From pepper.steve at gmail.com Wed Jul 1 14:46:15 2009 From: pepper.steve at gmail.com (Steve Pepper) Date: Wed, 1 Jul 2009 20:46:15 +0200 Subject: [sc34wg3] Scope support in Ontopoly In-Reply-To: <5DB88B37-9FDF-4D61-BA83-F0AC8A2465D3@garshol.priv.no> References: <31ABA30AC6214D869A344A597AC20D9F@huchu> <5DB88B37-9FDF-4D61-BA83-F0AC8A2465D3@garshol.priv.no> Message-ID: <2220B6B66298478487436FE15A95CB71@huchu> I wasn't aware that this couldn't be expressed in TMCL. That would appear to be a major omission. I can't imagine a multilingual topic map for which one would *not* want to have an enforceable policy regarding which *specific* languages should be used for which particular types of name and occurrence. Will you register this as a TMCL issue? Steve | -----Original Message----- | From: ontopia at googlegroups.com [mailto:ontopia at googlegroups.com] On Behalf Of | Lars Marius Garshol | Sent: 01 July 2009 20:15 | To: ontopia at googlegroups.com | Subject: Re: Scope support in Ontopoly | | | | * Steve Pepper | > | > I could envisage a variant of this ("Fixed-2"), based on an extended | > definition of "given field": | > | > ["s-type"] + [type] + [scope] | > | > This would allow us to do quite a bit more than today. For example a | > topic could have two (default) names (of type 'tmdm:name-type'), one | > of which was in the unconstrained scope and the other in the scope | > 'norwegian'. (This is not possible with "Fixed-1".) | | This is not expressible with TMCL today. You can say | | language isa tmcl:topic-type. | # define 5 instances of language | | topic-type has-occurrence(field, 5, 5). | field has-scope(language, 1, 1). | | but you cannot require the five occurrences of the type field to all | have different instances of language in their scopes, except by using | a user-defined constraint. | | > Assuming we agree that multilingual topic maps are best done using | > scoped names, rather than typed names, then this capability is | > clearly something that we need. | | It is not easy to avoid that conclusion, no. | | --Lars M. | http://www.garshol.priv.no/tmphoto/ | http://www.garshol.priv.no/blog/ | | | --~--~---------~--~----~------------~-------~--~----~ | You received this message because you are subscribed to the Google Groups | "ontopia" group. | To post to this group, send email to ontopia at googlegroups.com | To unsubscribe from this group, send email to | ontopia+unsubscribe at googlegroups.com | For more options, visit this group at | http://groups.google.com/group/ontopia?hl=en | -~----------~----~----~----~------~----~------~--~--- From gra at networkedplanet.com Wed Jul 1 14:56:18 2009 From: gra at networkedplanet.com (Graham Moore) Date: Wed, 1 Jul 2009 20:56:18 +0200 Subject: [sc34wg3] [tmcl-wg] Scope support in Ontopoly In-Reply-To: <2220B6B66298478487436FE15A95CB71@huchu> References: <31ABA30AC6214D869A344A597AC20D9F@huchu> <5DB88B37-9FDF-4D61-BA83-F0AC8A2465D3@garshol.priv.no> <2220B6B66298478487436FE15A95CB71@huchu> Message-ID: <69a048ce0907011156i6a16bb9fx60bb92f303aa19ac@mail.gmail.com> Hi, I've added it here http://projects.topicmapslab.de/issues/868. cheers, Gra 2009/7/1 Steve Pepper : > I wasn't aware that this couldn't be expressed in TMCL. > > That would appear to be a major omission. I can't imagine a multilingual topic > map for which one would *not* want to have an enforceable policy regarding which > *specific* languages should be used for which particular types of name and > occurrence. > > Will you register this as a TMCL issue? > > Steve > > > | -----Original Message----- > | From: ontopia at googlegroups.com [mailto:ontopia at googlegroups.com] On Behalf Of > | Lars Marius Garshol > | Sent: 01 July 2009 20:15 > | To: ontopia at googlegroups.com > | Subject: Re: Scope support in Ontopoly > | > | > | > | * Steve Pepper > | > > | > I could envisage a variant of this ("Fixed-2"), based on an extended > | > definition of "given field": > | > > | > ? ["s-type"] + [type] + [scope] > | > > | > This would allow us to do quite a bit more than today. For example a > | > topic could have two (default) names (of type 'tmdm:name-type'), one > | > of which was in the unconstrained scope and the other in the scope > | > 'norwegian'. (This is not possible with "Fixed-1".) > | > | This is not expressible with TMCL today. You can say > | > | ? ?language isa tmcl:topic-type. > | ? ?# define 5 instances of language > | > | ? ?topic-type has-occurrence(field, 5, 5). > | ? ?field has-scope(language, 1, 1). > | > | but you cannot require the five occurrences of the type field to all > | have different instances of language in their scopes, except by using > | a user-defined constraint. > | > | > Assuming we agree that multilingual topic maps are best done using > | > scoped names, rather than typed names, then this capability is > | > clearly something that we need. > | > | It is not easy to avoid that conclusion, no. > | > | --Lars M. > | http://www.garshol.priv.no/tmphoto/ > | http://www.garshol.priv.no/blog/ > | > | > | --~--~---------~--~----~------------~-------~--~----~ > | You received this message because you are subscribed to the Google Groups > | "ontopia" group. > | To post to this group, send email to ontopia at googlegroups.com > | To unsubscribe from this group, send email to > | ontopia+unsubscribe at googlegroups.com > | For more options, visit this group at > | http://groups.google.com/group/ontopia?hl=en > | -~----------~----~----~----~------~----~------~--~--- > > _______________________________________________ > tmcl-wg mailing list > tmcl-wg at isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/tmcl-wg > -- Graham Moore, Director, Networked Planet Limited Editor XTM 1.0, ISO13250 (TopicMaps) -2,-3, TMCL e: graham.moore at networkedplanet.com w: www.networkedplanet.com t: +44 1865 811131 m: +44 7769658611 (UK) m: +47 45271713 (Norway) Networked Planet Limited is registered in England and Wales, no. 5273377 From patrick at durusau.net Sun Jul 5 19:23:42 2009 From: patrick at durusau.net (Patrick Durusau) Date: Sun, 05 Jul 2009 19:23:42 -0400 Subject: [sc34wg3] TMQL Chapter 4, Sections 1 + 2 Message-ID: <4A5135FE.3030708@durusau.net> Greetings! Apologies for being late. It was a long week. Continuing to explore the recesses and crannies of the latest draft of TMQL (http://www.isotopicmaps.org/tmql/tmql.html). First, let me say up front that I would lose all the examples, both here and elsewhere. I assume this is being authored in markup so production of a version with even *more* examples for an annotated version of the final text should be trivial. That would allow an annotated version to concentrate on being a tutorial like document and allow the standard to concentrate on being a standard. 4.2 becomes: ***** Atoms are values drawn from the data types listed in Table 1. ***** Only partially defined by CTM. References W3C for date and date-time (note error in TMQL draft, which reports dateTime). Might be easier to simply invoke the data types as defined by the W3C and list those in table 1. Besides, number is simply wrong. There are lot of non-ASCII digits in the world. I really don't see why we need this limitation. I don't know what to make up decimal patterns being preferred over shorter integer patterns? For what purposes? By who or what? Suggest lose that line without more explanation. The rest of that paragraph is just repeitition so strike it as well. Well, except for the escape character doesn't appear in the regex. Need to fix that or better yet reference a regex with it already present. Lose the examples as I said before. Oh, the IRI or QName to explicitly provide data type? Not available except on strings. I don't see how the reference to clause 8 helps anything? The next paragraph starts: "For references either absolute IRIs or QNames can be used:" Should read: "Item references can be either absolute IRIs or QNames." Suggestion: Rather than dipping in and out of the formal syntax, why not simply make all the prose statements, uninterrupted by the formal syntax and then express the same material in a concluding section? Or subsection? Actually my preference would be to simply define all the material once, in prose and then in a normative annex have the formal grammar that tracks the statements in the prose. That serves the audience of readers who prefer prose as well as those who prefer to simply read formal productions. Not to mention that it would be easier to say: IRIs as defined by RFC 3987 and then to move on. Noting that the productions there bear little resemblance to /([^<>'{}|^`] - [#x00-#x20]])*/ as found in TMQL. Same should be true for prefix. Odd that identifier should be limited to ASCII text under the current proposal. Lose the language following [16] identifier. IRIs can be defined both in prose and in productions but let's do it fully in both places, not half in and half out. Same observation for QNames. Lose the Note on prefixes. In the paragraph that starts: "If the item reference is a QName, then the ...." Suggest: "If an item reference is a QName, then the QName prefix (without the trailing colon ":") is a topic identifier for a topic of type tmql:ontology in the effective map. It is an error if no such topic exists." OK, now what? We have declared an error condition. Does the processor just laugh? Out loud or silently? Then,... "If no subject indicator for that ontology topic exists, then an error will be flagged." Gee, that sounds a lot worse than simply having an error. ;-) It seems to assume that the tmql:ontology topic exists, so we are past the first error condition, but now we find that the topic exists but doesn't have a subject indicator? Now we get "flagged." Now what? We can say the handling of errors is implementation defined but we really should say something. Besides, all this is at odds with: "This International Standard does not define an API (application programming interface) to interact with query processors and also refrains from naming certain error conditions." Unless you think these are "certain other error conditions." And that paragraph concludes: "Otherwise one such subject indicator - together with the identifier in the QName - is used to construct an absolute IRI according to the rules in [RFC3986] (5.2, Relative Resolution)." The final statement seems to presume that the subject indicator can meaningfully be used with the QName to construct an identifier. I don't know of any fixed relationship between QNames and subject indicators that are found in a topic. Is this meant to enforce such a relationship? Particularly since a topic can have more than one subject indicator. Hopefully this will be a better week. Hope everyone is at the start of a great week! Patrick -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From heuer at semagia.com Mon Jul 6 17:20:31 2009 From: heuer at semagia.com (Lars Heuer) Date: Mon, 6 Jul 2009 23:20:31 +0200 Subject: [sc34wg3] TMQL Chapter 4, Sections 1 + 2 In-Reply-To: <4A5135FE.3030708@durusau.net> References: <4A5135FE.3030708@durusau.net> Message-ID: Hi Patrick, I am not sure if it makes sense to discuss the current draft in detail since there seems to be attempts to change TMQL "Here, There and Everywhere". Anyway, maybe I can clarify a few points. > First, let me say up front that I would lose all the examples, both here > and elsewhere. I think keeping the examples would be good. Even if a standard is not meant as tutorial, the examples help the reader to get an access to the abstract topic. [...] > 4.2 becomes: > > ***** > Atoms are values drawn from the data types listed in Table 1. > ***** > > Only partially defined by CTM. References W3C for date and date-time > (note error in TMQL draft, which reports dateTime). IMO this is a minor task. Aside from "undef" and the iri notation TMQL is pretty aligned to CTM. IIRC the TMQL editors want to loose the boolean datatype anyway. Regarding "dateTime": Yes, I've chosen the notation date-time since it fits better in the naming scheme for productions. I think that the TMQL standard either will refer to the CTM standard for its datatypes or will use the same productions as CTM. Not a big issue at all (aside from the "iri" production which has to be fixed since it looks like a string). > Well, except for the escape character doesn't appear in the regex. Need > to fix that or better yet reference a regex with it already present. I think the regexes will be fixed once the TMQL editors use the correct (not Perl-alike) stylesheet. [...] > Not to mention that it would be easier to say: IRIs as defined by RFC > 3987 and then to move on. Noting that the productions there bear little > resemblance to /([^<>'{}|^`] - [#x00-#x20]])*/ as found in TMQL. In CTM we've gone the other way around: We provided a regex to define "That's an IRI" and the committee said "Well, we have the nice RFCs, we could simply put a reference to them into CTM, please do that". We made that. In one of the next meetings the committee said "Well, you reference the RFC here, wouldn't it be cool if we could have a regex just to have a common understanding what that production means?". Yeah, cool idea. :) Personally I think having regexes is better than just referring to another document. > Odd that identifier should be limited to ASCII text under the current > proposal. Should be aligned to CTM as well. > "Otherwise one such subject indicator - together with the identifier in > the QName - is used to construct an absolute IRI according to the rules > in [RFC3986] (5.2, Relative Resolution)." > > The final statement seems to presume that the subject indicator can > meaningfully be used with the QName to construct an identifier. I don't > know of any fixed relationship between QNames and subject indicators > that are found in a topic. Is this meant to enforce such a relationship? > Particularly since a topic can have more than one subject indicator. I think it is meant as: If you declare a prefix A for URI B that prefix is handled like an item identifier and is putted into the environment map and the URI B becomes automatically a subject identifier of that prefix. If you try to resolve a QName, the interpreter looks for the "prefix" part of the QName and looks for the subject identifier of the prefix. If a topic has more than just one subject identifier, TMQL treats all these ontologies as one ontology, I guess. I was never a big supporter of handing prefixes as topics, though. I think it would be better to keep the prefix -> URI mapping outside the Topic Maps model. Best regards, Lars -- Semagia From patrick at durusau.net Mon Jul 6 19:41:30 2009 From: patrick at durusau.net (Patrick Durusau) Date: Mon, 06 Jul 2009 19:41:30 -0400 Subject: [sc34wg3] TMQL Chapter 4, Sections 1 + 2 In-Reply-To: References: <4A5135FE.3030708@durusau.net> Message-ID: <4A528BAA.5000302@durusau.net> Lars, Lars Heuer wrote: > Hi Patrick, > > I am not sure if it makes sense to discuss the current draft in detail > since there seems to be attempts to change TMQL "Here, There and > Everywhere". > > Anyway, maybe I can clarify a few points. > > Thanks for the reply! Actually one of the things I want for TMQL is to not see all the work done to date lost. Such as re-using the TMRM to define the formal semantics of TMQL, separate and apart from any implementation. Which obviously includes relying upon the TMDM <-> TMRM mapping by Lars Marius Garshol. Not to mention all the work that has gone into TMQL up to this point. That is not to say that some aspects of it shouldn't be changed even now. Simplification or syntax changes that will make it easier to finish and gain final approval may not be bad things. So far there hasn't been enough detail offered vis-a-vis the current draft to make an informed judgment. Personally I would like to see TMQL on the agenda for a WG 3 meeting in September, at which time syntax changes, simplifications could be discussed, followed by a called editor's meeting in Leipzig. Assuming the formal mapping parts can be completed by the September meeting, it might be possible to see a nearly final version of TMQL by later this year. Given the recent flurry of interest, which I assume indicates people with the time to devote to working on TMQL, that should be doable. Yes? I will respond separately to your relies on my other comments. Hope you are having a great day! Patrick -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From patrick at durusau.net Mon Jul 6 19:55:59 2009 From: patrick at durusau.net (Patrick Durusau) Date: Mon, 06 Jul 2009 19:55:59 -0400 Subject: [sc34wg3] TMQL Chapter 4, Sections 1 + 2 In-Reply-To: References: <4A5135FE.3030708@durusau.net> Message-ID: <4A528F0F.3030009@durusau.net> Lars, Lars Heuer wrote: > Hi Patrick, > > I am not sure if it makes sense to discuss the current draft in detail > since there seems to be attempts to change TMQL "Here, There and > Everywhere". > > Anyway, maybe I can clarify a few points. > > Well, I don't know of any other draft to discuss other than the one before WG 3. At least that would focus the discussion on what is known, even if parts of it are unwanted. ;-) >> First, let me say up front that I would lose all the examples, both here >> and elsewhere. >> > > I think keeping the examples would be good. Even if a standard is not > meant as tutorial, the examples help the reader to get an access to > the abstract topic. > > True but as I said, more extensive and useful examples can be placed in an annotated version. And that could include snippets of actual code, something that is unlikely to appear otherwise. I don't disagree with your premise about examples being helpful, my only concern is that we make standards short and direct. Being easy to read is the job of secondary literature. > [...] > >> 4.2 becomes: >> >> ***** >> Atoms are values drawn from the data types listed in Table 1. >> ***** >> >> Only partially defined by CTM. References W3C for date and date-time >> (note error in TMQL draft, which reports dateTime). >> > > IMO this is a minor task. Aside from "undef" and the iri notation TMQL > is pretty aligned to CTM. IIRC the TMQL editors want to loose the > boolean datatype anyway. > Regarding "dateTime": Yes, I've chosen the notation date-time since it > fits better in the naming scheme for productions. > I think that the TMQL standard either will refer to the CTM standard > for its datatypes or will use the same productions as CTM. Not a big > issue at all (aside from the "iri" production which has to be fixed > since it looks like a string). > > OK. >> Well, except for the escape character doesn't appear in the regex. Need >> to fix that or better yet reference a regex with it already present. >> > > I think the regexes will be fixed once the TMQL editors use the > correct (not Perl-alike) stylesheet. > > ;-) > [...] > >> Not to mention that it would be easier to say: IRIs as defined by RFC >> 3987 and then to move on. Noting that the productions there bear little >> resemblance to /([^<>'{}|^`] - [#x00-#x20]])*/ as found in TMQL. >> > > In CTM we've gone the other way around: We provided a regex to define > "That's an IRI" and the committee said "Well, we have the nice RFCs, > we could simply put a reference to them into CTM, please do that". We > made that. In one of the next meetings the committee said "Well, you > reference the RFC here, wouldn't it be cool if we could have a regex > just to have a common understanding what that production means?". > Yeah, cool idea. :) Personally I think having regexes is better than > just referring to another document. > > Hmmm, sure, opinions differ on the practice. Do you think this regex matches what is found in RFC 3987? >> Odd that identifier should be limited to ASCII text under the current >> proposal. >> > > Should be aligned to CTM as well. > > >> "Otherwise one such subject indicator - together with the identifier in >> the QName - is used to construct an absolute IRI according to the rules >> in [RFC3986] (5.2, Relative Resolution)." >> >> The final statement seems to presume that the subject indicator can >> meaningfully be used with the QName to construct an identifier. I don't >> know of any fixed relationship between QNames and subject indicators >> that are found in a topic. Is this meant to enforce such a relationship? >> Particularly since a topic can have more than one subject indicator. >> > > I think it is meant as: If you declare a prefix A for URI B that > prefix is handled like an item identifier and is putted into the > environment map and the URI B becomes automatically a subject > identifier of that prefix. > If you try to resolve a QName, the interpreter looks for the "prefix" > part of the QName and looks for the subject identifier of the prefix. > If a topic has more than just one subject identifier, TMQL treats all > these ontologies as one ontology, I guess. > I was never a big supporter of handing prefixes as topics, though. I > think it would be better to keep the prefix -> URI mapping outside the > Topic Maps model. > OK, that makes sense. There could be a problem with using prefixes as item identifiers if there is a clash between them. For example, in ODF (unfortunately) we define our own "svg" prefix with a URI. So, if you had the "svg" compatible namespace from ODF and the "svg" namespace from the W3C, then you would have two item identifiers with different URIs. Note that we redefine some things, mostly subsetting but not always in the "svg" compatible namespace so I am not sure it would be accurate to say it is "one ontology." I strongly suspect the SVG crowd at the W3C would say not. Hope you are having a great day! Patrick PS: Thanks for the latest CTM draft! -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From heuer at semagia.com Mon Jul 6 20:40:09 2009 From: heuer at semagia.com (Lars Heuer) Date: Tue, 7 Jul 2009 02:40:09 +0200 Subject: [sc34wg3] TMQL Chapter 4, Sections 1 + 2 In-Reply-To: <4A528F0F.3030009@durusau.net> References: <4A5135FE.3030708@durusau.net> <4A528F0F.3030009@durusau.net> Message-ID: Hi Patrick, [...] >> I am not sure if it makes sense to discuss the current draft in detail >> since there seems to be attempts to change TMQL "Here, There and >> Everywhere". [...] > Well, I don't know of any other draft to discuss other than the one before > WG 3. At least that would focus the discussion on what is known, even if > parts of it are unwanted. ;-) :) There is no other draft, of course, but the community (that includes me to some extend), seems to be unhappy with TMQL. I think TMQL is consistent (with a few bugs) but I like to change some things and I think TMQL would gain a higher acceptance in the community if some things change and some things are dropped. I am not talking about a new language here, I just think that TMQL needs some further work and I hope the community (and committee) follows the "fixing issues" path. [...] > I don't disagree with your premise about examples being helpful, my only > concern is that we make standards short and direct. Being easy to read is > the job of secondary literature. I agree that standards are not meant to be consumed by "normal" people, but I think examples help even "abnormal" people who want to implement the standard. The standard itself must be consistent, of course. [...] >> In CTM we've gone the other way around: We provided a regex to define >> "That's an IRI" and the committee said "Well, we have the nice RFCs, >> we could simply put a reference to them into CTM, please do that". We >> made that. In one of the next meetings the committee said "Well, you >> reference the RFC here, wouldn't it be cool if we could have a regex >> just to have a common understanding what that production means?". [....] > Hmmm, sure, opinions differ on the practice. Do you think this regex matches > what is found in RFC 3987? Well, the escaped syntax () is matched by the RFC, but the new CTM syntax for unescaped (non-rootless) IRIs does not cover the whole RFC but that's intentional: We just want to cover the use case where the IRI exists of a schema name (like http, or https, or ftp, or...) and the "://" follows that schema name. That's the common use case. For all other schemas, like "mailto" the user could use the '' syntax. [...] >> I think it is meant as: If you declare a prefix A for URI B that >> prefix is handled like an item identifier and is putted into the >> environment map and the URI B becomes automatically a subject >> identifier of that prefix. >> If you try to resolve a QName, the interpreter looks for the "prefix" >> part of the QName and looks for the subject identifier of the prefix. >> If a topic has more than just one subject identifier, TMQL treats all >> these ontologies as one ontology, I guess. >> I was never a big supporter of handing prefixes as topics, though. I >> think it would be better to keep the prefix -> URI mapping outside the >> Topic Maps model. >> > > OK, that makes sense. As said, I was never a big supporter of that mental model. Even if I think that "Eating your own dogfood" is preferable, you have to take the "everything looks like a nail" assumption into account. Regarding prefixes and QNames I'd go the traditional way. The standard should not forbid to tread the prefix / IRI tuple as topic, but IMO it is wrong to mandate that. > PS: Thanks for the latest CTM draft! To be written........ :( Best regards, Lars -- Semagia From patrick at durusau.net Tue Jul 7 07:48:07 2009 From: patrick at durusau.net (Patrick Durusau) Date: Tue, 07 Jul 2009 07:48:07 -0400 Subject: [sc34wg3] TMQL Chapter 4, Sections 1 + 2 In-Reply-To: References: <4A5135FE.3030708@durusau.net> <4A528F0F.3030009@durusau.net> Message-ID: <4A5335F7.9010905@durusau.net> Lars, Just quickly as I dash out the door for another round with the American medical establishment. ;-) Lars Heuer wrote: > Hi Patrick, > > [...] > >>> I am not sure if it makes sense to discuss the current draft in detail >>> since there seems to be attempts to change TMQL "Here, There and >>> Everywhere". >>> > [...] > >> Well, I don't know of any other draft to discuss other than the one before >> WG 3. At least that would focus the discussion on what is known, even if >> parts of it are unwanted. ;-) >> > > :) There is no other draft, of course, but the community (that > includes me to some extend), seems to be unhappy with TMQL. I think > TMQL is consistent (with a few bugs) but I like to change some things > and I think TMQL would gain a higher acceptance in the community if > some things change and some things are dropped. I am not talking about > a new language here, I just think that TMQL needs some further work > and I hope the community (and committee) follows the "fixing issues" > path. > > No disagreement at all. Higher acceptance is always a good thing. I happen to think discussing a nearly finished draft in terms of what should stay and what should go will be more productive in terms of reaching a final draft sooner rather than later. Hope you are having a great day! Patrick -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From larsga at garshol.priv.no Tue Jul 7 12:18:52 2009 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: Tue, 7 Jul 2009 18:18:52 +0200 Subject: [sc34wg3] CTM: CURIE vs. embedded topics In-Reply-To: <362101955.20090630161615@semagia.com> References: <362101955.20090630161615@semagia.com> Message-ID: * Lars Heuer > > There were some people who wish to support CURIEs [1] in CTM. IMO it > would be a good thing, but the safe CURIE syntax [2] conflicts with > the embedded topics feature: Both use these brackets: [ ] > > Either we do not reference the CURIE recommendation and I add a > syntactical construct to CTM which works similar to CURIEs but does > not include the [ ] syntax, or I can add a note that [] is not > supported for CURIEs or we drop embedded topics. > > Any opinion on this? It's just a working draft, so there's no knowing how it will look when and if it is ever finished. It would be a good thing, but IMHO redoing CTM is a total no-no. In other words, I think we should just silently ignore CURIEs. --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/ From patrick at durusau.net Tue Jul 14 20:07:17 2009 From: patrick at durusau.net (Patrick Durusau) Date: Tue, 14 Jul 2009 20:07:17 -0400 Subject: [sc34wg3] WG3 Meeting, Seattle, 14-16, September 2009 Message-ID: <4A5D1DB5.3030206@durusau.net> Greetings! The official document should appear later today or tomorrow but this is to announce the WG 3 meeting in connection with the SC 34 plenary in Seattle this coming September. The draft agenda is as follows (subject to modification): *1.* Opening - 2009-09-14 10:00 *2.* Adoption of the Agenda *3.* Future meeting schedule *4.* TMQL: 18048 *5.* TMCL: 19756 *6.* TMRM: 13250-5 *7.* CTM: 13250-7 *8.* Overview and Basic Concepts 13250-1 *9. *Approval of Recommendations *10.* Any other business *11.*. Closing Please contact your national body about being a delegate to this meeting. If you are unable to attend as part of a national body, the WG has a tradition of extending "invited expert" status to those wishing to attend and participate in the work. More details to follow. Hope everyone is having a great week! Patrick -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From larsga at garshol.priv.no Wed Jul 15 06:01:56 2009 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: Wed, 15 Jul 2009 12:01:56 +0200 Subject: [sc34wg3] New TMCL draft posted Message-ID: The editors have posted a new TMCL draft: http://www.isotopicmaps.org/tmcl/tmcl.html Changes from the previous draft are: * other-role-constraint has been replaced by role-combination- constraint http://projects.topicmapslab.de/issues/861 * topic-reifies-constraint has been added http://projects.topicmapslab.de/issues/855 * improved the section on user-defined constraints http://projects.topicmapslab.de/issues/858 There are still a number of open issues which need further consideration and discussion. Input on these and on the new draft is more than welcome. http://projects.topicmapslab.de/projects/tmcl/issues --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/ From patrick at durusau.net Thu Jul 23 06:32:20 2009 From: patrick at durusau.net (Patrick Durusau) Date: Thu, 23 Jul 2009 06:32:20 -0400 Subject: [sc34wg3] PSI issue Message-ID: <4A683C34.6080903@durusau.net> Greetings! Apologies for the cross-posting but this concerns a proposal I am making in WG 5 of SC 34 so I wanted ISO folks to hear this issue as well. I am trying to design PSIs to represent the markup constructs of both ISO 26300 and ISO 29500. Note that I said the "markup constructs" by which I mean to eliminate the notion of some uber abstraction that represents all "p" elements. Granted that might be an interesting exercise and possibly even a useful one but at this point, the only subjects of my concern are the elements and attributes as defined by those two standards. I am considering generating PSIs along the lines of: http://psi.somewhere.com/odf/element/(elementName).html http://psi.somewhere.com/odf/attribute(attributeName).html http://psi.somewhere.com/ooxml/element/(elementName).html http://psi.somewhere.com/ooxml/attribute(attributeName).html One modest improvement would be to add version information to that string, thus: http://psi.somewhere.com/odf/1.0/element/(elementName).html However, there is a more fundamental problem. There are attributes with the same names that have different values depending upon the element where they appear. This is true for both ODF and OOXML. Murata-san assures me this is a very powerful schema design feature. I have a less generous opinion of this "feature" but I forebear further comment as the schemas are what they are and I can't change that. So I can't have, for instance: http://psi.somewhere.com/odf/1.0/attribute/office_name.html without confusing the different uses of that attribute. For example on a draw:draw:area-polygon it specifies a name for an image and explicitly need not be unique. On the other hand, when that attribute appears on office:annotation, it specifies the name of a corresponding element and the pair must be unique. One thing that I have considered is having: http://psi.somewhere.com/odf/1.0/attribute/office_name.html as a PSI and the information there contains additional PSIs that point to the various meanings of that attribute. I find that attractive because I am sure I will want to talk about office:name in "general," that is as a confusing way to specify names on elements and at the same time, I will need PSIs to identify the various more specific uses of office:name. Should the more "specific" attributes then have the structure: http://psi.somewhere.com/odf/1.0/attribute/office_name/element-draw_area-polygon and http://psi.somewhere.com/odf/1.0/attribute/office_name/element-office_annotation ??? Be aware that I used the element prefix on the final part of the string deliberately because both standards have a tendency to "reuse" names. The goal of this initial step is to develop a structure for the PSIs and then to generate a generous sampling of them to inspect for other issues. There are attributes whose behavior varies depending upon the presence (or absence) of other attributes either on the same element or a parent element but I don't see that as changing the subject in question. Any thoughts or suggestions would be most welcome! Hope everyone is having a great week! Patrick -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From gkholman at CraneSoftwrights.com Thu Jul 23 09:07:41 2009 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Thu, 23 Jul 2009 09:07:41 -0400 Subject: [sc34wg3] [topicmapmail] PSI issue In-Reply-To: <4A683C34.6080903@durusau.net> References: <4A683C34.6080903@durusau.net> Message-ID: <7.0.1.0.2.20090723090555.027d5c28@wheresmymailserver.com> At 2009-07-23 06:32 -0400, you wrote: >I am trying to design PSIs to represent the markup constructs of both >ISO 26300 and ISO 29500. Interesting! I have had a number of false starts trying to initiate PSI projects. >I am considering generating PSIs along the lines of: > >http://psi.somewhere.com/odf/element/(elementName).html > >http://psi.somewhere.com/odf/attribute(attributeName).html > >http://psi.somewhere.com/ooxml/element/(elementName).html > >http://psi.somewhere.com/ooxml/attribute(attributeName).html > >One modest improvement would be to add version information to that >string, thus: > >http://psi.somewhere.com/odf/1.0/element/(elementName).html For UBL I'm choosing not to add the version number because our mandate covers only minor revisions of UBL 2.0, so only UBL 2.x, and within all of UBL 2.x any given construct retains its semantics. It happens we don't put any business entity in an attribute. >However, there is a more fundamental problem. > >There are attributes with the same names that have different values >depending upon the element where they appear. This is true for both ODF >and OOXML. Murata-san assures me this is a very powerful schema design >feature. I have a less generous opinion of this "feature" but I forebear >further comment as the schemas are what they are and I can't change that. > >So I can't have, for instance: > >http://psi.somewhere.com/odf/1.0/attribute/office_name.html > >without confusing the different uses of that attribute. I think you can do with explicitly using "/element/" or "/attribute." in the PSI. If the PSI set is assumed to be for the XML vocabulary, then you can probably get away with the following set of files: http://psi.somewhere.com/odf/1.0/vocabulary/elementName/index.html http://psi.somewhere.com/odf/1.0/vocabulary/elementName/attributeName/index.html and the following PSI strings: http://psi.somewhere.com/odf/1.0/vocabulary/elementName http://psi.somewhere.com/odf/1.0/vocabulary/elementName/attributeName which would be resolved in a server to the index.html files. This allows you to have an entire directory in which to put artefacts that might be referenced by the PSI documentation (images, etc.). This addresses attribute context by being in a subdirectory of the element subdirectory. Now there is no ambiguity ... you know exactly what the semantics are. I am assuming, however, that ancestral context (beyond parent) is merely addressed in the semantics and is not a separate set of semantics. Using various server-side mechanisms (rewrite, symbolic links, etc.) you can reduce the number of server artefacts, but the end result would be transparent to the user and the scheme would be, I think, obvious to someone who sees it without having any coaching. After seeing a couple of examples, they would know what to do for any attribute they had. Note you wouldn't need "/vocabulary/" if the *only* reason you are creating PSI strings is for the elements and attributes, but I'm guessing there may be other PSI strings related to these specifications so this would separate the vocabulary from others. >The goal of this initial step is to develop a structure for the PSIs and >then to generate a generous sampling of them to inspect for other >issues. There are attributes whose behavior varies depending upon the >presence (or absence) of other attributes either on the same element or >a parent element but I don't see that as changing the subject in question. Nor do I ... the semantics for a given attribute include issues of the impact of other attributes, but that is just part of its definition. In my PSI efforts I'm trying to create 2000 PSI pages, one for each of the business entities in UBL, to be put in the OASIS PSI server, and hyperlink those bidirectionally to 2000 wiki pages in http://ubl.xml.org so that the committee manages the formal definitions and semantics in the PSI documentation and the community supplements that with anything they want to say about each entity in the wiki discussion. From the wiki you can get to the official read-only committee specification. From the committee PSI you can get to what the community thinks of a particular concept, how it should be used, examples, etc., all of which are not really part of the committee-managed semantics. It turns out the roadblocks are pedestrian concerns about how to mount 4000 web pages on two servers. Once I'm told how I can do that, the rest is just a simple matter of stylesheet writing (I've done a bit of that before). I hope this suggestion is considered helpful. Good luck in your PSI project! . . . . . . . . . . . . . Ken -- XSLT/XQuery/XSL-FO hands-on training - Oakland, CA, USA 2009-08-03 Crane Softwrights Ltd. http://www.CraneSoftwrights.com/t/ Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman at CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/t/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal From gkholman at CraneSoftwrights.com Thu Jul 23 09:10:32 2009 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Thu, 23 Jul 2009 09:10:32 -0400 Subject: [sc34wg3] [topicmapmail] PSI issue In-Reply-To: <7.0.1.0.2.20090723090555.027d5c28@wheresmymailserver.com> References: <4A683C34.6080903@durusau.net> <7.0.1.0.2.20090723090555.027d5c28@wheresmymailserver.com> Message-ID: <7.0.1.0.2.20090723090929.02842de0@wheresmymailserver.com> At 2009-07-23 09:07 -0400, I wrote: >I think you can do with explicitly using "/element/" or "/attribute." Sorry, "I think you can do without explicitly using..." . . . . . . . . Ken -- XSLT/XQuery/XSL-FO hands-on training - Oakland, CA, USA 2009-08-03 Crane Softwrights Ltd. http://www.CraneSoftwrights.com/t/ Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman at CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/t/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal From patrick at durusau.net Thu Jul 23 10:39:46 2009 From: patrick at durusau.net (Patrick Durusau) Date: Thu, 23 Jul 2009 10:39:46 -0400 Subject: [sc34wg3] [topicmapmail] PSI issue In-Reply-To: <7.0.1.0.2.20090723090555.027d5c28@wheresmymailserver.com> References: <4A683C34.6080903@durusau.net> <7.0.1.0.2.20090723090555.027d5c28@wheresmymailserver.com> Message-ID: <4A687632.3030400@durusau.net> Ken, Thanks for the quick response! Just a hurried partial response: G. Ken Holman wrote: > At 2009-07-23 06:32 -0400, you wrote: > > > I think you can do with explicitly using "/element/" or "/attribute." > in the PSI. If the PSI set is assumed to be for the XML vocabulary, > then you can probably get away with the following set of files: > > http://psi.somewhere.com/odf/1.0/vocabulary/elementName/index.html > http://psi.somewhere.com/odf/1.0/vocabulary/elementName/attributeName/index.html > > and the following PSI strings: > > http://psi.somewhere.com/odf/1.0/vocabulary/elementName > http://psi.somewhere.com/odf/1.0/vocabulary/elementName/attributeName > > which would be resolved in a server to the index.html files. This > allows you to have an entire directory in which to put artefacts that > might be referenced by the PSI documentation (images, etc.). > > I am assuming you intend for "vocabulary" to be replace by the namespace prefix? Yes? Because there are conflicts of names across namespaces. From ODF: vs. . Thus your suggestion becomes: http://psi.somewhere.com/odf/1.0/meta/editing-cycles http://psi.somewhere.com/odf/1.0/text/editing-cycles But by leaving out element/attribute, I lose the ability to talk about an attribute that may have the same value space for multiple elements. Yes? At least for use with one PSI. That is for every case of an attribute I have to create the longer listing. Doable and I did something similar in the current ODF draft but duplicating the definition seems untidy at best and does tend to lose the information that the same value space applies across multiple elements. Having said all that, it may be preferable to be too specific and rely upon a topic map engine and/or user interface to present the necessary information in a user friendly way. I am hopeful that PSIs are generally going to be presented to users as pick lists of names, etc. where the actual mechanics aren't really visible. Not unlike picking a font for a text. All sorts of things have to go right for that to happen but for the most part I am blissfully unaware of them. The use of PSIs should be the same. And I may be mistaken but I have the definite impression that I have encountered reuse of an element or attribute name, which would required the use of element/attribute in the path to disambiguate it. Hope you are having a great day! Patrick -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From gkholman at CraneSoftwrights.com Thu Jul 23 10:53:04 2009 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Thu, 23 Jul 2009 10:53:04 -0400 Subject: [sc34wg3] [topicmapmail] PSI issue In-Reply-To: <4A687632.3030400@durusau.net> References: <4A683C34.6080903@durusau.net> <7.0.1.0.2.20090723090555.027d5c28@wheresmymailserver.com> <4A687632.3030400@durusau.net> Message-ID: <7.0.1.0.2.20090723104421.027e7b58@wheresmymailserver.com> At 2009-07-23 10:39 -0400, Patrick Durusau wrote: >Because there are conflicts of names across namespaces. > > From ODF: vs. . > >Thus your suggestion becomes: > >http://psi.somewhere.com/odf/1.0/meta/editing-cycles > >http://psi.somewhere.com/odf/1.0/text/editing-cycles > >But by leaving out element/attribute, I lose the ability to talk about >an attribute that may have the same value space for multiple elements. >Yes? At least for use with one PSI. True, but I tried to address that with a comment on implementation-level approaches: At 2009-07-23 09:07 -0400, I wrote: >Using various server-side mechanisms (rewrite, symbolic links, etc.) >you can reduce the number of server artefacts, but the end result >would be transparent to the user and the scheme would be, I think, >obvious to someone who sees it without having any coaching. After >seeing a couple of examples, they would know what to do for any >attribute they had. Such schemes would allow you to have multiple web pages for the same named attribute, one under each element, but they would, say, symbolically link to the one page in the directories that documents it. Would a user ever think about an attribute without thinking of its element? Every "shared" attribute would be found under every element that shares it, so it doesn't matter which one the user uses to see the common documentation. And they don't have to worry about guessing which element is correct (they may not even know it is a common attribute). At 2009-07-23 10:39 -0400, Patrick Durusau wrote: >That is for every case of an attribute I have to create the longer >listing. Doable and I did something similar in the current ODF draft but >duplicating the definition seems untidy at best and does tend to lose >the information that the same value space applies across multiple elements. The tidiness is addressed by back-end schemes, and the documentation for an attribute can reveal all the elements to which it applies. It has to be simple so that the user doesn't have to think about how the scheme works ... the user won't know which attributes are shared and which are not ... it is up to us to bear the burden of complexity behind the scenes. >Having said all that, it may be preferable to be too specific and rely >upon a topic map engine and/or user interface to present the necessary >information in a user friendly way. I am hopeful that PSIs are generally >going to be presented to users as pick lists of names, etc. where the >actual mechanics aren't really visible. Not unlike picking a font for a >text. All sorts of things have to go right for that to happen but for >the most part I am blissfully unaware of them. The use of PSIs should be >the same. Agreed. But consistency and expectation will be important fallback mechanisms to rely on should there be no user interface. >And I may be mistaken but I have the definite impression that I have >encountered reuse of an element or attribute name, which would required >the use of element/attribute in the path to disambiguate it. But even if the same name is used for both an attribute and an element, if you categorically always put attributes "under" elements in the PSI path structure, there is no ambiguity. There are no "top-level" attributes in the PSI scheme. I hope this helps. . . . . . . . . . . Ken -- XSLT/XQuery/XSL-FO hands-on training - Oakland, CA, USA 2009-08-03 Crane Softwrights Ltd. http://www.CraneSoftwrights.com/t/ Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman at CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/t/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal From patrick at durusau.net Fri Jul 24 16:15:38 2009 From: patrick at durusau.net (Patrick Durusau) Date: Fri, 24 Jul 2009 16:15:38 -0400 Subject: [sc34wg3] [topicmapmail] PSI issue In-Reply-To: <7.0.1.0.2.20090723104421.027e7b58@wheresmymailserver.com> References: <4A683C34.6080903@durusau.net> <7.0.1.0.2.20090723090555.027d5c28@wheresmymailserver.com> <4A687632.3030400@durusau.net> <7.0.1.0.2.20090723104421.027e7b58@wheresmymailserver.com> Message-ID: <4A6A166A.2040203@durusau.net> Ken, Apologies for the delayed response! And yes, I read too quickly in my first reply. G. Ken Holman wrote: > At 2009-07-23 10:39 -0400, Patrick Durusau wrote: > >> Because there are conflicts of names across namespaces. >> >> From ODF: vs. . >> >> Thus your suggestion becomes: >> >> http://psi.somewhere.com/odf/1.0/meta/editing-cycles >> >> http://psi.somewhere.com/odf/1.0/text/editing-cycles >> >> But by leaving out element/attribute, I lose the ability to talk about >> an attribute that may have the same value space for multiple elements. >> Yes? At least for use with one PSI. >> > > True, but I tried to address that with a comment on > implementation-level approaches: > > At 2009-07-23 09:07 -0400, I wrote: > >> Using various server-side mechanisms (rewrite, symbolic links, etc.) >> you can reduce the number of server artefacts, but the end result >> would be transparent to the user and the scheme would be, I think, >> obvious to someone who sees it without having any coaching. After >> seeing a couple of examples, they would know what to do for any >> attribute they had. >> > > Such schemes would allow you to have multiple web pages for the same > named attribute, one under each element, but they would, say, > symbolically link to the one page in the directories that documents it. > > Would a user ever think about an attribute without thinking of its element? > > Every "shared" attribute would be found under every element that > shares it, so it doesn't matter which one the user uses to see the > common documentation. And they don't have to worry about guessing > which element is correct (they may not even know it is a common attribute). > > I think you make a good argument for the structure you suggest for PSIs but to some degree I think your interpretation reflects a different understanding of the subject I am trying to capture. To me, which is probably a highly individualized view, attributes certainly exist separate from any particular element. It is as if I have a store of attribute from which to select when deciding on what attributes should appear on an element. However, I think your point that most users will always think of attributes in regard to particular elements is a good one. After all, I want to create a resource that will be used by users and not one that has the "true" view of markup languages (which is invariably the author's). > At 2009-07-23 10:39 -0400, Patrick Durusau wrote: > >> That is for every case of an attribute I have to create the longer >> listing. Doable and I did something similar in the current ODF draft but >> duplicating the definition seems untidy at best and does tend to lose >> the information that the same value space applies across multiple elements. >> > > The tidiness is addressed by back-end schemes, and the documentation > for an attribute can reveal all the elements to which it applies. It > has to be simple so that the user doesn't have to think about how the > scheme works ... the user won't know which attributes are shared and > which are not ... it is up to us to bear the burden of complexity > behind the scenes. > > Well, but for some advanced modeling purposes I will need to represented the shared nature or perhaps co-existence of certain attributes on a single element but that is probably too heavy duty for a simple PSI. There are other topic map mechanisms to do the heavy lifting. >> Having said all that, it may be preferable to be too specific and rely >> upon a topic map engine and/or user interface to present the necessary >> information in a user friendly way. I am hopeful that PSIs are generally >> going to be presented to users as pick lists of names, etc. where the >> actual mechanics aren't really visible. Not unlike picking a font for a >> text. All sorts of things have to go right for that to happen but for >> the most part I am blissfully unaware of them. The use of PSIs should be >> the same. >> > > Agreed. But consistency and expectation will be important fallback > mechanisms to rely on should there be no user interface. > > +1! >> And I may be mistaken but I have the definite impression that I have >> encountered reuse of an element or attribute name, which would required >> the use of element/attribute in the path to disambiguate it. >> > > But even if the same name is used for both an attribute and an > element, if you categorically always put attributes "under" elements > in the PSI path structure, there is no ambiguity. There are no > "top-level" attributes in the PSI scheme. > > True. And that regularity could help with interfaces that want to present pick lists of elements or attributes to users. Thanks! Hope you are looking forward to a great weekend! Patrick > I hope this helps. > > . . . . . . . . . . Ken > > -- > XSLT/XQuery/XSL-FO hands-on training - Oakland, CA, USA 2009-08-03 > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/t/ > Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video > Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 > Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 > G. Ken Holman mailto:gkholman at CraneSoftwrights.com > Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/t/bc > Legal business disclaimers: http://www.CraneSoftwrights.com/legal > > _______________________________________________ > topicmapmail mailing list > topicmapmail at infoloom.com > http://www.infoloom.com/mailman/listinfo/topicmapmail > > -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From patrick at durusau.net Wed Jul 29 07:59:23 2009 From: patrick at durusau.net (Patrick Durusau) Date: Wed, 29 Jul 2009 07:59:23 -0400 Subject: [sc34wg3] irreflexive isa Message-ID: <4A70399B.7020102@durusau.net> Greetings! Some time ago the question of the irreflexive isa was posted as an issue with the TMRM. See: http://www.isotopicmaps.org/pipermail/sc34wg3/2009-April/004141.html I have responded that I think a broader definition of ins includes the more restrictive one of the TMRM, but I also pinged my co-editors for their takes on this issue. Barta responds that the TMDM has the same restrictive definition of isa: > > And I see now that TMDM does that too: > > http://www.isotopicmaps.org/sam/sam-model/#sect-types > > A topic type is a subject that captures some commonality in a set > of subjects. > > According to "normal" set theory, the set is never part of itself. In > other words, the isa relation between the set and elements of that set > is always is irreflexive. > > And further it strengthens also > > .... A topic type may itself be an instance of another topic type, .... > > It does not say > > .... be an instance of any other topic ... > > TMDM uses the word ... another ... > > So it is fair to assume that irreflexive is intended. > So, if this is an issue with the TMRM, it appears to equally be an issue with the TMDM. Hope everyone is having a great day! Patrick -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From larsga at garshol.priv.no Wed Jul 29 08:11:04 2009 From: larsga at garshol.priv.no (Lars Marius Garshol) Date: Wed, 29 Jul 2009 14:11:04 +0200 Subject: [sc34wg3] irreflexive isa In-Reply-To: <4A70399B.7020102@durusau.net> References: <4A70399B.7020102@durusau.net> Message-ID: <93E8225C-30CC-4D15-8962-30E53F47D1A9@garshol.priv.no> * Robert Barta > > And I see now that TMDM does that too: > > http://www.isotopicmaps.org/sam/sam-model/#sect-types > > A topic type is a subject that captures some commonality in a set > of subjects. > > According to "normal" set theory, the set is never part of itself. In > other words, the isa relation between the set and elements of that set > is always is irreflexive. Actually, this is not a violation of set theory. Here is what we have: A topic type: a subject that captures some commonality in a set of subjects A set of subjects: basically, the instances of the topic type Now, you'll note that the topic type itself is not described as a set, but rather as "a that captures a commonality". So if the topic type were an instance of itself, the set would contain the topic type, yes, but it wouldn't be a set containing itself. So I don't see any problem here. --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/ From patrick at durusau.net Wed Jul 29 09:36:12 2009 From: patrick at durusau.net (Patrick Durusau) Date: Wed, 29 Jul 2009 09:36:12 -0400 Subject: [sc34wg3] irreflexive isa In-Reply-To: <93E8225C-30CC-4D15-8962-30E53F47D1A9@garshol.priv.no> References: <4A70399B.7020102@durusau.net> <93E8225C-30CC-4D15-8962-30E53F47D1A9@garshol.priv.no> Message-ID: <4A70504C.5090902@durusau.net> Lars, Lars Marius Garshol wrote: > * Robert Barta > >> And I see now that TMDM does that too: >> >> http://www.isotopicmaps.org/sam/sam-model/#sect-types >> >> A topic type is a subject that captures some commonality in a set >> of subjects. >> >> According to "normal" set theory, the set is never part of itself. In >> other words, the isa relation between the set and elements of that set >> is always is irreflexive. >> > > Actually, this is not a violation of set theory. Here is what we have: > > A topic type: a subject that captures some commonality in a set > of subjects > > A set of subjects: basically, the instances of the topic type > > Now, you'll note that the topic type itself is not described as a set, > but rather as "a that captures a commonality". > > So if the topic type were an instance of itself, the set would contain > the topic type, yes, but it wouldn't be a set containing itself. > > So I don't see any problem here. > > Well, there isn't a problem because apparently both the TMDM and TMRM use irreflexive isa. Note the rest of Robert's post noted: > And further it strengthens also > > > > .... A topic type may itself be an instance of another topic type, .... > > > > It does not say > > > > .... be an instance of any other topic ... > > > > TMDM uses the word ... another ... > > > > So it is fair to assume that irreflexive is intended. Had reflexive isa been intended the language would read: "A topic type may be an instance of itself or of another topic type." In any event, this is a mapping question between the TMDM and the TMRM. BTW, the TMRM is not an attempt to be a universal data model (from your original post on this issue). It is an attempt to describe the disclosure of the subjects that make up any data model (and by extension the subjects that data model represents). Quite a different thing. Integration requires 1) that everyone use the same data model (highly unlikely) or 2) disclosure of the subjects that make up data models (and the subjects they represent) so that reliable mappings can be created between them. The TMDM defining a way to create mappings between identified subjects, for instance. But that requires a definition of a means of identification and definitions of equivalence, for which the TMRM defines disclosure but doesn't define itself. The latter seems more feasible to me but that should come as no surprise. Hope you are having a great day! Patrick PS: Breaking for meetings. Won't be back online, reliably, until this evening my local time. (East Coast, US) > --Lars M. > http://www.garshol.priv.no/tmphoto/ > http://www.garshol.priv.no/blog/ > > _______________________________________________ > sc34wg3 mailing list > sc34wg3 at isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > > -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) From patrick at durusau.net Thu Jul 30 06:18:21 2009 From: patrick at durusau.net (Patrick Durusau) Date: Thu, 30 Jul 2009 06:18:21 -0400 Subject: [sc34wg3] Very rough draft of possible proposal for 13250-1/TR Message-ID: <4A71736D.9060909@durusau.net> Greetings! I have posted a very rough draft of a possible proposal for ISO 13250-1 or a TR to replace that part of the standard. http://www.durusau.net/publications/tm_index_intro_0.10.pdf The *real* draft is due mid-August for the SC 34 meeting in September but I wanted to post this pre-draft version to get as much feedback as possible. The actual ISO draft will be posted to the document repository. The basic theme of the document is to start where topic maps started, with indexes and to take a fairly simple example forward through the various parts of the standard. Three observations: 1) Yes, there could be more examples but one of my goals is to have a framework into which *other* index examples from other fields could be easily inserted. If people identify subjects differently, doesn't it stand to reason that they will respond to examples differently? That is to say that examples from their areas of interest are likely to be more compelling? 2. Yes, there needs to be use of the examples under TMCL, TMQL and a strong conclusion. I just ran out of time and wanted to get this posted. 3. No, no I haven't proofed it for typos, spelling/grammar errors, errors in the examples or syntax. I just typed it out and pasted in suggestions from Naito-san and others and posted it. This is truly a "rough" draft. ;-) I do think this document needs to be short enough for a person to read in say 20 or so minutes so that puts the page limit somewhere between 18 to 25 pages. Hope everyone is having a great week! Patrick -- Patrick Durusau patrick at durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)