[sc34wg3] TMDM bug

[Lars Marius Garshol]

It turns out there is a bug in the TMDM FCD. We'll discuss and correct
it; I just wanted people to be aware of it.

Ontopia's test suite contains the following nice XTM file, which turns
out to have a nasty TMDM representation:

  <topicMap ...>
    <topic id="C">
     <subjectIdentity>
       <resourceRef xlink:href="http://www.example.com"/>
       <topicRef xlink:href="#B"/>
       <subjectIndicatorRef xlink:href="#B"/>
     </subjectIdentity>
    </topic>
  </topicMap>

This creates a topic map with one topic item, and that topic item has
itself as the value of the [reified] property. Clearly that doesn't
make much sense. 

Admittedly, this is a pretty pathological XTM file, but it turns out
that this case is more common than might be thought, because the
following XTM file will produce an identical TMDM instance.

  <topicMap ...>
    <topic id="C">
     <subjectIdentity>
       <resourceRef xlink:href="http://www.example.com"/>
       <subjectIndicatorRef xlink:href="#B"/>
     </subjectIdentity>
    </topic>

    <topic id="B"/>
  </topicMap>

This might not be obvious at first glance, but the fourth point in the
equality rule for topics causes C and B to merge, and since B has a
"#B" source locator, this gives the same result as the first XTM file.

What this means is that whenever two topics merge because one reifies
the other (according to XTM syntax rules) the resulting topic item
will have itself as the value of the [reified] property.

I guess what we should do is modify the computation rule for [reified]
so that it states that the reified information item cannot be the
topic itself.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >