[sc34wg3] Issue merge-srcloc-vs-subjid

[Jan Algermissen]

Lars Marius Garshol wrote:
> 
> * Jan Algermissen
> |
> | I don't really know what a source locator is, but I assume it is the
> | URL of the <topic> element, yes?
> 
> Provided the topic was created from reading in a <topic> element that
> is correct. You can also assign source locators by other means, but
> this is the default use of them.
> 
> | Then (assuming map.xtm as the base URI for the map )
> |
> | <topic id="t1" />
> |
> | is the source (source element?) for a topic and the
> | topic will have the source locator map.xtm#t1, yes?
> 
> Correct.
> 
> | In addition to the source locator, a topic can have a set
> | of subject indicators and both can be used to refer to that
> | topic equally, yes?
> 
> Also correct.
> 
> | The approach that PM4TM [1] and the early RM [2] take is to make the
> | node demander locator a subject indicator too.
> 
> I know. We discussed this at length at several SC34 meetings and so
> far there has been agreement that source locators and subject
> identifiers need to be distinct. When you serialize a SAM instance to
> XTM you do not want to find <subjectIndicatorRef> references to all
> the source <topic> elements in that XTM.

Ah yes, I know that problem. 

I am actually not sure if it is a disadvantage to have that infomation,
but that's another story. Do you now just throw the source locators 'away' 
when exporting?

> 
> Therefore the model needs to maintain a distinction between true
> subject indicators and source elements so that it can do the
> reserialization correctly.
> 
> What this issue is about is what to do when a locator appears in both
> roles: it's both used as a subject identifier *and* as a source locator.
> 
> | I am not sure if this is of any help, but maybe...
> 
> Well, essentially what you've done is to point out that I left out one
> possible resolution from my list of proposed resolutions: to merge
> the notions of source locators and subject identifiers. It *is* a
> possible choice, but would entail being unable to distinguish between
> references to <topic> elements and references to true subject
> indicators.
> 
> It would also mean that most XTM exports would contain at least one
> junk <subjectIndicatorRef> for every <topic> element and that repeated
> roundtripping would cause the set of junk references to grow with each
> roundtrip.

I once thought about using this for tracking the versions of the map....
also another story, I know ;-)


Jan


> 
> Admittedly it is less elegant than it could be to have three kinds of
> URIs for topics, it's just that I can't see any cure for this disease
> that is less harmful than the disease itself.

> 
> --
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@acm.org
Web:   http://www.topicmapping.com