[topicmaps-comment] re: subject identity

[Ivan Uemlianin <ivan@jurakm.com>]

RESPONSE TO REPLIES:


Thanks for all responses, clarifications, etc., especially on the use of 
mergeMap and the importance of human intuition in topic map design. 
Apologies for the vaguenesses in my syntax - I had actually intended the 
two topics to be about the jpg file itself (topic1 about jpg-as-image, 
topic2 about jpg-as-code) -I'm glad my query got across despite these.

Upon reflection - aided by Kal Ahmed's comments - it seems that the 
problem I was trying to articulate is simply the problem of opaque 
contexts (e.g. If I have beliefs about the Morning Star, that doesn't 
necessarily mean I have applicable beliefs about the Evening Star or the 
planet Venus; because I may not have the belief that the three names 
denote the same object).  This issue is relevant for topic maps when 
we're trying to make inferences about scoped entities.  The problem is 
addressed by the scoping facility of mergeMap - provided that defining 
the topicMap as the context gives you enough granularity.

<nb re="mergeMap">
In the XTM spec Appendix F.5.1 Topic Merge Operation, Postcondition 7 
states that topics no longer exist after having been merged.  This is 
problematic, and the association implementation of mergeMap in TM4J 
mentioned by Kal Ahmed seems preferable.

 > > - mergeMap creates associations between elements
 > >   and does not delete topics.
 > Implement it that way by all means! TM4J does...plug, plug ;-)
</nb>

For other contexts, a scoping property of topics would be useful, as 
Thomas Passin suggests.  I posted earlier on this, so all I'll say here 
is that the 'syntactic shorthand' provided in ISO 13250 (i.e. 
topic@scope) might be written out in 'longhand' in XTM as something like 
this:

<topicMap>

   <topic id="lc">
     <subjectIdentity>
       <subjectIndicatorRef
        xlink:href="http:"www.biogs.org/~123456789012.html"/>
     </subjectIdentity>
     <baseName>
       <baseNameString>Lewis Carroll</baseNameString>
     </baseName>
   </topic>

   <topic id="cd">
     <subjectIdentity>
       <subjectIndicatorRef
        xlink:href="http:"www.biogs.org/~123456789012.html"/>
     </subjectIdentity>
     <baseName>
       <baseNameString>Charles Dodgson</baseNameString>
     </baseName>
   </topic>

   <association id="a1">
     <instanceOf>
       <topicRef xlink:href="#topicScopingAssociation"/>
     </instanceOf>
     <member>
       <roleSpec>
         <topicRef xlink:href="#topicBeingScoped"/>
       </roleSpec>
       <topicRef xlink:href="#lc"/>
       </member>
     <member>
       <roleSpec>
         <topicRef xlink:href="#scopingTopic"/>
       </roleSpec>
       <topicRef xlink:href="#childrensLiterature"/>
     </member>
   </association>

   <association id="a2">
     <instanceOf>
       <topicRef xlink:href="#topicScopingAssociation"/>
     </instanceOf>
     <member>
       <roleSpec>
         <topicRef xlink:href="#topicBeingScoped"/>
       </roleSpec>
       <topicRef xlink:href="#cd"/>
     </member>
     <member>
       <roleSpec>
         <topicRef xlink:href="#scopingTopic"/>
       </roleSpec>
       <topicRef xlink:href="#predicateCalculus"/>
     </member>
   </association>

</topicMap>

As the topics in this topic map refer to the same object, they could be 
merged.  Once this is done however, each of the characteristics of the 
new topic will have to be scoped under either "childrensLiterature" or 
"predicateCalculus", similarly with associations in which the new topic 
plays a role (excluding things like birthday - assuming pseudonyms have 
such things).  Something like the form given (i.e. leaving the topics 
unmerged, or at most forming a 'merge association' between the two) 
might be more intuitive, as well as saving on typing.