Re: [Tm4j-developers] core xtm

[Kal A. <ka...@te...>]

At 12:44 22/02/2002 +1100, Smith, Tim wrote:
>Okay, I have been using <instanceOf> for parent-child relationships. On the
>topic map mail list someone said this was bad and the way to go was
> >    <association>
> >      <instanceOf><topicRef xlink:href="#parent-child"/></instanceOf>
> >      <member>
> >        <roleSpec><topicRef xlink:href="#parent"/></roleSpec>
> >        <topicRef xlink:href="#BA"/>
> >      </member>
> >      <member>
> >        <roleSpec><topicRef xlink:href="#child"/></roleSpec>
> >        <topicRef xlink:href="#BA1"/>
> >      </member>
> >    </association>
>I now have
><association>
>   <instanceOf><topicRef
>xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass"/>
></instanceOf>
>   <member>
>     <roleSpec><topicRef
>xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass"/></roleSpe
>c>
>     <topicRef xlink:href="#A-Parent"/>
>       </member>
>   <member>
>     <roleSpec><topicRef
>xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#subclass"/></roleSpec>
>     <topicRef xlink:href="#A-Child"/>
>     </member>
></association>
>HOWEVER as I understand it that would be dynamic interlinking/merging, which
>is not supported by TM4j (yet)
>CONSEQUENTLY am I required to redefine these 3 concepts with appropriate
>SIs, and if I do, will they STILL count as PSIs to TM4j (so I can check for
>PSI types)
>Puzzledly yours,
>Tim Smith

Actually, what you have specified is that the roleSpec is defined by a 
topic contained in the external topic map located at 
http://www.topicmaps.org/xtm/1.0/core.xtm. What TM4J will do is create a 
stub for that external topic which should have the full URI (e.g. 
http://www.topicmaps.org/xtm/1.0/core.xtm#subclass) as its resourceLocator.
If you have the latest CVS snapshot, which does now include some support 
for mergeMap and external topic reference processing, you should also find 
that "http://www.topicmaps.org/xtm/1.0/core.xtm is contained in the list 
returned by TopicMap.getExternalRefs(). You could then use 
TopicMapProvider.addTopicMap() to add the externally referenced topic map 
to you topic map (i.e. do the merge). If you do this, then calling 
Member,getRoleSpec().getResourceLocator() should return a locator whose 
address is http://www.topicmaps.org/xtm/1.0/core.xtm#subclass.

According to the XTM Processing Requirements of XTM 1.0, it is also equally 
valid to use a <subjectIndicatorRef> with the same URI (see XTM 1.0 Section 
F.3.1). If you do this, then calling 
Member.getRoleSpec().getSubjectIndicators() should return a collection 
containing a locator whose address is 
http://www.topicmaps.org/xtm/1.0/core.xtm#subclass

Finally, you can create a topic in your XTM file which has the URI as a 
subject indicator:

<topic id="mysubclass">
   <subjectIdentity><subjectIndicatorRef 
xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#subclass"/></subjectIdentity>
   <baseName><baseNameString>Sub-class</baseNameString></baseName>
</topic>

Then you refer to that topic in your roleSpec:

<association ... >
   <member>
     <roleSpec><topicRef xlink:href="#mysubclass"/></roleSpec>
   </member>
</association>

If you do this, the effect in TM4J is the same as simply embedding the 
<subjectIndicatorRef> in the <roleSpec> except that you have created a 
topic with a valid resourceLocator ({tm-base-uri}#mysubclass).

Eventually (like with the next release), I believe that 
Topic.getSubjectIndicators() should return a list containing all the 
explicitly defined subject indicators of the topic, plus all of the 
resourceLocators of the topic (as the upshot of Annex F is essentially that 
the URI of the topic should be treated as a subjectIndicator - and this is 
also a key part of PMTM4). In the meantime, you can cope with all of these 
(essentially equivalent) variations with code like this:

// Create Locators for the XTM PSIs
Locator subclassLoc = tm.getLocatorFactory.createLocator("URI", 
XTMPSI.SUBLCASS);
...

/**
  * Test if the specified Member plays a subclass role
  */
boolean isSubclass(Member m)
{
   Topic roleSpec = m.getRoleSpec();
   if (roleSpec == null) return false; // No role spec, so can't play 
subclass role
   // Check if PSI is one of the subject indicators of the roleSpec
   if (roleSpec.getSubjectIndicators().contains(subclassLoc)) return true;
   // Check if the PSI *is* the address of the roleSpec
   Locator resLoc = roleSpec.getResourceLocator();
   if ((resLoc != null) && (resLoc.equals(subclass)) return true;
   // If we get here, the roleSpec is not XTM subclass
   return false;
}


BTW - you called your relationships "parent-child". That can mean 
subclass-superclass (i.e. an instance of the subclass topic is also an 
instance of the superclass topic) or it can mean containment, or it can 
mean some other categorical hierarchy (e.g. broader-term/narrower-term in a 
thesaurus). Before going too far down this route, I would advise you to 
make sure that your definition of parent-child marries with the XTM 
definition of subclass-superclass.

Cheers,

Kal