tm4j-developers — Forum for issues related to development of TM4J.

[Tm4j-developers] Association.ofType()

[Gerd M. <ge...@sm...>]

The following situation: I have:

- Topic A

- Topic B

- Association C

- C is of type B

- B is of type A

Does this mean that C is of type B *and* A or is it only of type
B ? TM4J currently implements the second case.

And where is the difference between the base topic and the types
of a topic ?

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

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

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

At 06:11 PM 6/28/2001 +0200, you wrote:
><snip>
>NO !!! ;-)
>
> > is it the right package for a graph based universe?
>
>YES !!! ;-)
>
>ozone (http://www.ozone-db.org) is an *object-oriented database*, so
>you can store any Java-objects you like. The ozone implementation
>of TM4J is exactly the same as the transient part with some ozone
>compatiblity features. There is also the ozoneXML project that
>stores to DOM to provide an XML database, but IHMO it is the wrong
>way to store topicmaps as DOM.

Oh!  I guess I misinterpreted something I read last night while downloading 
the documents on Ozone-db, something about megaDom or monsterDom or 
somesuch.  I have a poor memory for such things.  I plan to use Ozone and 
think it to be of great value here.

>BTW: There is an interesting discussion regarding this topic at
>infoloom.
>

I've been following that, if you're talking about the topicmaplist.  Thanks
Jack

>Best Regards,
>Gerd

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

[Gerd M. <ge...@sm...>]

> >I would be happy to go with this. I'm on the road at the moment but will be
> >back home in a couple of days and able to get something started on this.
> 
> 
> All of this is making me think I might just ditch my rdbms xtm package and 
> go with TM4J.  One question (off this topic, however) remains: if Ozone is 
> DOM based, 

NO !!! ;-)

> is it the right package for a graph based universe?

YES !!! ;-)

ozone (http://www.ozone-db.org) is an *object-oriented database*, so
you can store any Java-objects you like. The ozone implementation
of TM4J is exactly the same as the transient part with some ozone
compatiblity features. There is also the ozoneXML project that 
stores to DOM to provide an XML database, but IHMO it is the wrong
way to store topicmaps as DOM. 

BTW: There is an interesting discussion regarding this topic at
infoloom.


Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

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

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

At 06:48 PM 6/26/2001 +0100, you wrote:
><snippage>
>
>For "topic map content types" this would work. For other content types,
>resolving the locator would involve a different interpretation of the
>fragment ID, and it would be nice to have some pluggable way of handling
>occurrences of any type or locator notation (in the topic map) and of any
>resource content type. However, I'm not sure that this is something which
>should be addressed by TM4J - I would prefer to see the development of a
>generic content addressing framework (such as a grove engine) as a separate
>project and integrate TM4J with that. Does anyone know of such a thing ?

Take a look at NODAL being written by Lee Iverson on behalf of Douglas 
Engelbart's OHS project.  View his latest draft at 
http://www.ai.sri.com/~leei/OHS/NODAL-WhitePaper.htm

His goal is something akin to a grove engine, complete with versioning and 
more.

> > Having said this, I would suggest the following interfaces:
> >
> > public interface TopicMapProviderFactory {
> >     public TopicMapProvider createTopicMap( Properties );
> > }
> >
> > public interface TopicMapProvider {
> >     public TopicMap getTopicMap();
> >     public String getURL();
> > }
> >
> > These two interface are necessary to intergrate a topicmap into a system.
> > With getTopicMap() I get the map handled by this provider. I'm not sure
> > if we need getURL() since TopicMap already has a getBaseURL() method.
> >
> > public interface TopicMapManager {
> >     public void initialise(Properties) throws TopicMapManagerException();
> >     public TopicMap getTopicMap(String sourceURL);
> >     public Collection getTopicMaps();
> >     public registerProvider( String providerFactoryClassName,
> > Properties );
> > }
> >
> > The TopicMapManager manages all TopicMapProviders known by a system. The
> > registerProvider() method adds a provider to the manager by using the
> > given factory class.
>
>This is a nice model, it would allow me to combine both in-memory
>(file-based) topic maps and topic maps from a persistent store and from
>other sources (perhaps a "RemoteTopicMap" implementation over SOAP !)
>
><snip!>
> >
> > What about that ?
> >
>
>I would be happy to go with this. I'm on the road at the moment but will be
>back home in a couple of days and able to get something started on this.


All of this is making me think I might just ditch my rdbms xtm package and 
go with TM4J.  One question (off this topic, however) remains: if Ozone is 
DOM based, is it the right package for a graph based universe?

Cheers
Jack

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

[Gerd M. <ge...@sm...>]

On Wed, 27 Jun 2001 09:01:37 +0100
"Kal Ahmed" <ka...@te...> wrote:

> >
> > >   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.
> >
> > The ID should not be the object ID in the persistent store, since
> > those IDs are normally hidden to the application layer, in our case the
> > topicmap implementation. Also the validity of a topicmap object
> > reference would depend on the database that contains it. So, if a
> > topicmap provider changes the database, all references to it become
> > invalid. We should better use the ID provided by TopicMapObject.getID()
> > or the resourceID (or is this what you mean with persistent object ID ?).
> > We could also use some kind of XPointer notation to point into another
> > TopicMap.
> >
> 
> My feeling is that the ID returned by TopicMapObject.getID() would be the
> best choice. TopicMapObject.getResourceID() is meant to return the "source"
> ID of the topic map object. If a TopicMap is created by merging two or more
> different sources, you will have resourceIDs which specify different URLs
> all mixed up within the same TopicMap - this is useful if your goal is to
> determine which objects came from where, but useless if you want some
> consistent form of addressing - hence the get/setID() function on
> TopicMapObject.

+1

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

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

[Gerd M. <ge...@sm...>]

> > We would need some lookup service that tells us which topicmaps
> > are around
> > there and what topics they 'export' for external use. The export
> > set of topics
> > could be managed via a scope, i.e. all topics in a special
> > export-scope are
> > available for external use. And we would need a protocol for topicmap
> > engine communication, e.g. Soap.
> >
> 
> For "topic map content types" this would work. For other content types,
> resolving the locator would involve a different interpretation of the
> fragment ID, and it would be nice to have some pluggable way of handling
> occurrences of any type or locator notation (in the topic map) and of any
> resource content type. However, I'm not sure that this is something which
> should be addressed by TM4J - I would prefer to see the development of a
> generic content addressing framework (such as a grove engine) as a separate
> project and integrate TM4J with that. Does anyone know of such a thing ?

The goal of the Infozone project Prowler is an integration layer for 
different data sources. We have an adapter/resource concept, where a
resource represents a data source and an adapter converts resource
data to XML documents. Thus you can integrate, e.g. SQL database,
mailboxes, etc. The links between XML documents are described with 
simple XLinks. And there is a XLinkResolver that takes the URL and
finds the correct adapter/resource where this link points to. But
the approach of simple XLinks has it's limits. First I thought
about using extended XLinks, but then I stumpled across topicmaps 
and this approach is much more better and flexible. So, the separate 
project you are looking for could be Prowler.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

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

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

>
> >   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.
>
> The ID should not be the object ID in the persistent store, since
> those IDs are normally hidden to the application layer, in our case the
> topicmap implementation. Also the validity of a topicmap object
> reference would depend on the database that contains it. So, if a
> topicmap provider changes the database, all references to it become
> invalid. We should better use the ID provided by TopicMapObject.getID()
> or the resourceID (or is this what you mean with persistent object ID ?).
> We could also use some kind of XPointer notation to point into another
> TopicMap.
>

My feeling is that the ID returned by TopicMapObject.getID() would be the
best choice. TopicMapObject.getResourceID() is meant to return the "source"
ID of the topic map object. If a TopicMap is created by merging two or more
different sources, you will have resourceIDs which specify different URLs
all mixed up within the same TopicMap - this is useful if your goal is to
determine which objects came from where, but useless if you want some
consistent form of addressing - hence the get/setID() function on
TopicMapObject.

Cheers,

Kal

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

[Gerd M. <ge...@sm...>]

>   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.

The ID should not be the object ID in the persistent store, since
those IDs are normally hidden to the application layer, in our case the
topicmap implementation. Also the validity of a topicmap object
reference would depend on the database that contains it. So, if a 
topicmap provider changes the database, all references to it become 
invalid. We should better use the ID provided by TopicMapObject.getID()
or the resourceID (or is this what you mean with persistent object ID ?). 
We could also use some kind of XPointer notation to point into another 
TopicMap.

Best Regards,
Gerd


--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

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

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

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Gerd
> Mueller
> Sent: 26 June 2001 08:19
> To: tm4...@li...
> Subject: Re: [Tm4j-developers] Drill-down topic maps
>
>
> On Mon, 25 Jun 2001 12:17:15 -0700
> Jack Park <jac...@th...> wrote:
>
>
> > 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?
>
> We would need some lookup service that tells us which topicmaps
> are around
> there and what topics they 'export' for external use. The export
> set of topics
> could be managed via a scope, i.e. all topics in a special
> export-scope are
> available for external use. And we would need a protocol for topicmap
> engine communication, e.g. Soap.
>

For "topic map content types" this would work. For other content types,
resolving the locator would involve a different interpretation of the
fragment ID, and it would be nice to have some pluggable way of handling
occurrences of any type or locator notation (in the topic map) and of any
resource content type. However, I'm not sure that this is something which
should be addressed by TM4J - I would prefer to see the development of a
generic content addressing framework (such as a grove engine) as a separate
project and integrate TM4J with that. Does anyone know of such a thing ?

> Having said this, I would suggest the following interfaces:
>
> public interface TopicMapProviderFactory {
>     public TopicMapProvider createTopicMap( Properties );
> }
>
> public interface TopicMapProvider {
>     public TopicMap getTopicMap();
>     public String getURL();
> }
>
> These two interface are necessary to intergrate a topicmap into a system.
> With getTopicMap() I get the map handled by this provider. I'm not sure
> if we need getURL() since TopicMap already has a getBaseURL() method.
>
> public interface TopicMapManager {
>     public void initialise(Properties) throws TopicMapManagerException();
>     public TopicMap getTopicMap(String sourceURL);
>     public Collection getTopicMaps();
>     public registerProvider( String providerFactoryClassName,
> Properties );
> }
>
> The TopicMapManager manages all TopicMapProviders known by a system. The
> registerProvider() method adds a provider to the manager by using the
> given factory class.

This is a nice model, it would allow me to combine both in-memory
(file-based) topic maps and topic maps from a persistent store and from
other sources (perhaps a "RemoteTopicMap" implementation over SOAP !)

<snip!>
>
> What about that ?
>

I would be happy to go with this. I'm on the road at the moment but will be
back home in a couple of days and able to get something started on this.

Cheers,

Kal

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

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

[Gerd M. <ge...@sm...>]

On Mon, 25 Jun 2001 12:17:15 -0700
Jack Park <jac...@th...> wrote:


> 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?

We would need some lookup service that tells us which topicmaps are around 
there and what topics they 'export' for external use. The export set of topics
could be managed via a scope, i.e. all topics in a special export-scope are
available for external use. And we would need a protocol for topicmap
engine communication, e.g. Soap.

Having said this, I would suggest the following interfaces:

public interface TopicMapProviderFactory {
    public TopicMapProvider createTopicMap( Properties );
}

public interface TopicMapProvider {
    public TopicMap getTopicMap();
    public String getURL();
}

These two interface are necessary to intergrate a topicmap into a system.
With getTopicMap() I get the map handled by this provider. I'm not sure
if we need getURL() since TopicMap already has a getBaseURL() method.

public interface TopicMapManager {
    public void initialise(Properties) throws TopicMapManagerException();
    public TopicMap getTopicMap(String sourceURL);
    public Collection getTopicMaps();
    public registerProvider( String providerFactoryClassName, Properties );
}

The TopicMapManager manages all TopicMapProviders known by a system. The
registerProvider() method adds a provider to the manager by using the 
given factory class.

> > > 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).

What about that ?

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

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

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

[Gerd M. <ge...@sm...>]

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

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

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

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 ?

Cheers,

Kal

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Jack
> Park
> Sent: 24 June 2001 17:26
> To: tm4...@li...
> Subject: [Tm4j-developers] Drill-down topic maps
>
>
> New member alert! <gg>
>
> Goal:
> To allow an occurrence of a topic to be, in fact, another topic map.
>
> Problem:
> xlink:href opens a can of worms.  For instance, the topic map
> FiveKingdoms
> has a topic Animalia, the occurrence for which is another topic
> map called
> Animalia.
>
> An approach to a solution:
> I am making the occurrence an instanceOf topicMap.  In so doing,
> I have my
> XTM engine do a type check.  My system --
> http://nexist.sourceforge.net --
> uses HSQLDB as a relational store.  Everything is in tables.  It
> becomes a
> simple task for the engine to see that an occurrence is of type topicMap,
> and search the topicmap table rather than the topic table.
>
> Angst:
> This is just not a general enough solution.  Besides, Nexist converses
> (client-server) with my xtm engine by way of an XTMSession
> object.  It will
> be an easy change to rewrite XTMSession to converse with TM4J
> instead.  Thusly, I'd like to know how this community might go about
> implementing drill-down topic maps.
>
> Cheers
> Jack
>
>
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> http://lists.sourceforge.net/lists/listinfo/tm4j-developers
>
>

[Tm4j-developers] Drill-down topic maps

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

New member alert! <gg>

Goal:
To allow an occurrence of a topic to be, in fact, another topic map.

Problem:
xlink:href opens a can of worms.  For instance, the topic map FiveKingdoms 
has a topic Animalia, the occurrence for which is another topic map called 
Animalia.

An approach to a solution:
I am making the occurrence an instanceOf topicMap.  In so doing, I have my 
XTM engine do a type check.  My system -- http://nexist.sourceforge.net -- 
uses HSQLDB as a relational store.  Everything is in tables.  It becomes a 
simple task for the engine to see that an occurrence is of type topicMap, 
and search the topicmap table rather than the topic table.

Angst:
This is just not a general enough solution.  Besides, Nexist converses 
(client-server) with my xtm engine by way of an XTMSession object.  It will 
be an easy change to rewrite XTMSession to converse with TM4J 
instead.  Thusly, I'd like to know how this community might go about 
implementing drill-down topic maps.

Cheers
Jack

RE: [Tm4j-developers] associations in objectsByID ?

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

Hi Gerd,

There is no reason for associations not to be added at all - its a bug :-).

I discovered the same problem for the index of objects by resourceID and
fixed that for the case of associations. I alsoadded a bug report to remind
me to index all the other topic map objects against their resourceID - it
looks like we need another one to remind me to index all the topic map
objects against their ID as well.

Cheers,

Kal

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Gerd
> Mueller
> Sent: 21 June 2001 10:46
> To: tm4...@li...
> Subject: [Tm4j-developers] associations in objectsByID ?
>
>
> Hi,
>
> Is there any particular reason why associations are not added to
> the objectsByID map in the TopicMap ? If not I would suggest to
> do this. It would give us the possiblity to retrieve associations
> with TopicMap.getObjectByID(). I need this for the web interface
> that I'm currently developing.
>
> 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
>
>

[Tm4j-developers] associations in objectsByID ?

[Gerd M. <ge...@sm...>]

Hi,

Is there any particular reason why associations are not added to
the objectsByID map in the TopicMap ? If not I would suggest to 
do this. It would give us the possiblity to retrieve associations
with TopicMap.getObjectByID(). I need this for the web interface
that I'm currently developing.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

Re: [Tm4j-developers] WARNING: TopicMap interface change

[Gerd M. <ge...@sm...>]

> > Just an idea: Is it really necessary to return an iterator. Wouldn't
> > be a collection enough ? That would make the ozone impl. much more
> > easier.
> >
> 
> Oh! I had done that because I thought that the iterator would be easier to
> implement for Ozone...DOH! :-)

In some aspects ozone is more like an EJB server: the database objects are
controlled via a kind of RMI. I would need to implement a RMI controlled
iterator, which is not that easy.

> I too would prefer a Collection as the return value because it is consistent
> with the rest of the interface.
> 
> So lets go for
> 
> Collection getObjects();

+1

Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

RE: [Tm4j-developers] WARNING: TopicMap interface change

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

> > Hi,
> >
> > Just a heads-up to let you know that I added a new method to
> the TopicMap
> > interface:
> >
> > Iterator getObjects();
> >
> > Which should return an Iterator over all of the TopicMapObjects
> which are
> > associated with the topic map.
> >
> > The in-memory implementation has this function added, although
> it is broken
> > because it only iterates over Topics and Associations. I'm
> working on a fix.
> > However, I guess that the Ozone implementation will need
> updating too...do
> > you have time to take a look at that, Gerd ?
>
> At the moment I don't have the time for a full implementation,
> since iterators are a bit tricky. But I will add a dummmy
> implemenation to stay interface compatible.
>

OK.

> Just an idea: Is it really necessary to return an iterator. Wouldn't
> be a collection enough ? That would make the ozone impl. much more
> easier.
>

Oh! I had done that because I thought that the iterator would be easier to
implement for Ozone...DOH! :-)
I too would prefer a Collection as the return value because it is consistent
with the rest of the interface.

So lets go for

Collection getObjects();

Cheers,

Kal

Re: [Tm4j-developers] WARNING: TopicMap interface change

[Gerd M. <ge...@sm...>]

On Tue, 12 Jun 2001 09:33:20 +0100
"Kal Ahmed" <ka...@te...> wrote:

> Hi,
> 
> Just a heads-up to let you know that I added a new method to the TopicMap
> interface:
> 
> Iterator getObjects();
> 
> Which should return an Iterator over all of the TopicMapObjects which are
> associated with the topic map.
> 
> The in-memory implementation has this function added, although it is broken
> because it only iterates over Topics and Associations. I'm working on a fix.
> However, I guess that the Ozone implementation will need updating too...do
> you have time to take a look at that, Gerd ?

At the moment I don't have the time for a full implementation, 
since iterators are a bit tricky. But I will add a dummmy 
implemenation to stay interface compatible. 

Just an idea: Is it really necessary to return an iterator. Wouldn't
be a collection enough ? That would make the ozone impl. much more
easier.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

[Tm4j-developers] WARNING: TopicMap interface change

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

Hi,

Just a heads-up to let you know that I added a new method to the TopicMap
interface:

Iterator getObjects();

Which should return an Iterator over all of the TopicMapObjects which are
associated with the topic map.

The in-memory implementation has this function added, although it is broken
because it only iterates over Topics and Associations. I'm working on a fix.
However, I guess that the Ozone implementation will need updating too...do
you have time to take a look at that, Gerd ?

Cheers,

Kal

Re: [Tm4j-developers] Checking in

[Gerd M. <ge...@sm...>]

On Tue, 5 Jun 2001 18:52:36 +0100
"Kal Ahmed" <ka...@te...> wrote:

> Hi Gerd,
> 
> Sorry its taken so long to get back to you on this. Firstly with regards to
> the copyright, I guess that this all needs to be updated. I noticed that you
> checked in some files with both our names in. The other way to do this might
> be to create a group - say "The TM4J Group" and assign the copyright to that
> group. Then we should also update the general license file to acknowledge
> that some parts of the distribution are copyrighted by SMB GmbH and some
> parts belong to the Ozone project. How does that sound ? If it sounds
> reasonable, I'll work on a new license text.

I would prefer 'The TM4J Project', 'group' sounds more like a organisation.
The rest is very reasonable :-) 

Best Regards.
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

RE: [Tm4j-developers] Checking in

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

Hi Gerd,

Sorry its taken so long to get back to you on this. Firstly with regards to
the copyright, I guess that this all needs to be updated. I noticed that you
checked in some files with both our names in. The other way to do this might
be to create a group - say "The TM4J Group" and assign the copyright to that
group. Then we should also update the general license file to acknowledge
that some parts of the distribution are copyrighted by SMB GmbH and some
parts belong to the Ozone project. How does that sound ? If it sounds
reasonable, I'll work on a new license text.

Secondly on the syncmail front, thanks for this, I'll update it today.

Cheers,

Kal

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Gerd
> Mueller
> Sent: 29 May 2001 18:47
> To: tm4...@li...
> Subject: Re: [Tm4j-developers] Checking in
>
>
>
> Hi,
>
> As you may have noticed, I've checked in something. I didn't add
> the correct license to my code, since I wasn't quite sure about
> the copyright notice in the license file. Should I change it to
> my name for the code I wrote or do we use the 'project' as the
> copyright owner ?
>
> Also I've attached a patched version of 'syncmail' for the CVS
> messages. It does't produce diffs, so that the message will be
> smaller. If you like it, you'll need to contact the sourceforge
> admin to deploy the script.
>
> Best Regards,
> Gerd
>
> --
> ________________________________________________________________
> Gerd Mueller                                    ge...@sm...
> SMB GmbH                                  http://www.smb-tec.com
>

Re: [Tm4j-developers] Checking in

[Gerd M. <ge...@sm...>]

Hi,

As you may have noticed, I've checked in something. I didn't add
the correct license to my code, since I wasn't quite sure about
the copyright notice in the license file. Should I change it to
my name for the code I wrote or do we use the 'project' as the
copyright owner ?

Also I've attached a patched version of 'syncmail' for the CVS
messages. It does't produce diffs, so that the message will be
smaller. If you like it, you'll need to contact the sourceforge
admin to deploy the script.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

RE: [Tm4j-developers] Checking in

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

Hi Gerd,

Those changes seem fine to me - feel free to check your stuff in.

Cheers,

Kal

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Gerd
> Mueller
> Sent: 28 May 2001 19:12
> To: tm4...@li...
> Subject: [Tm4j-developers] Checking in
> 
> 
> 
> Hi,
> 
> I'm about to check in the ozone stuff. Before I'll do this some
> remarks/questions:
> 
> 1. My build script seems to be obsolete since the bin/ant does everything
>    that is needed.
> 
> 2. The XTMBuilder had two small bugs: somewhere the *Impl objects
>    where created directly with 'new' instead with the factory.
> 
> 3. I had to make the constructors of TopicNotFoundException and
>    DuplicateTopicException public since otherwise I can't use 
>    them.
> 
> 4. To make the ozone implementation work I had to make TopicMapObjectImpl
>    'Serializable'. This is needed since method arguments of ozone
>    object methods are serialized and there are some util methods that
>    get a transient TopicMapObjectImpl, e.g. the search methods.
> 
> If you don't mind I would check in the whole stuff.
> 
> 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
> 
>