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

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

  -----Original Message-----
  From: tm4...@li...
[mailto:tm4...@li...]On Behalf Of Jack Park
  Sent: 25 June 2001 20:17
  To: tm4...@li...
  Subject: Re: [Tm4j-developers] Drill-down topic maps


  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.

All TopicMapObjects stored in a given persistent topic map have an object ID
assigned to them. So the URI for any TopicMapObject in the persistent store
would be the baseURL of the TopicMap with the object ID appended as a
fragment identifier. TopicMapObjects also have their sourceURL stored with
them (this is really to maintain the provenance of a topic map object and is
not intended to be a means of locating it). An application wishing to
resolve a URI to a topic map object would have to first split the URI into
the document part and the fragment identifier part, then look in the
TopicMapManager for the topic map with that ID.


  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?

It is not a general enough solution to do this - essentially, the smarts
would be an integral part of the application. Perhaps what you are after
here is a generic interface for resolving a locator with some selection of
the locator resolution mechanism based on the occurrence type ? The
TopicMapManager interface isn't intended to do that (although it does
provide the hooks to enable a mechanism which does do it).

Cheers,

Kal

  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