Re: [Tm4j-developers] Drill-down topic maps

[Jack P. <jac...@th...>]

I am wondering if this isn't akin to a much larger problem: addressing any 
information resource.  In theory, just assign a URI to anything and assume 
there is some engine (Grove?) that knows what to do with it.

Robert Barta gave this code in a post to topicmapmail:

<topic id="m-xtm">
<baseName>
<baseNameString>Topic Map Arena</baseNameString>
</baseName>
<instanceOf><topicRef xlink:href="urn:x-tm-map"/></instanceOf>
<occurrence>
<instanceOf><topicRef xlink:href="urn:x-tm-knowledge"/></instanceOf>
<resourceRef xlink:href="http://topicmaps.bond.edu.au/examples/xtm.xtm"/>
</occurrence>
<occurrence>
<instanceOf><topicRef xlink:href="urn:x-tm-continuation"/></instanceOf>
<resourceRef xlink:href="m-xtm%23t-topic-maps"/>
</occurrence>
<occurrence>
<instanceOf><topicRef xlink:href="urn:x-tm-description"/></instanceOf>
<resourceData>some collected material, far from being in any way 
'complete'</resourceData> </occurrence>
</topic>

and says that this page: http://topicmaps.bond.edu.au/maps.mc
is driven by the above code.  His server is able to tell what the 
occurrence type is.

But, what about an occurrence that happens to be stored in your local 
persistent store?  How do you reference it?  Particularly, how do you 
reference it such that others could, at a minimum, write and ask you for a 
copy--given that you might have published the topic map on the web or sent 
it off for merging elsewhere.

Right now, I am using typed occurrences and I am willing to make my 
persistentXTM implementation smart enough to check type before accessing an 
occurrence.  Kal's interface suggestion looks interesting.  Can it be 
viewed as a general enough solution that we could then generate PSI's for a 
variety of occurrence types, turning an XTM engine into a kind of grove engine?

Cheers
Jack

At 08:23 PM 6/25/2001 +0200, you wrote:
>On Mon, 25 Jun 2001 16:54:03 +0100
>"Kal Ahmed" <ka...@te...> wrote:
>
> > I think that the solution to this problem lies in something that Gerd and I
> > discussed briefly a little while ago and that is creating a more 
> generic way
> > to create and access TopicMap objects. We already have the TopicMapFactory
> > interface, which at least provides a generic means of creating topic map
> > objects regardless of the back-end. However, I think that what we also need
> > is a TopicMapManager interface which would enable a back-end to provide a
> > generic interface for accessing and creating TopicMap objects.
> >
> > I am thinking of an interface something like this:
> >
> > import com.techquila.topicmap.*;
> > import java.util.*;
> >
> > public interface TopicMapManager {
> >
> >   public TopicMapManger();
> >   public void initialise(Properties) throws TopicMapManagerException();
> >   public TopicMap getTopicMap(String sourceURL);
> >   public Collection getTopicMaps();
> >
> > }
> >
> > The init() function takes a java property set, which would enable any
> > back-end specific initialisation to be passed en-masse (and so manage 
> things
> > like establishing a database connection and setting up internal caches).
> > Perhaps an additional function to set properties one-by-one might also be
> > useful.
> >
> > The getTopicMap() function returns a topic map whose sourceURL property
> > matches that specified in the parameter.
> > The getTopicMaps() function returns all of the TopicMap objects that the
> > manager knows about.
> >
> > Jack, you should then be able to get the referenced topic map by checking
> > with the TopicMapManager (equates to the XTMSession object I guess).
> > Although your topic map will still need to use the full URL for referencing
> > the topic map as an occurrence (or else your code needs to have some smarts
> > to recognise how to process the occurrence according to its type).
> >
> > How does this sound ?
>
>Sounds good so far. This brings another idea to my mind: What about
>distributed topic maps ? E.g. an association in topicmap A could have
>a type that is defined in a topicmap B somewhere. It would be cool
>to manage this transparently for the application, e.g. be topic
>proxies or something like that.
>
>Best Regards,
>Gerd
>
>--
>________________________________________________________________
>Gerd Mueller                                    ge...@sm...
>SMB GmbH                                  http://www.smb-tec.com
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>http://lists.sourceforge.net/lists/listinfo/tm4j-developers