RE: [xtm-wg] An way to avoid id clashes (WAS: Merging proposals u ploaded)

[Peter Jones <peterj@wrox.com>]

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#ab4765">...</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