RE: [TM4J-users] Questions

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

Hi Richard,

> Looks like a lot of work has gone into TM4J!  Keen to get into it...

Welcome on board! ;-)

> Quick introduction:
> My name is Richard Watson, I work for a research company in South Africa
> called the CSIR.  We're playing around with TM4J for an internal prototype
> project, essentially a storage bank for ideas.  Using TM's as a
> network for
> finding related info.
>
> I'm not sure how keen you are on questions, but here are a few:
>

We love questions! They remind us that we need to write docs! :-)

> 1) ID's.  On importing a topic map using:
>
>      FileInputStream in = new FileInputStream(file);
>      InputSource src = new InputSource(in);
>      parser.parse(src);
>
>      TopicMap tm = builder.getTopicMap();
>
> we end up with all the topic id's changed.  Is there any way to preserve
> id's?

Thats kind of deliberate because you can load multiple XTM files into a
single TM4J topic map - if you do this, of course the individual topic ID
attribute value becomes meaningless. However, the full URL of the topic is
preserved and can be accessed using getResourceID() (this is in the
TopicMapObject interface). So that means that theoretically, it should be
possible to round trip a topic map and preserve ids by writing an export
class that uses the resourceID property rather than the ID property of the
objects to create the ID attribute value.

The TopicMap interface also has a getObjectsByResourceID() function so that
you can do lookups based on the (full) URL of the imported object.

>
> 2) If a topic is an instance of a topic that is in another file,
> how should
> we handle that?  It seems to create a dummy topic, but doesn't store the
> xlink anywhere.

That is probably a bug. The XTMBuilder class creates 'stub' topics whenever
it encounters a reference to a topic which it hasn't yet parsed. These stubs
are then replaced by the 'real thing' when it is encountered in the input
stream. Of course, if the 'real thing' is in another file, then the builder
won't replace the stub. Ideally, I think that the resourceID of the stub
topic should be set to the URL of the topic that wasn't found during the
parse - and that should probably happen at the end of the parse when the
builder is left with a list of unresolved stubs.


>
> I'm sure I'll have a few more over the next while. :)
>
Fire away !

Cheers,

Kal