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

[Tm4j-developers] Normalising ID and resourceID

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

I've been reviewing the way in which TM4J's import and export functionality
handles the resolution and normalisation of IDs and references and I would
like to get feedback on my thoughts before implementing anything.

Firstly, all TopicMapObjects have two separate 'identifiers':

  ID property: Assigned by the import process.
               Guarunteed to be unique across all objects in the same
TopicMap
               Should be stored as the ID only (not as a full URL)

  resourceID property: The URI of the XML element which gave rise to the
creation
                         of the object.
                       Stored as a complete URI (many different topic map
documents
                         may contribute objects to a single TopicMap.
                       May be NULL
                       Guarunteed to be unique across all objects in the
same TopicMap.

Then TopicMaps have three additional associated URIs:

  baseURL property: The URL which should be treated as the URL of the topic
map in
                      its entirety. All objects in the topic map can then be
                      addressed as <baseURL>#<ID>.
                    This is currently not a required property of the
TopicMap, but
                      it probably should be.

  xml:base : The (optional) value of the xml:base attribute of the
               <topicMap> element.
             Used only during parsing to resolve references to external
documents.

  sourceURL: Not stored as a property of the TopicMap, but just used when
parsing
               a source document.
             Used only during parsing to resolve the value of the id
attribute
               of an element into a full URI for storing as the resourceID
               property of a TopicMapObject
             Used to resolve references to external documents if baseURL is
not
               specified

Addressing into a topic map held in a TM4J system may require a
backend-specific URI to identify the store. However, once a connection is
made to a TM4J store, I think it should be possible to query the
TopicMapProvider interface to retrieve a TopicMapObject by specifying a URL
constructed of the baseURL property of the TopicMap and the ID of the object
required.

What I have described in the foregoing is not exactly the way that TM4J
behaves right now, partially because I didn't properly understand the
purpose of xml:base and partly because before the Ozone implementation,
there was no real need to consider a TM4J system that kept track of multiple
topic maps simultaneously.

So, my questions to y'all are: Does this sound reasonable to everyone ? Is
there something else missing from this list ?

If this is OK, I'll implement this policy for the next release of TM4J -
most of the changes are localised in the XTMBuilder and XTMWriter classes.

Cheers,

Kal

-----------------------------------
Kal Ahmed
XML and Topic Maps Consultant
e: ka...@te...
p: +44 (0)7968 529 531
w: www.techquila.com
-----------------------------------

RE: [Tm4j-developers] Ozone problem on NT

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

I just tested again with JDK1.3.1 and it worked fine (I already had JDK1.3.1
on Linux). So I guess I had better update the docs and then I think we are
more or less ready for release!

Cheers,

Kal

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Kal
> Ahmed
> Sent: 27 July 2001 08:35
> To: Tm4j-Developers@Lists. Sourceforge. Net
> Subject: RE: [Tm4j-developers] Ozone problem on NT
>
>
>
> Gerd Mueller wrote:
>
> > On Thu, 26 Jul 2001 22:05:17 +0100
> > "Kal Ahmed" <ka...@te...> wrote:
> >
> > > Hi Gerd,
> > >
> > > I have tried running the Ant ozone-test target on Linux and
> > that works, no
> > > problem. However, when I try on my Win2K machine, I get the
> > error shown at
> > > the bottom of this file.
> > >
> > > There is hopefully a simple reason why (like I have done
> > something really
> > > stupid) but I'm stumped with it at the moment - any clues ?
> >
> > Which JDK do you use on NT ?
>
> I'm using JDK 1.3 or
>
> java version "1.3.0_01"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
> Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)
>
> to be precise.
>
>
> > Could please send the logfile of ozone ($TM4J_HOME/db/log) ? There
> > is more detailed exception.
> >
>
> The log file is attached.
>
> Cheers,
>
> Kal
>

RE: [Tm4j-developers] Ozone problem on NT

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

Gerd Mueller wrote:

> On Thu, 26 Jul 2001 22:05:17 +0100
> "Kal Ahmed" <ka...@te...> wrote:
> 
> > Hi Gerd,
> > 
> > I have tried running the Ant ozone-test target on Linux and 
> that works, no
> > problem. However, when I try on my Win2K machine, I get the 
> error shown at
> > the bottom of this file.
> > 
> > There is hopefully a simple reason why (like I have done 
> something really
> > stupid) but I'm stumped with it at the moment - any clues ?
> 
> Which JDK do you use on NT ?

I'm using JDK 1.3 or 

java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)

to be precise.


> Could please send the logfile of ozone ($TM4J_HOME/db/log) ? There
> is more detailed exception.
> 

The log file is attached.

Cheers,

Kal

[Tm4j-developers] Re: [Tm4j-announce] Developers Guide now online

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

On Thu, 26 Jul 2001 22:40:43 +0100
"Kal Ahmed" <ka...@te...> wrote:

> The first cut of the TM4J Developer's Guide is now posted on the website.

Seems that you've got a lot of fun with writing docu ;-) Really impressive.

> BTW, I have also registered a domain for the TM4J Project, so you can now
> get to the project website via http://tm4j.org

Cool ! 

Best Regards,
Gerd

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

Re: [Tm4j-developers] Ozone problem on NT

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

On Thu, 26 Jul 2001 22:05:17 +0100
"Kal Ahmed" <ka...@te...> wrote:

> Hi Gerd,
> 
> I have tried running the Ant ozone-test target on Linux and that works, no
> problem. However, when I try on my Win2K machine, I get the error shown at
> the bottom of this file.
> 
> There is hopefully a simple reason why (like I have done something really
> stupid) but I'm stumped with it at the moment - any clues ?

Which JDK do you use on NT ?
Could please send the logfile of ozone ($TM4J_HOME/db/log) ? There
is more detailed exception.

Best Regards,
Gerd

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

[Tm4j-developers] Ozone problem on NT

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

Hi Gerd,

I have tried running the Ant ozone-test target on Linux and that works, no
problem. However, when I try on my Win2K machine, I get the error shown at
the bottom of this file.

There is hopefully a simple reason why (like I have done something really
stupid) but I'm stumped with it at the moment - any clues ?

Cheers,

Kal

--- START DUMP ---

O:\tm4j>bin\ant -Dozone.test.file=resource\tests\opera-xtm.xml ozone-test
Buildfile: build.xml

init:

ozone-install:
   [delete] Deleting directory O:\tm4j\db
     [java] installing database in db\ ...
     [java] deleting db\\ ...
     [java] making dir db\\ ...
     [java] making db\\data\ ...
     [java] making db\\ostab ...
     [java] making db\\config.properties ...
     [java]     ozoneDB.adminPort = 3000
     [java]     ozoneDB.classicStore.clusterSize = 65536
     [java]     ozoneDB.classicStore.clusterSpaceSize = 5120000
     [java]     ozoneDB.classicStore.tableBufferSize = 12800
     [java]     ozoneDB.classicStore.tableCacheSize = 4096
     [java]     ozoneDB.dbID = 0
     [java]     ozoneDB.fileLog = INFO, WARN, ERROR
     [java]     ozoneDB.port = 3333
     [java]     ozoneDB.stdoutLog = INFO, WARN, ERROR
     [java]     ozoneDB.store = org.ozoneDB.core.wizardStore.WizardStore
     [java]     ozoneDB.wizardStore.clusterSize = 65536
     [java]     ozoneDB.wizardStore.clusterSizeRatio = 256
     [java]     ozoneDB.wizardStore.compressClusters = true
     [java]     ozoneDB.wizardStore.tableBufferSize = 15
     [java]     ozoneDB.wizardStore.tableCacheSize = 12
     [java]     ozoneDB.wizardStore.tableSubtableSize = 11
     [java] making db\\state.properties ...
     [java]     ID counter = 0 * 2^40
     [java] Edit the file db\config.properties to change settings.
     [java] Ready.

ozone-test-args:

ozone-test:
    ozoneDB.adminPort = 3000
    ozoneDB.classicStore.clusterSize = 65536
    ozoneDB.classicStore.clusterSpaceSize = 5120000
    ozoneDB.classicStore.tableBufferSize = 12800
    ozoneDB.classicStore.tableCacheSize = 4096
    ozoneDB.dbID = 0
    ozoneDB.fileLog = INFO, WARN, ERROR
    ozoneDB.port = 3333
    ozoneDB.stdoutLog = INFO, WARN, ERROR
    ozoneDB.store = org.ozoneDB.core.wizardStore.WizardStore
    ozoneDB.wizardStore.clusterSize = 65536
    ozoneDB.wizardStore.clusterSizeRatio = 256
    ozoneDB.wizardStore.compressClusters = true
    ozoneDB.wizardStore.tableBufferSize = 15
    ozoneDB.wizardStore.tableCacheSize = 12
    ozoneDB.wizardStore.tableSubtableSize = 11

BUILD FAILED

O:\tm4j\build.xml:350: org.ozoneDB.OzoneInternalExc:
java.lang.NullPointerExcept
ion
--- Nested Exception ---
org.ozoneDB.OzoneInternalExc: java.lang.NullPointerException
        at org.ozoneDB.core.Transaction.nameObject(Transaction.java:561)
        at org.ozoneDB.core.Transaction.createObject(Transaction.java:402)
        at org.ozoneDB.core.admin.AdminManager.startup(AdminManager.java:53)
        at org.ozoneDB.core.Env.<init>(Env.java:216)
        at org.ozoneDB.LocalDatabase.open(LocalDatabase.java:104)
        at
org.ozoneDB.ExternalDatabase.openDatabase(ExternalDatabase.java:603)
        at
com.techquila.topicmap.ozone.OzoneXTMBuilder.main(OzoneXTMBuilder.jav
a:167)
        at java.lang.reflect.Method.invoke(Native Method)
        at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:12
7)
        at org.apache.tools.ant.taskdefs.Java.run(Java.java:260)
        at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:123)
        at org.apache.tools.ant.taskdefs.Java.execute(Java.java:87)
        at org.apache.tools.ant.Target.execute(Target.java:153)
        at org.apache.tools.ant.Project.runTarget(Project.java:898)
        at org.apache.tools.ant.Project.executeTarget(Project.java:536)
        at org.apache.tools.ant.Project.executeTargets(Project.java:510)
        at org.apache.tools.ant.Main.runBuild(Main.java:421)
        at org.apache.tools.ant.Main.main(Main.java:149)

Total time: 16 seconds

RE: [Tm4j-developers] TopicMapProvider

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

I wrote:
>
> OK, if both of the existing implementations have an addTopicMap()
> method, I
> guess it should probably be in the interface. I've added
> addTopicMap(InputStream src, URL baseURL) to the TopicMapProvider
> interface.
> The baseURL parameters should specify a URL to be assigned to the TopicMap
> object only if the parser does not find a value in the topic map itself
> (i.e. if the <topicMap> element does not have an xml:base attribute).
>

And I later realised that in fact the method should be:

addTopicMap(InputStream src, URL baseURL, TopicMap existingTopicMap)

which matches more closely the existing buildTopicMap() function in
OzoneTopicMapProviderImpl

Cheers,

Kal

RE: [Tm4j-developers] TopicMapProvider

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

>
> > > Yeap, that's what I was thinking of. The problem was that
> I've implemented
> > > the TopicMapProvider stuff, but I didn't know what to provide
> since that
> > > database was empty. Thus I've needed a addTopicMap method
> somehow. And as
> > > I saw, you've already added such method to the in-memory
> implementation.
> > >
> > Yep, I did, though I consider that to be a bit of a special
> case, because
> > the in-memory implementation has not persistant store. In other
> words, it
> > *has* to add new topic maps somehow.
>
> It's not that special. Finally ozone is nothing more and nothing less than
> a transactional swap for Java objects. There must be point where to put a
> topicmap into the system and the system (ozone) has to know about the
> topicmap. The logical conclusion is a addTopicMap() method.
>

OK, if both of the existing implementations have an addTopicMap() method, I
guess it should probably be in the interface. I've added
addTopicMap(InputStream src, URL baseURL) to the TopicMapProvider interface.
The baseURL parameters should specify a URL to be assigned to the TopicMap
object only if the parser does not find a value in the topic map itself
(i.e. if the <topicMap> element does not have an xml:base attribute).

> > > Sounds really good. But IMHO the Import/Export interfaces must be
> > > connected
> > > somehow with a provider, because finally the provider knows
> how to store
> > > the topicmap. E.g. a provider could have a method like
> > > ImportFilter getImportFilter( String format ) or something like that.
> > >
> >
> > That is an interesting possibility. So an ImportFilter would essentially
> > wrap an parser object, and a builder object with the
> appropriate factory for
> > the store which the TopicMapProvider wraps. That sounds quite
> neat. Though
> > then we may need to also add some way of getting hold of the
> > TopicMapProvider from the TopicMapManager object - perhaps
> returning it from
> > the registerProvider() method, or maybe by adding a
> getProvider( TopicMap )
> > method to the TopicMapManager interface.
>
> registerProvider() should return the provider and the getProvider() method
> may also be useful.
>

To support the addition of later import filters, I've added a getFactory()
method to the TopicMapProvider interface, this should return the
TopicMapFactory implementation which works with the TopicMapProvider's data
store. That should provide the necessary hook for a "syntax independant"
import process to be implemented later.

> > I think that this should be provider dependent - what you
> describe certainly
> > makes sense for a persistant storage-backed implementation, but probably
> > doesn't make sense for the in-memory implementation where the system is
> > parsing files from a file system or from the Web. There is another issue
> > here as well, currently the XTMParser object will honour the xml:base
> > attribute if it is found on the <topicMap> object - the URL specified in
> > that attribute will then become the value of the base property of the
> > TopicMap object. This is important because enables me to import
> a topic map
> > with a "well-known" URL into a topic map store and for
> references between
> > topic maps to be resolved correctly. It is the value of the
> base property
> > which the in-memory provider makes use of.
> >
> > Of course, it could also be possible for an implementation to recognise
> > multiple URLs for the same topic map - so the Ozone provider may support
> > addressing as you suggest as well as addressing by the base
> property of the
> > TopicMap object, but should probably only return its
> 'generated' base URL if
> > the TopicMap does not have a value for the 'base' property.
>
> Okay, I've forgot the xml:base attribute. I think you are right and we
> leave it provider depend.
>
> Another point: Now as the interface collection of topicmap grows
> it would probably as good idea to create a separate package for
> the in-memory implementation as you've already suggest some time
> ago.
>
OK - I've done that now locally and I'll check it in soon.

> With my latest check-ins of the ozone stuff I guess I'm ready for
> the 0.5 distribution, except that we change something with the
> provider interface.
>

Hopefully the updated interface will be suitable for you. I'll spend some
time today going through the documentation. Hopefully we will be able to
release by Friday.

Cheers,

Kal

Re: [Tm4j-developers] TopicMapProvider

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

> > Yeap, that's what I was thinking of. The problem was that I've implemented
> > the TopicMapProvider stuff, but I didn't know what to provide since that
> > database was empty. Thus I've needed a addTopicMap method somehow. And as
> > I saw, you've already added such method to the in-memory implementation.
> >
> Yep, I did, though I consider that to be a bit of a special case, because
> the in-memory implementation has not persistant store. In other words, it
> *has* to add new topic maps somehow.

It's not that special. Finally ozone is nothing more and nothing less than
a transactional swap for Java objects. There must be point where to put a
topicmap into the system and the system (ozone) has to know about the
topicmap. The logical conclusion is a addTopicMap() method.
 
> > Sounds really good. But IMHO the Import/Export interfaces must be
> > connected
> > somehow with a provider, because finally the provider knows how to store
> > the topicmap. E.g. a provider could have a method like
> > ImportFilter getImportFilter( String format ) or something like that.
> >
> 
> That is an interesting possibility. So an ImportFilter would essentially
> wrap an parser object, and a builder object with the appropriate factory for
> the store which the TopicMapProvider wraps. That sounds quite neat. Though
> then we may need to also add some way of getting hold of the
> TopicMapProvider from the TopicMapManager object - perhaps returning it from
> the registerProvider() method, or maybe by adding a getProvider( TopicMap )
> method to the TopicMapManager interface.

registerProvider() should return the provider and the getProvider() method
may also be useful.
 
> I think that this should be provider dependent - what you describe certainly
> makes sense for a persistant storage-backed implementation, but probably
> doesn't make sense for the in-memory implementation where the system is
> parsing files from a file system or from the Web. There is another issue
> here as well, currently the XTMParser object will honour the xml:base
> attribute if it is found on the <topicMap> object - the URL specified in
> that attribute will then become the value of the base property of the
> TopicMap object. This is important because enables me to import a topic map
> with a "well-known" URL into a topic map store and for references between
> topic maps to be resolved correctly. It is the value of the base property
> which the in-memory provider makes use of.
> 
> Of course, it could also be possible for an implementation to recognise
> multiple URLs for the same topic map - so the Ozone provider may support
> addressing as you suggest as well as addressing by the base property of the
> TopicMap object, but should probably only return its 'generated' base URL if
> the TopicMap does not have a value for the 'base' property.

Okay, I've forgot the xml:base attribute. I think you are right and we
leave it provider depend.
 
Another point: Now as the interface collection of topicmap grows
it would probably as good idea to create a separate package for
the in-memory implementation as you've already suggest some time
ago. 

With my latest check-ins of the ozone stuff I guess I'm ready for
the 0.5 distribution, except that we change something with the
provider interface.

Best Regards,
Gerd

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

RE: [Tm4j-developers] TopicMapProvider

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

Hi Gerd,

>
> > What you describe sounds like a generic "import" method for the
> > TopicMapProvider interface - essentially a way for an
> application programmer
> > to easily code the task of parsing an XTM file and storing it
> in whatever
> > underlying topic map store is being used by the system. Is that
> correct ?
>
> Yeap, that's what I was thinking of. The problem was that I've implemented
> the TopicMapProvider stuff, but I didn't know what to provide since that
> database was empty. Thus I've needed a addTopicMap method somehow. And as
> I saw, you've already added such method to the in-memory implementation.
>
Yep, I did, though I consider that to be a bit of a special case, because
the in-memory implementation has not persistant store. In other words, it
*has* to add new topic maps somehow.

> > If so, I'm not sure that TopicMapProvider is necessarily the
> right place to
> > add this functionality - generic import and export interfaces would
> > definitely be useful and the TopicMapManager interface makes it
> relatively
> > easy to implement, but I think I would prefer to have a
> separate interface
> > for store-independant and syntax-independant import/export - I
> am thinking
> > that in the future it would be good to reintroduce support for
> reading and
> > possibly writing ISO 13250 syntax and for reading and possibly writing
> > Ontopia's LTM syntax. For that reason I would prefer to
> encapsulate import
> > and export in some interface(s) separate from TopicMapProvider.
> What do you
> > think ?
>
> Sounds really good. But IMHO the Import/Export interfaces must be
> connected
> somehow with a provider, because finally the provider knows how to store
> the topicmap. E.g. a provider could have a method like
> ImportFilter getImportFilter( String format ) or something like that.
>

That is an interesting possibility. So an ImportFilter would essentially
wrap an parser object, and a builder object with the appropriate factory for
the store which the TopicMapProvider wraps. That sounds quite neat. Though
then we may need to also add some way of getting hold of the
TopicMapProvider from the TopicMapManager object - perhaps returning it from
the registerProvider() method, or maybe by adding a getProvider( TopicMap )
method to the TopicMapManager interface.

> The next thing I was thinking about is the base URL of a topic map.
> Should a provider have a base URL and all topicmaps which it provides
> are 'folders' of this URL ? E.g. the ozone provider has
> http://topicmap.techquila.com/ozone, thus a topicmap provided by this
> has http://topicmap.techquila.com/ozone/the_name_of_the_tm
>

I think that this should be provider dependent - what you describe certainly
makes sense for a persistant storage-backed implementation, but probably
doesn't make sense for the in-memory implementation where the system is
parsing files from a file system or from the Web. There is another issue
here as well, currently the XTMParser object will honour the xml:base
attribute if it is found on the <topicMap> object - the URL specified in
that attribute will then become the value of the base property of the
TopicMap object. This is important because enables me to import a topic map
with a "well-known" URL into a topic map store and for references between
topic maps to be resolved correctly. It is the value of the base property
which the in-memory provider makes use of.

Of course, it could also be possible for an implementation to recognise
multiple URLs for the same topic map - so the Ozone provider may support
addressing as you suggest as well as addressing by the base property of the
TopicMap object, but should probably only return its 'generated' base URL if
the TopicMap does not have a value for the 'base' property.

> And what about the name of topicmap ? Is it user-defined or
> auto generated ?
>

The in-memory implementation uses the value of the xml:base attribute or
else a default URL as the base property of the imported topic map. I'm not
entirely happy with a single default URL so I think future behaviour of the
in-memory implementation will be to default to some generated,
session-unique value.

For the Ozone implementation I would suggest that some similar algorithm
should be employed.

> I've noticed that you checked in a developer doc made with
> docbook. Which tool do you use for that ?
>

I used XMetal for creating that document. XMetal is probably my favourite
XML editor - and I've tried a few - though I have a love-hate relationship
with all of them. :-)

Cheers,

Kal

Re: [Tm4j-developers] TopicMapProvider

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

Hi Kal,

> What you describe sounds like a generic "import" method for the
> TopicMapProvider interface - essentially a way for an application programmer
> to easily code the task of parsing an XTM file and storing it in whatever
> underlying topic map store is being used by the system. Is that correct ?

Yeap, that's what I was thinking of. The problem was that I've implemented
the TopicMapProvider stuff, but I didn't know what to provide since that
database was empty. Thus I've needed a addTopicMap method somehow. And as
I saw, you've already added such method to the in-memory implementation.

> If so, I'm not sure that TopicMapProvider is necessarily the right place to
> add this functionality - generic import and export interfaces would
> definitely be useful and the TopicMapManager interface makes it relatively
> easy to implement, but I think I would prefer to have a separate interface
> for store-independant and syntax-independant import/export - I am thinking
> that in the future it would be good to reintroduce support for reading and
> possibly writing ISO 13250 syntax and for reading and possibly writing
> Ontopia's LTM syntax. For that reason I would prefer to encapsulate import
> and export in some interface(s) separate from TopicMapProvider. What do you
> think ?

Sounds really good. But IMHO the Import/Export interfaces must be connected
somehow with a provider, because finally the provider knows how to store
the topicmap. E.g. a provider could have a method like 
ImportFilter getImportFilter( String format ) or something like that.
 
The next thing I was thinking about is the base URL of a topic map.
Should a provider have a base URL and all topicmaps which it provides
are 'folders' of this URL ? E.g. the ozone provider has 
http://topicmap.techquila.com/ozone, thus a topicmap provided by this
has http://topicmap.techquila.com/ozone/the_name_of_the_tm 

And what about the name of topicmap ? Is it user-defined or
auto generated ?

I've noticed that you checked in a developer doc made with
docbook. Which tool do you use for that ?

Best Regards,
Gerd

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

RE: [Tm4j-developers] TopicMapProvider

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

Hi Gerd,

What you describe sounds like a generic "import" method for the
TopicMapProvider interface - essentially a way for an application programmer
to easily code the task of parsing an XTM file and storing it in whatever
underlying topic map store is being used by the system. Is that correct ?

If so, I'm not sure that TopicMapProvider is necessarily the right place to
add this functionality - generic import and export interfaces would
definitely be useful and the TopicMapManager interface makes it relatively
easy to implement, but I think I would prefer to have a separate interface
for store-independant and syntax-independant import/export - I am thinking
that in the future it would be good to reintroduce support for reading and
possibly writing ISO 13250 syntax and for reading and possibly writing
Ontopia's LTM syntax. For that reason I would prefer to encapsulate import
and export in some interface(s) separate from TopicMapProvider. What do you
think ?

On the subject of TopicImpl.m_contribThemes and TopicMapImpl.m_id - both are
dead code...well spotted! I've removed them from my local copy and I'll
check-in in a short while.

Cheers,

Kal
> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Gerd
> Mueller
> Sent: 17 July 2001 18:56
> To: tm4...@li...
> Subject: [Tm4j-developers] TopicMapProvider
>
>
>
> Hi,
>
> I'm about to implement the TopicMapProvider stuff for ozone. What
> I'm missing is something like a createTopicMap() method. I would
> suggest to extend the TopicMapProvider interface with the
> following method:
>
> public TopicMap buildTopicMap( InputSource input,
>     TopicMap existingTopicMap ) throws TopicMapProviderException;
>
> This method parses the input source and either creates a new
> TopicMap if existingTopicMap is null or merges it otherwise.
> I'm not sure about the baseURL of the new TopicMap: Should it
> created automatically by the provider or can it be user defined ?
>
> Best Regards,
> Gerd
>
> P.S. While browsing the code I found TopicImpl.m_contribThemes. Is
> this still necessary ? Otherwise I would suggest to remove it. Also
> TopicMapImpl has a member m_id although it already inherits one
> from TopicMapObjectImpl.
>
> --
> ________________________________________________________________
> 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] TopicMapProvider

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

Hi,

I'm about to implement the TopicMapProvider stuff for ozone. What
I'm missing is something like a createTopicMap() method. I would
suggest to extend the TopicMapProvider interface with the
following method:

public TopicMap buildTopicMap( InputSource input, 
    TopicMap existingTopicMap ) throws TopicMapProviderException;

This method parses the input source and either creates a new
TopicMap if existingTopicMap is null or merges it otherwise.
I'm not sure about the baseURL of the new TopicMap: Should it
created automatically by the provider or can it be user defined ?

Best Regards,
Gerd

P.S. While browsing the code I found TopicImpl.m_contribThemes. Is
this still necessary ? Otherwise I would suggest to remove it. Also
TopicMapImpl has a member m_id although it already inherits one
from TopicMapObjectImpl.

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

RE: [Tm4j-developers] TMQL

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

There is currently no spec for TMQL. The TMQL working group are still in the
process of gathering requirements, so don't expect anything from that effort
any time soon. Empolis and Ontopia have both developed and presented
demonstrations of topic map query languages, though I don't believe that
either company have published a specification that could be implemented
against.

I quite like the approach taken by Ontopia with their "tolog" query
language[1] - as the name suggests, it uses a Prolog-style query language. A
similar approach was taken by FourThought with their RDF Inference Lanuage
(RIL)[2] and I think that this kind of approach suits applications which
want to discover new relationships in a topic map. Other, more
straightforward querying could be implemented with an SQL-style syntax
(which is the approach taken by Empolis and by RDF query languages such as
SQUISH[3]).

Cheers,

Kal

[1] http://www.ontopia.net/topicmaps/materials/tolog.html
[2] http://rdfinference.org/ril/about.html
[3] http://swordfish.rdfweb.org:8085/rdfquery/squish.html

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Gerd
> Mueller
> Sent: 16 July 2001 08:23
> To: tm4...@li...
> Subject: [Tm4j-developers] TMQL
>
>
> Hi,
>
> Is there a spec of TMQL or any other query language for Topic Maps?
> And if so what about an implementation within TM4J ?
>
> 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] TMQL

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

Hi,

Is there a spec of TMQL or any other query language for Topic Maps?
And if so what about an implementation within TM4J ?

Best Regards,
Gerd

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

RE: [Tm4j-developers] Towards 0.5

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

>
> > Its been a while since a TM4J release and I feel that we have made some
> > major progress that it would be good to get announced and
> released. I would
> > like to draw up a list of things to do prior to an 0.5 release.
> Here is my
> > shortlist:
> >
> > 	1) Documentation: Just a basic developer's guide and some
> user docs for the
> > tools
> > 	2) Stabilise the TMNav application: It has been really
> buggy for a while -
> > I've tracked down the cause of most of the error messages generated by
> > TheBrain SDK and I think that the intermittent crashes are to do with
> > deadlocks in AWT event processing which it might be possible to fix by
> > splitting the application into separate top-level windows.
> > 	3) Complete the Provider/Manager interface
>
> I'd like the improve the ozone implementation, but I will not be
> able to this
> within the next three weeks. Also some docu for the ozone stuff
> would be good.
>

We could label the ozone package as "experimental" for the 0.5 release.
Perhaps I could write some really basic documentation for people to be able
to get a topic map database up and running (that would be a useful exercise
for me).


> > I'm going to be travelling and working away for much of this month, but
> > hopefully will have some time while on the road to work on (1)
> and (2) and
> > to make any changes necessary for (3). Once I get back I'll
> have some free
> > time to finish off, so I'm tentatively planning on making 0.5
> before the end
> > of the month.
> >
> > However, this means that a few things will probably not make the cut for
> > 0.5. Such as:
> > 	1) Index of *all* topic map objects by ID
> > 	2) Implementing the duplicate suppression rules of XTM
> > 	3) Implementing a different Open Source-based visualisation
> for TMNav
> >
> > (1) and (2) I will try and do if there is time. (3) I'm playing
> with ideas
> > for but don't even have a concrete design in mind at this
> stage, so it is
> > almost certain to be left undone.
>
> I've done a web based interface with Cocoon2, but it's very application
> specfic. I'm not sure if a HTML based solution would be the right for a
> general TMNav solution. I had also some ideas for a graph based interface
> as we have it now, but I'll have to think about it again.
>

I would be interested to hear your ideas - I've been playing with a pinwheel
tree display in Jazz - though I haven't got very far with that yet.
Visualisations are pretty tricky for topic maps. One thing I would like to
do is completely overhaul the TMNav framework and clean it up. The original
idea with TMNav was that it would support pluggable components in an
MVC-style framework. Unfortunately, when I started that I didn't have the
event mechanism in the TopicMapObject interface so it got very messy. I
think redesigning that framework from the ground up and implementing a
couple of different visualisations within that framework would be a good
goal for 0.6.

Cheers,

Kal

Re: [Tm4j-developers] Suggestion regarding players

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

On Mon, 9 Jul 2001 09:37:35 +0100
"Kal Ahmed" <ka...@te...> wrote:

> Hi Gerd,
> 
> I don't know how I managed to miss this message ... sorry for the delay in
> replying.
> 
> I think that using a hashmap internally for Topic.rolesPlayed and
> Member.player attributes might be a useful thing to do, and as you note, it
> would enable a more convenient removeXXX() operation. However, it should be
> noted that from an XTM spec point of view, this would not be sufficient to
> meet the requirements to suppress duplicate players of roles in an
> association. Also, I wonder about the time and space overhead of the use of
> a HashMap in the in-memory implementation when the index would really only
> be used for removals.

Maybe you are right, since removals don't happen that often.
 
> So my position would be +1 to adding the suggested operations to the
> interface but -1 on using a HashMap for the in-memory implementation (I
> don't yet know enough about Ozone internals to determine the best course of
> action for that implementation).

Okay, +1 for adding the removeXXX() methods to the interface.

Best Regards,
Gerd

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

Re: [Tm4j-developers] Towards 0.5

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

> Its been a while since a TM4J release and I feel that we have made some
> major progress that it would be good to get announced and released. I would
> like to draw up a list of things to do prior to an 0.5 release. Here is my
> shortlist:
> 
> 	1) Documentation: Just a basic developer's guide and some user docs for the
> tools
> 	2) Stabilise the TMNav application: It has been really buggy for a while -
> I've tracked down the cause of most of the error messages generated by
> TheBrain SDK and I think that the intermittent crashes are to do with
> deadlocks in AWT event processing which it might be possible to fix by
> splitting the application into separate top-level windows.
> 	3) Complete the Provider/Manager interface

I'd like the improve the ozone implementation, but I will not be able to this
within the next three weeks. Also some docu for the ozone stuff would be good.
 
> I'm going to be travelling and working away for much of this month, but
> hopefully will have some time while on the road to work on (1) and (2) and
> to make any changes necessary for (3). Once I get back I'll have some free
> time to finish off, so I'm tentatively planning on making 0.5 before the end
> of the month.
> 
> However, this means that a few things will probably not make the cut for
> 0.5. Such as:
> 	1) Index of *all* topic map objects by ID
> 	2) Implementing the duplicate suppression rules of XTM
> 	3) Implementing a different Open Source-based visualisation for TMNav
> 
> (1) and (2) I will try and do if there is time. (3) I'm playing with ideas
> for but don't even have a concrete design in mind at this stage, so it is
> almost certain to be left undone.

I've done a web based interface with Cocoon2, but it's very application
specfic. I'm not sure if a HTML based solution would be the right for a 
general TMNav solution. I had also some ideas for a graph based interface
as we have it now, but I'll have to think about it again.

Best Regards,
Gerd

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

[Tm4j-developers] Towards 0.5

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

Hi all,

Its been a while since a TM4J release and I feel that we have made some
major progress that it would be good to get announced and released. I would
like to draw up a list of things to do prior to an 0.5 release. Here is my
shortlist:

	1) Documentation: Just a basic developer's guide and some user docs for the
tools
	2) Stabilise the TMNav application: It has been really buggy for a while -
I've tracked down the cause of most of the error messages generated by
TheBrain SDK and I think that the intermittent crashes are to do with
deadlocks in AWT event processing which it might be possible to fix by
splitting the application into separate top-level windows.
	3) Complete the Provider/Manager interface

I'm going to be travelling and working away for much of this month, but
hopefully will have some time while on the road to work on (1) and (2) and
to make any changes necessary for (3). Once I get back I'll have some free
time to finish off, so I'm tentatively planning on making 0.5 before the end
of the month.

However, this means that a few things will probably not make the cut for
0.5. Such as:
	1) Index of *all* topic map objects by ID
	2) Implementing the duplicate suppression rules of XTM
	3) Implementing a different Open Source-based visualisation for TMNav

(1) and (2) I will try and do if there is time. (3) I'm playing with ideas
for but don't even have a concrete design in mind at this stage, so it is
almost certain to be left undone.

What are peoples thoughts on this ? Are there priority things that I have
missed out ?

Cheers,

Kal

RE: [Tm4j-developers] Suggestion regarding players

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

Hi Gerd,

I don't know how I managed to miss this message ... sorry for the delay in
replying.

I think that using a hashmap internally for Topic.rolesPlayed and
Member.player attributes might be a useful thing to do, and as you note, it
would enable a more convenient removeXXX() operation. However, it should be
noted that from an XTM spec point of view, this would not be sufficient to
meet the requirements to suppress duplicate players of roles in an
association. Also, I wonder about the time and space overhead of the use of
a HashMap in the in-memory implementation when the index would really only
be used for removals.

So my position would be +1 to adding the suggested operations to the
interface but -1 on using a HashMap for the in-memory implementation (I
don't yet know enough about Ozone internals to determine the best course of
action for that implementation).

Cheers,

Kal

> -----Original Message-----
> From: tm4...@li...
> [mailto:tm4...@li...]On Behalf Of Gerd
> Mueller
> Sent: 02 July 2001 14:22
> To: tm4...@li...
> Subject: [Tm4j-developers] Suggestion regarding players
>
>
>
> Hi,
>
> I've got a suggestion regarding the player-member management:
>
> At the moment the players of a member and the roles played by a
> topic are managed with an ArrayList. I would suggest to use a
> HashMap where the keys are the id's. Then we could add
> Member.removePlayer( Topic ) and Topic.removeRolePlayed( Member )
> methods with a good complexity. This would also avoid adding
> a player multiple times to a member.
>
> 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] Checkins

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

Folks,

I'm not sure what is up with the CVS notifications - I checked in a bunch of
stuff a while ago and haven't seen a notification message on the CVS list.
So, just to let you know, I have recently checked in a first cut of the
TopicMapProvider/TopicMapManager interface along with an implementation for
the in-memory backend. I would appreciate any feedback from folks on this.
All the new/modified files are in com/techquila/topicmap and
com/techquila/topicmap/test.

Cheers,

Kal

[Tm4j-developers] Suggestion regarding players

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

Hi,

I've got a suggestion regarding the player-member management:

At the moment the players of a member and the roles played by a
topic are managed with an ArrayList. I would suggest to use a
HashMap where the keys are the id's. Then we could add 
Member.removePlayer( Topic ) and Topic.removeRolePlayed( Member ) 
methods with a good complexity. This would also avoid adding 
a player multiple times to a member.

Best Regards,
Gerd

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

RE: [Tm4j-developers] Association.ofType()

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

> > C is only an association of type B. B is an instance of the
> class A, but A
> > is not a superclass of C. Sounds confusing ? :)
> >
> > The <instanceOf> element (which translates to the type or types
> attribute)
> > specifies a class-instance relationship. Topic maps are a powerful
> > information modelling tool because they allow a topic to be
> both a class and
> > an instance of a class.
> >
> > You can model the subclass-superclass relationship by using an
> association
> > with the XTM-defined PSIs which you will find declared as constants in
> > com.techquila.topicmap.PSI. To get the supertypes of a topic,
> you need to
> > first go to its type(s) and then for each of them, traverse the
> > subclass-superclass association to find superclasses.
>
> Okay, sound reasonable. Interesting point: What happens with
> cyclic dependencies ? E.g. A instanceof B, B instanceof C,
> C instanceof A. Nobody bars you to model this, but it could cause
> problems while processing.
>

It is true that you could get problems from this kind of dependancy loop -
though I think that different applications would have different ways of
wanting to handle it. I don't think that TM4J would have a problem - there
are relatively few functions which perform any kind of traversal, but an
editing application or a display application would need to be able to handle
cycles in the topic map model.

One thing that would be useful in a suite of topic map tools would be
utilities to discover these kinds of problems and report on them - perhaps
something like that should go into the command-line utilities package. This
raises another question: What other kinds of problems should a "topicmap
lint" application report on ? I would be interested in peoples' thoughts on
this...

Cheers,

Kal

Re: [Tm4j-developers] Association.ofType()

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

> C is only an association of type B. B is an instance of the class A, but A
> is not a superclass of C. Sounds confusing ? :)
> 
> The <instanceOf> element (which translates to the type or types attribute)
> specifies a class-instance relationship. Topic maps are a powerful
> information modelling tool because they allow a topic to be both a class and
> an instance of a class.
> 
> You can model the subclass-superclass relationship by using an association
> with the XTM-defined PSIs which you will find declared as constants in
> com.techquila.topicmap.PSI. To get the supertypes of a topic, you need to
> first go to its type(s) and then for each of them, traverse the
> subclass-superclass association to find superclasses.

Okay, sound reasonable. Interesting point: What happens with
cyclic dependencies ? E.g. A instanceof B, B instanceof C, 
C instanceof A. Nobody bars you to model this, but it could cause
problems while processing.

Best Regards,
Gerd

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

RE: [Tm4j-developers] Association.ofType()

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

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

C is only an association of type B. B is an instance of the class A, but A
is not a superclass of C. Sounds confusing ? :)

The <instanceOf> element (which translates to the type or types attribute)
specifies a class-instance relationship. Topic maps are a powerful
information modelling tool because they allow a topic to be both a class and
an instance of a class.

You can model the subclass-superclass relationship by using an association
with the XTM-defined PSIs which you will find declared as constants in
com.techquila.topicmap.PSI. To get the supertypes of a topic, you need to
first go to its type(s) and then for each of them, traverse the
subclass-superclass association to find superclasses.

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

The base topic is a construct that has no direct mapping to the XTM spec. In
the in-memory implementation, topic B gets merged with topic A by getting
added to the mergedTopics list property of A. Then, when A is asked for its
characteristics (such as names, occurrences, types or roles played in
associations), it will return the aggregate of all of its merged topics. For
this to work properly and for the "demerging" of topics to be supported, the
merged topics must also know which topic it is that they are merged with, so
the baseTopic property is really a back-pointer to the topic which is
serving as the "container" for all of the merged topics.


Hope this makes sense - I haven't finished my coffee yet...;-)
Cheers,

Kal