[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] An way to avoid id clashes (WAS: Merging proposals u ploaded)
I think we are beginning to see very clearly here (below) the potentially serious limitations of concentrating on syntactic forms of topic maps - however useful they are in other ways. In the broader sense of "Topic Map" which is emerging below, there will inevitably be topic maps which are only conceptual models. There will be multiple-layered topic maps where eg one topic map over a suite of resources becomes one of many base resource sets for another topic map with different intent. There could be many of these layers - much richer structures than can be represented usefully all-in-one as TM-interchange-syntax. I had this area shelved for now, hoping XTM 1.0 would succeed in pinning down a pretty basic first-level interchange syntax - maybe we should still do that? I firmly believe that the Topic Map concept is much much "bigger" than any interchange syntax - about in the same ratio as the full relational model and RDBMS concepts are "bigger" than simple named-tuples used to export/import tables. But, interchange v. important, and a key brick-in-the-wall at this stage - especially to achieve acceptance and immediate usefulness, and be something that lots of our potential market can understand right now. So, (please?) we must continue to work towards a (simple as it can be) XTM 1.0 syntax, whilst also looking forwards towards model-conformance, layered map architectures, etc etc. Ann W. > -----Original Message----- > From: Peter Jones [mailto:peterj@wrox.com] > Sent: 20 October 2000 11:28 > To: 'xtm-wg@egroups.com' > Subject: RE: [xtm-wg] An way to avoid id clashes (WAS: > Merging proposals > u ploaded) > > > Thanks Kal, > > I did actually click last night that it worked like that, and > tried to send > you a mail to that effect but it bounced. oh well... > > OK. Then, yes, I agree that this is one way to cure the problem. > However, I am inclined to think that your solution has two > aspects that > worry me: > 1) It is like using a pile driver to squash an ant. > 2) Writing all that information into the linking structure of > the document > might risk complicating subsequent inclusions. It concerns me > that those id > strings might end up looking like UUIDs in the Web > environment at a later > stage. > > this brings me back to > >Isn't this just about declaring namespace info for IDs in each map ? > > It seems to me that what we are trying to do here is add > metadata over the > packaged map, a topic map over the topic maps in the package > if you will. > All of which brings me back to a suggestion I posted to the > list earlier on. > > > <insert> > Just thought I'd chuck an idea on this into the pond. It > seems to me that > you could think of all XML Namespace information that is > contained in a > namespaced doc instance as something like an aggregate link, > and therefore > not dissimilar from a scope in the BOS (which I believe > several folks have > suggested can be implemented as topic/association). > What I mean is that instead of prefixing everything you suck all that > information out into a single reference point that _points_ at all the > things that it is "namespacing" and says, "these things are in this > namespace if you really need to know that. > This might of course require the XTM community to define a > public topic for > the purpose at some time. > </insert> > > I seems to me to be an obvious point that folks are going to > start using the > power of topic maps to say things about topic maps at some > point (because > topic maps are so wonderful that we can do lovely things like > that!), so > a) why shouldn't we, as the standard makers be the first to do so, and > b) it seems an obvious consequence of this that some topics > are going to be > More Meta Than Most in this second-order topic mapping -- the > concept of > namespace being one IMHO. > > Therefore, in light of the fact that id clashes are unlikely > to be that > numerous, and that shoving lots of extra prefixes in possibly > risks muddying > the waters for later, could we do the following instead. > > 1)When an xtmdoc package is produced a More Meta Than The > Rest topic map > should be included that contains the following: > a) A set of Namespace topics (where 'Namespace' is a Public > Topic) one for > each topic map in the package. > b) Each Namespace topic contains the original URL of the > document as its > identity, is of type="Namespace", and has as an occurrence > the address of > the topicmap in the package. Such a Namespace topic can > contain any number > of different types of namespace information (XML Namespace, ID clash > mappings, doc origins, &c, in different TM scopes). > c)Each Namespace topic also has as occurrences a set of > associations that > describe the relations between any id attributes that have > been remapped to > a new value and their new values in the package in the > process of removing > clashes (so the reassignment is reversible). Likewise the IDREFS. > d) anything else sensible that would make this proposal work > that my poor > brain can't think of just now > > This way the set of remappings is minimal, and the package remains > relatively clean for for future mergers further down the > line. The remapping > information is also available at the topic map level, not > internal system > dig down. > > Thoughts anyone? > > Peter > > -----Original Message----- > From: Kal Ahmed [mailto:kal@ontopia.net] > Sent: 19 October 2000 17:33 > To: xtm-wg@egroups.com > Subject: RE: [xtm-wg] Merging proposals uploaded > > > If you have two topic maps with something like: > > <topic id="ab4765>...</topic> > <topic type="#ab4765" ...>...</topic> > > and one topic map which refers to the other topic map > directly like this: > > in both, then by the packaging rules, you end up with > <topic type="http://www.someurl.com/foo/bar.xtm#ab4765" > ...>...</topic> > > <xtmdoc> > > <redirect tmid="topicmap1" > tmbase="http://www.xyzcorp.com/topicmaps/basic_ontology.xtm" > idprefix="tmA_"/> > <topicmap id="topicmap1"> > <topic id="tmA_ab4765">...</topic> > <topic type="ab4765">...</topic> > </topicmap> > > <redirect tmid="topicmap2" > tmbase="http://www.xyzcorp.com/topicmaps/my_topicmap.xtm" > idprefix="tmB_"/> > <topicmap id="topicmap2"> > <topic id="tmB_ab4765">...</topic> > <topic type="ab4765">...</topic> > <topic > type="http://www.xyzcorp.com/topicmaps/basic_ontology.xtm#ab47 > 65">...</topic > > > </topicmap> > > </xtmdoc> > > At unpacking time, by reading the tmbase and idprefix > attributes, I can > create an internal table that maps any occurrence of > http://www.xyzcorp.com/topicmaps/basic_ontology.xtm to the id > prefix "tmA_", > so I know that the external reference in the second topic map > in the package > is actually internal to the package and is found in the first > topic map. > Also, when processing the ID/IDREFs within a topicmap > document in a package, > I will need to prepend the prefix to the IDREF value, so in the first > topicmap, 'type="ab4765"' will be located as "tmA_ab4756" and > in the second > map it will be "tmB_ab4765". > > BTW, this also works for relative addressing to as tmbase > actually declares > the base URL for performing the processing, so the last topic > in the second > map could have been encoded as: > <topic type="./basic_ontology.xtm#ab4765"> > You would convert that to a fully specified path by applying > the relative > path to the tmbase of the topic map which contains the > reference, then use > that to determine if you are referring to another packaged topic map. > > Forward references can be easily handled by creating a stub topic and > postponing resolution to an external topic map until after > the xtmdoc has > been processed in its entirety. > > Cheers, > > Kal > > > -----Original Message----- > > From: Peter Jones [mailto:peterj@wrox.com] > > Sent: 19 October 2000 16:04 > > To: 'xtm-wg@egroups.com' > > Subject: RE: [xtm-wg] Merging proposals uploaded > > > > > > sorry, use of URL path was a boob. > > > > but any id string will do. > > > > peter > > > > -----Original Message----- > > From: Peter Jones [mailto:peterj@wrox.com] > > Sent: 19 October 2000 15:57 > > To: 'xtm-wg@egroups.com' > > Subject: RE: [xtm-wg] Merging proposals uploaded > > > > > > >to be useful you still need to be able to make > > >globally (in the scope of xtmdoc) unique identifiers > > > > Yes. my question was, how does your mechanism cope with the > case where two > > distinct maps from different contexts both refer to > > id="/foo/bar.xtm#ab4756" > > by pure accident ? > > > > you have to look at the contexts of the two TMs whatever, don't you? > > > > Peter > > > > -----Original Message----- > > From: Kal Ahmed [mailto:kal@ontopia.net] > > Sent: 19 October 2000 15:49 > > To: xtm-wg@egroups.com > > Subject: RE: [xtm-wg] Merging proposals uploaded > > > > > > Yes...well, sort of yes - to be useful you still need to be > able to make > > globally (in the scope of xtmdoc) unique identifiers, and to resolve > > references between packaged topic maps (without requiring the > > package reader > > to go to the original source of the packaged tm). Hence the > > modifications to > > the content model of xtmdoc. I think that with these > modifications (or > > something like them), what you want to do will be possible > and I can think > > of usecases where such a facility would be useful. I think my > > real point is > > that **without** those modifications, you would not be > really solving the > > packaging problem. > > > > Kal > > > > PS I can see techquila.com becoming a 'topic map merging > service' ... send > > me your packages and I'll send you a single merged tm. Now > I just have to > > work out a pricing structure ;-) > > > > > -----Original Message----- > > > From: Sam Hunting [mailto:sam_hunting@yahoo.com] > > > Sent: 19 October 2000 15:23 > > > To: xtm-wg@egroups.com > > > Subject: RE: [xtm-wg] Merging proposals uploaded > > > > > > > > > [kal writes] > > > > 3) A proposal for handling xtmdoc. ... [T]here is also > a need for > > > > ensuring that the packaging and unpackaging can actually be done > > > > simply. ... BTW, I feel that packaging tms is a really > weak argument > > > > considering that the merging and scoping mechanisms can > be trivially > > > > combined to do tm packaging > > > > > > Packaging into xtmdoc is wicked simple, because it could > be done with > > > an XML editor, or even a text editor. One could, of > course, use the > > > usual entity mechanisms. > > > > > > Contrariwise, packaging TM with a scoping and merging > mechanism is not > > > wicked simple, because it cannot be done with an XML > editor or text > > > editor. > > > > > > Alternatively, I'm missing some subtle point obvious to > all but me. > > > > > > S. > > > > > > > > > > > > > > > ===== > > > <? "To imagine a language is to imagine a form of life." > > > -- Ludwig Wittgenstein, Philosophical Investigations ?> > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! Messenger - Talk while you surf! It's FREE. > > > http://im.yahoo.com/ > > > > > > > > > To Post a message, send it to: xtm-wg@eGroups.com > > > > > > To Unsubscribe, send a blank message to: > xtm-wg-unsubscribe@eGroups.com > > > > > > > > > > > > > > > > > To Post a message, send it to: xtm-wg@eGroups.com > > > > To Unsubscribe, send a blank message to: > xtm-wg-unsubscribe@eGroups.com > > > > > > To Post a message, send it to: xtm-wg@eGroups.com > > > > To Unsubscribe, send a blank message to: > xtm-wg-unsubscribe@eGroups.com > > > > > > To Post a message, send it to: xtm-wg@eGroups.com > > > > To Unsubscribe, send a blank message to: > xtm-wg-unsubscribe@eGroups.com > > > > > > > > > > To Post a message, send it to: xtm-wg@eGroups.com > > To Unsubscribe, send a blank message to: > xtm-wg-unsubscribe@eGroups.com > > -------------------------- eGroups Sponsor > -------------------------~-~> > Last minute trips at > first-rate discounts > from Hotwire. > http://click.egroups.com/1/9748/4/_/337252/_/972037542/ > -------------------------------------------------------------- > -------_-> > > To Post a message, send it to: xtm-wg@eGroups.com > > To Unsubscribe, send a blank message to: > xtm-wg-unsubscribe@eGroups.com > -------------------------- eGroups Sponsor -------------------------~-~> Your family still won't know what you do. At least they'll know where. The resources, brainpower & breadth of opportunities at Microsoft are unmatched. The only question is are you ready for that kind of impact? http://click.egroups.com/1/9223/4/_/337252/_/972039529/ ---------------------------------------------------------------------_-> To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC