[sc34wg3] Issue merge-srcloc-vs-subjid

[Lars Marius Garshol]

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 >