RE: [Tm4j-developers] Normalising ID and resourceID

[Kal A. <ka...@te...>]

>
> > I've been reviewing the way in which TM4J's import and export
> functionality
> > handles the resolution and normalisation of IDs and references
> and I would
> > like to get feedback on my thoughts before implementing anything.
> >
> > Firstly, all TopicMapObjects have two separate 'identifiers':
> >
> >   ID property: Assigned by the import process.
> >                Guarunteed to be unique across all objects in the same
> > TopicMap
> >                Should be stored as the ID only (not as a full URL)
> >
> >   resourceID property: The URI of the XML element which gave rise to the
> > creation
> >                          of the object.
> >                        Stored as a complete URI (many different
> topic map
> > documents
> >                          may contribute objects to a single TopicMap.
> >                        May be NULL
> >                        Guarunteed to be unique across all objects in the
> > same TopicMap.
> >
> > Then TopicMaps have three additional associated URIs:
> >
> >   baseURL property: The URL which should be treated as the URL
> of the topic
> > map in
> >                       its entirety. All objects in the topic
> map can then be
> >                       addressed as <baseURL>#<ID>.
> >                     This is currently not a required property of the
> > TopicMap, but
> >                       it probably should be.
> >
> >   xml:base : The (optional) value of the xml:base attribute of the
> >                <topicMap> element.
> >              Used only during parsing to resolve references to external
> > documents.
> >
> >   sourceURL: Not stored as a property of the TopicMap, but just
> used when
> > parsing
> >                a source document.
> >              Used only during parsing to resolve the value of the id
> > attribute
> >                of an element into a full URI for storing as the
> resourceID
> >                property of a TopicMapObject
> >              Used to resolve references to external documents
> if baseURL is
> > not
> >                specified
> >
> > Addressing into a topic map held in a TM4J system may require a
> > backend-specific URI to identify the store. However, once a
> connection is
> > made to a TM4J store, I think it should be possible to query the
> > TopicMapProvider interface to retrieve a TopicMapObject by
> specifying a URL
> > constructed of the baseURL property of the TopicMap and the ID
> of the object
> > required.
> >
> > What I have described in the foregoing is not exactly the way that TM4J
> > behaves right now, partially because I didn't properly understand the
> > purpose of xml:base and partly because before the Ozone implementation,
> > there was no real need to consider a TM4J system that kept
> track of multiple
> > topic maps simultaneously.
> >
> > So, my questions to y'all are: Does this sound reasonable to
> everyone ? Is
> > there something else missing from this list ?
>
> One problem that I see is when to use the ID and when the resourceID.
> I mean if I reference a topic in another topicmap I would write
> <baseURL of th TM>#<ID of the topic>. But could it also be possible
> to use the resourceID instead of the ID ? And if so, how do we
> differentiate both versions or is this up to the target topic map ?
>

The problem is that one TopicMap object could be generated from multiple XTM
files, and so it will actually contain a set of resourceIDs from each of the
different document bases.
It is definitely necessary for references to be able to use resourceID as
easily as possible as those should be considered to be the "external" ID of
the object - and are the only ID that the topic map author has some control
over before TM4J processes the topic map.

> We could say the <baseURL>#<some id> means that <some id> is an ID
> and <xml:base URL>#<some id> means that <some id> is a resourceID.
> But the baseURL and <xml:base> can be the same, e.g. if there is
> no <xml:base> in the XTM file. The solution could a different
> syntax for both versions, e.g. <baseURL>/ID#<some ID> references
> the ID of topic and <baseURL>#<some ID> the resourceID.
>

This could be a neat way of working. Again, I would be in favour of not
munging the resourceIDs. So I would suggest that you access a topic map
object by resourceID by simply asking for the full URL of the resource. To
access by ID use <topic map baseURL>?id=<ID>.

What this means in practice is that topic map authors will probably always
use the resourceID form of reference when working with XTM files locally,
but may prefer to use the TopicMapObject ID form of reference when creating
an XTM file that is to be merged with a topic map already stored in a TM4J
server. Obviously, the second form of reference really only makes sense with
a persistent store.

What I like about this approach is that it could then be extended a little
further to handle a "topic map server" application managing multiple topic
maps so that the URL <topic map server base>?topicmap=<topicmap
id>&id=<object ID> could be mapped by the topic map server into <topic map
baseURL>?id=<ID>

> We could also say that if there is a resourceID given by the XTM
> file then the ID of the topic must be the same as the resourceID.
> But then it will be hard to insure the uniqueness if the ID.
>

I would prefer not to have to enforce unique IDs across all possible source
XTM files. It could make life very difficult for applications which are
combining multiple XTM files from different sources.

Cheers,

Kal