[sc34wg3] Issue merge-srcloc-vs-subjid

[Jan Algermissen]

Lars--

I think I can't really help you, but I can tell you how the RM
handles this and maybe that helps you in finding a solution.

I don't really know what a source locator is, but I assume it
is the URL of the <topic> element, yes?

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?

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?

In the RM, an element that is the 'source' for a node is called a
"node demander" since its existence in the markup demands the
existence of a node in the graph. That way, a piece of markup can reference
another piece of markup and be sure, that there 'is a node at the other end'.

The RM Section that addresses this issue is 

5.2.10.3 Facilities for indirect node addressing via syntactic
         constructs

The approach that PM4TM [1] and the early RM [2] take is to make the node
demander locator a subject indicator too.

I am not sure if this is of any help, but maybe...

I don't know why the SAM makes a distinction between the set of subject
indicators and the source locator of a topic, could you explain that to me
or point me to an explanation? This may be an important issue for the
definition of the SAM in RM terms.


In order not to cause the wrong impression: The current RM does not require
that source elements (node demanders) be the same as subject indicators, it
just requires that any TM model (that 'includes' one or more syntaxes for the
interchange of topic maps) provides an assertion type that makes syntactic
addressing possible. 


Jan



[1] http://www.topicmaps.net/pmtm4.htm
[2] http://www.y12.doe.gov/sgml/sc34/document/0298R1.htm




Lars Marius Garshol wrote:
> 
> We settled this issue in Baltimore, but a customer just ran into a
> problem with the resolution we chose, so I'd like to revisit this to
> be sure we chose the right resolution to this issue.
> 
> If you want background, see these two links:
>   <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=merge-srcloc-vs-subjid >
>   <URL: http://isotopicmaps.org/pipermail/sc34wg3/2003-January/000841.html >
> 
> Basically, what happens is as follows. The customer has a topic map
> which uses sort names, and has an XTM <topic> which defines the sort
> name topic in exactly the right way:
> 
>   <topic id="sort">
>     <subjectIdentity>
>       <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#sort"/>
>     </subjectIdentity>
>     <baseName>
>       <baseNameString>sort</baseNameString>
>     </baseName>
>     <occurrence>
>       <instanceOf><topicRef xlink:href="#desc"/></instanceOf>
>       <resourceData>Suitability for sorting: Suitability of a topic name for use as a sort key; for use in the parameters of variant names.</resourceData>
>     </occurrence>
>   </topic>
> 
> Now, the customer also has <mergeMap>s to language.xtm and
> country.xtm, which in their turn have <topicRef>s to core.xtm, so that
> core.xtm gets loaded in. In core.xtm, of course, the topic appears one
> more time, with the same ID. core.xtm has been loaded from
> http://www.topicmaps.org/xtm/1.0/core.xtm, so this means that this new
> topic gets the same URI as its source locator that it already has as a
> subject identifier.
> 
> The resolution implemented in the OKS, and also agreed on by SC34 in
> Baltimore, is that in this case the URI is to be considered a source
> locator rather than a subject identifier. The result of that, however,
> is that when we sort topics we try to look up the sort name topic, so
> that we can pick the sort names and use those. We look it up by
> subject identifier only, however, and so we don't find it, even though
> it is there, and has the right URI.
> 
> The result is that the user gets a topic map where sorting does not
> happen by sort name as expected, and they send email to
> support@ontopia.net wondering why. And with good reason, as this
> problem is rather subtle.
> 
> As I see it, there are several possible choices:
> 
>  1) Tell the user: your topic map is wrong, you must fix it. (Note
>     that they have not referred to the subject indicator using a
>     <topicRef>; they just loaded the topic map over http.)
> 
>  2) Change our thinking, so that when looking for a topic by subject
>     identifier, we must also look for it by source locator.
> 
>  3) Turn the resolution around, so that referring to a <topic> using a
>     <subjectIndicatorRef> automatically promotes the URI of that topic
>     to subject identifier status. (The current resolution is to do the
>     opposite: demote subject identifiers to source locator status once
>     a <topicRef> to it is found.)
> 
> This is a really subtle issue that I feel we did not fully understand
> when discussing it in Baltimore, so I would really like to revisit it
> and make sure that we have gotten our resolution right. I had a long
> discussion with Geir Ove about this, but we didn't really manage to
> conclude it, and I'm hoping people on this list may have some insights
> that may help us.
> 
> --
> 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