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

Re: [Tm4j-developers] how are we different to DAML

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

At 03:57 PM 2/22/2002 +0000, Kal Ahmed wrote:
>Off the top of my head I would suggest a graph model. Just labelled nodes 
>and arcs (maybe with some "type" label too) That should be representable 
>in XML so it should be possible to apply XSLT - of course, thats not to 
>say that the mapping will be easy, but labelled nodes and arcs is probably 
>the lowest common denominator (or should that be highest common factor ?)
>
>A graph model also has the advantage of being relatively easy to represent 
>in a relational db (though it would probably be more efficient to use an 
>OO database, given the amount of traversal you would be doing).

Murray Altheim has become an advocate of GXL
http://www.gupro.de/GXL/

Cheers
Jack

Re: [Tm4j-developers] how are we different to DAML

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

At 07:13 22/02/2002 -0800, Jack Park wrote:
>At 09:08 AM 2/22/2002 +0000, Kal Ahmed wrote:
>>I would say one thing - ignore the markup argument. IMHO, the principle 
>>part of DAML is the specification of the primitives with which one can 
>>construct a rigorously defined ontology. The less significant part of 
>>DAML is its representation as RDF. In fact, if I were wanting to 
>>represent an ontology with a high degree of formal rigor (e.g. for later 
>>applying inference tools to the data set), then I would probably look at 
>>using DAML+OIL as an adjunct to the XTM map of the instance data. I could 
>>then use transformation tools (XSLT ?) to generate an XTM representation 
>>of the DAML+OIL ontology definition, while still using DAML+OIL tools to 
>>define my ontology and XTM tools to map it to real world resources.
>>
>>Cheers,
>>
>>Kal
>
>To which, I would like to point out that this is precisely the direction 
>that Nexist is headed!  In the long run, I want Nexist to be based on open 
>standards.  If you want a topic map from it, you get it in XTM.  If you 
>want an ontology, you get that in DAML/OIL.
>
>There exists, however, an open question: is there some canonical way to 
>represent everything in the database such that it can come out any way you 
>want it?  The idea being that you apply some transcoding scheme (i.e. 
>XSLT) to some canonical "document" (Douglas Engelbart calls this an 
>"iFile") to get the representation you want.

Off the top of my head I would suggest a graph model. Just labelled nodes 
and arcs (maybe with some "type" label too) That should be representable in 
XML so it should be possible to apply XSLT - of course, thats not to say 
that the mapping will be easy, but labelled nodes and arcs is probably the 
lowest common denominator (or should that be highest common factor ?)

A graph model also has the advantage of being relatively easy to represent 
in a relational db (though it would probably be more efficient to use an OO 
database, given the amount of traversal you would be doing).

Cheers,

Kal

Re: [Tm4j-developers] how are we different to DAML

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

At 09:08 AM 2/22/2002 +0000, Kal Ahmed wrote:
>I would say one thing - ignore the markup argument. IMHO, the principle 
>part of DAML is the specification of the primitives with which one can 
>construct a rigorously defined ontology. The less significant part of DAML 
>is its representation as RDF. In fact, if I were wanting to represent an 
>ontology with a high degree of formal rigor (e.g. for later applying 
>inference tools to the data set), then I would probably look at using 
>DAML+OIL as an adjunct to the XTM map of the instance data. I could then 
>use transformation tools (XSLT ?) to generate an XTM representation of the 
>DAML+OIL ontology definition, while still using DAML+OIL tools to define 
>my ontology and XTM tools to map it to real world resources.
>
>Cheers,
>
>Kal

To which, I would like to point out that this is precisely the direction 
that Nexist is headed!  In the long run, I want Nexist to be based on open 
standards.  If you want a topic map from it, you get it in XTM.  If you 
want an ontology, you get that in DAML/OIL.

There exists, however, an open question: is there some canonical way to 
represent everything in the database such that it can come out any way you 
want it?  The idea being that you apply some transcoding scheme (i.e. XSLT) 
to some canonical "document" (Douglas Engelbart calls this an "iFile") to 
get the representation you want.

Cheers,
Jack

Re: [Tm4j-developers] core xtm

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

At 12:44 22/02/2002 +1100, Smith, Tim wrote:
>Okay, I have been using <instanceOf> for parent-child relationships. On the
>topic map mail list someone said this was bad and the way to go was
> >    <association>
> >      <instanceOf><topicRef xlink:href="#parent-child"/></instanceOf>
> >      <member>
> >        <roleSpec><topicRef xlink:href="#parent"/></roleSpec>
> >        <topicRef xlink:href="#BA"/>
> >      </member>
> >      <member>
> >        <roleSpec><topicRef xlink:href="#child"/></roleSpec>
> >        <topicRef xlink:href="#BA1"/>
> >      </member>
> >    </association>
>I now have
><association>
>   <instanceOf><topicRef
>xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass"/>
></instanceOf>
>   <member>
>     <roleSpec><topicRef
>xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass"/></roleSpe
>c>
>     <topicRef xlink:href="#A-Parent"/>
>       </member>
>   <member>
>     <roleSpec><topicRef
>xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#subclass"/></roleSpec>
>     <topicRef xlink:href="#A-Child"/>
>     </member>
></association>
>HOWEVER as I understand it that would be dynamic interlinking/merging, which
>is not supported by TM4j (yet)
>CONSEQUENTLY am I required to redefine these 3 concepts with appropriate
>SIs, and if I do, will they STILL count as PSIs to TM4j (so I can check for
>PSI types)
>Puzzledly yours,
>Tim Smith

Actually, what you have specified is that the roleSpec is defined by a 
topic contained in the external topic map located at 
http://www.topicmaps.org/xtm/1.0/core.xtm. What TM4J will do is create a 
stub for that external topic which should have the full URI (e.g. 
http://www.topicmaps.org/xtm/1.0/core.xtm#subclass) as its resourceLocator.
If you have the latest CVS snapshot, which does now include some support 
for mergeMap and external topic reference processing, you should also find 
that "http://www.topicmaps.org/xtm/1.0/core.xtm is contained in the list 
returned by TopicMap.getExternalRefs(). You could then use 
TopicMapProvider.addTopicMap() to add the externally referenced topic map 
to you topic map (i.e. do the merge). If you do this, then calling 
Member,getRoleSpec().getResourceLocator() should return a locator whose 
address is http://www.topicmaps.org/xtm/1.0/core.xtm#subclass.

According to the XTM Processing Requirements of XTM 1.0, it is also equally 
valid to use a <subjectIndicatorRef> with the same URI (see XTM 1.0 Section 
F.3.1). If you do this, then calling 
Member.getRoleSpec().getSubjectIndicators() should return a collection 
containing a locator whose address is 
http://www.topicmaps.org/xtm/1.0/core.xtm#subclass

Finally, you can create a topic in your XTM file which has the URI as a 
subject indicator:

<topic id="mysubclass">
   <subjectIdentity><subjectIndicatorRef 
xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#subclass"/></subjectIdentity>
   <baseName><baseNameString>Sub-class</baseNameString></baseName>
</topic>

Then you refer to that topic in your roleSpec:

<association ... >
   <member>
     <roleSpec><topicRef xlink:href="#mysubclass"/></roleSpec>
   </member>
</association>

If you do this, the effect in TM4J is the same as simply embedding the 
<subjectIndicatorRef> in the <roleSpec> except that you have created a 
topic with a valid resourceLocator ({tm-base-uri}#mysubclass).

Eventually (like with the next release), I believe that 
Topic.getSubjectIndicators() should return a list containing all the 
explicitly defined subject indicators of the topic, plus all of the 
resourceLocators of the topic (as the upshot of Annex F is essentially that 
the URI of the topic should be treated as a subjectIndicator - and this is 
also a key part of PMTM4). In the meantime, you can cope with all of these 
(essentially equivalent) variations with code like this:

// Create Locators for the XTM PSIs
Locator subclassLoc = tm.getLocatorFactory.createLocator("URI", 
XTMPSI.SUBLCASS);
...

/**
  * Test if the specified Member plays a subclass role
  */
boolean isSubclass(Member m)
{
   Topic roleSpec = m.getRoleSpec();
   if (roleSpec == null) return false; // No role spec, so can't play 
subclass role
   // Check if PSI is one of the subject indicators of the roleSpec
   if (roleSpec.getSubjectIndicators().contains(subclassLoc)) return true;
   // Check if the PSI *is* the address of the roleSpec
   Locator resLoc = roleSpec.getResourceLocator();
   if ((resLoc != null) && (resLoc.equals(subclass)) return true;
   // If we get here, the roleSpec is not XTM subclass
   return false;
}


BTW - you called your relationships "parent-child". That can mean 
subclass-superclass (i.e. an instance of the subclass topic is also an 
instance of the superclass topic) or it can mean containment, or it can 
mean some other categorical hierarchy (e.g. broader-term/narrower-term in a 
thesaurus). Before going too far down this route, I would advise you to 
make sure that your definition of parent-child marries with the XTM 
definition of subclass-superclass.

Cheers,

Kal

Re: [Tm4j-developers] how are we different to DAML

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

At 19:55 21/02/2002 -0800, Jack Park wrote:
>At 10:28 AM 2/22/2002 +1100, Smith, Tim wrote:
>>I have been talking to a DAML guy here at work, and he seems to be saying
>>that DAML and TMs are pretty much the same.
>>Obviously I am missing something...
>>Can anyone tell me why TMs are superior to DAML?
>>Thanks
>>Tim Smith
>
>Tim,
>
>I'm sure Kal will have plenty to say about this, but my view is that they 
>are not really the same thing at all.
>
>True, they both define graph structures.
>True, they both deal with the same kinds of objects, mostly ontological 
>entities of one sort or another.
>
>But, they serve different purposes.  Topic Maps were invented as a means 
>of representating and navigating information resources, while DAML was 
>invented to represent those resources, and do that to a much finer 
>granularity than is easily accomplished with XTM.
>
>True, you can define lots of relations and use PSIs to do so.  That is to 
>say, one way or the other, you can make XTM serve the same purpose as 
>DAML/OIL, and, while I haven't spent any time trying to do so, I imagine 
>that you can find a way to use DAML as a navigational tool.
>
>Nobody is superior to the other, IMHO.  Rather, each technology, XTM and 
>DAML have contexts in which one is better suited: representation of 
>a  information resource space with XTM, and representation of an ontology 
>within that space with DAML.
>
>Cheers
>Jack

I agree with Jack. And I also think that he has hit the nail on the head 
with his analysis of the relative "purposes" of the two technologies. It is 
possible to use Topic Maps to describe minutiae about information 
resources, and it is possible to use DAML to map conceptual relationships 
between resources. But in practice, having both tools in your toolbox makes 
sense.

In fact, Jack hasn't left me with much to add ;-)

I would say one thing - ignore the markup argument. IMHO, the principle 
part of DAML is the specification of the primitives with which one can 
construct a rigorously defined ontology. The less significant part of DAML 
is its representation as RDF. In fact, if I were wanting to represent an 
ontology with a high degree of formal rigor (e.g. for later applying 
inference tools to the data set), then I would probably look at using 
DAML+OIL as an adjunct to the XTM map of the instance data. I could then 
use transformation tools (XSLT ?) to generate an XTM representation of the 
DAML+OIL ontology definition, while still using DAML+OIL tools to define my 
ontology and XTM tools to map it to real world resources.

Cheers,

Kal

Re: [Tm4j-developers] how are we different to DAML

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

At 10:28 AM 2/22/2002 +1100, Smith, Tim wrote:
>I have been talking to a DAML guy here at work, and he seems to be saying
>that DAML and TMs are pretty much the same.
>Obviously I am missing something...
>Can anyone tell me why TMs are superior to DAML?
>Thanks
>Tim Smith

Tim,

I'm sure Kal will have plenty to say about this, but my view is that they 
are not really the same thing at all.

True, they both define graph structures.
True, they both deal with the same kinds of objects, mostly ontological 
entities of one sort or another.

But, they serve different purposes.  Topic Maps were invented as a means of 
representating and navigating information resources, while DAML was 
invented to represent those resources, and do that to a much finer 
granularity than is easily accomplished with XTM.

True, you can define lots of relations and use PSIs to do so.  That is to 
say, one way or the other, you can make XTM serve the same purpose as 
DAML/OIL, and, while I haven't spent any time trying to do so, I imagine 
that you can find a way to use DAML as a navigational tool.

Nobody is superior to the other, IMHO.  Rather, each technology, XTM and 
DAML have contexts in which one is better suited: representation of 
a  information resource space with XTM, and representation of an ontology 
within that space with DAML.

Cheers
Jack

[Tm4j-developers] core xtm

[Smith, T. <Tim...@ds...>]

Okay, I have been using <instanceOf> for parent-child relationships. On the
topic map mail list someone said this was bad and the way to go was
>    <association>
>      <instanceOf><topicRef xlink:href="#parent-child"/></instanceOf>
>      <member>
>        <roleSpec><topicRef xlink:href="#parent"/></roleSpec>
>        <topicRef xlink:href="#BA"/>
>      </member>
>      <member>
>        <roleSpec><topicRef xlink:href="#child"/></roleSpec>
>        <topicRef xlink:href="#BA1"/>
>      </member>
>    </association>
I now have
<association>
  <instanceOf><topicRef
xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass"/>
</instanceOf>
  <member>
    <roleSpec><topicRef
xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass"/></roleSpe
c>
    <topicRef xlink:href="#A-Parent"/>
      </member>
  <member>
    <roleSpec><topicRef
xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#subclass"/></roleSpec>
    <topicRef xlink:href="#A-Child"/>
    </member>
</association>
HOWEVER as I understand it that would be dynamic interlinking/merging, which
is not supported by TM4j (yet)
CONSEQUENTLY am I required to redefine these 3 concepts with appropriate
SIs, and if I do, will they STILL count as PSIs to TM4j (so I can check for
PSI types)
Puzzledly yours,
Tim Smith

[Tm4j-developers] how are we different to DAML

[Smith, T. <Tim...@ds...>]

I have been talking to a DAML guy here at work, and he seems to be saying
that DAML and TMs are pretty much the same.
Obviously I am missing something...
Can anyone tell me why TMs are superior to DAML?
Thanks
Tim Smith

RE: [Tm4j-developers] [PATCH] Some improvements for LocatorFactory

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

At 23:07 18/02/2002 +0100, Florian G. Haas wrote:
>Hello.
>
>[Kal]
>| [...]
>| Could you apply the patches and check them in ?
>
>I've done this, and from what ViewCVS tells me, everything shows up fine in
>the repository. I have not received a syncmail message on the tm4j-commits
>list, though... perhaps a config error on SF's part, or a simple delay.

Probably just a delay - I've got the commit messages from SourceForge.

>You
>might want to do a "cvs update" in src/org/tm4j/net if you want to make sure
>you've got the latest versions.

Will do!

Cheers,

Kal

RE: [Tm4j-developers] [PATCH] Some improvements for LocatorFactory

[Florian G. H. <f.g...@gm...>]

Hello.

[Kal]
| [...]
| Could you apply the patches and check them in ?

I've done this, and from what ViewCVS tells me, everything shows up fine in
the repository. I have not received a syncmail message on the tm4j-commits
list, though... perhaps a config error on SF's part, or a simple delay. You
might want to do a "cvs update" in src/org/tm4j/net if you want to make sure
you've got the latest versions.

Later,
-- Florian

Re: [Tm4j-developers] [PATCH] Some improvements for LocatorFactory

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

Hi Florian,

This patch looks good - it certainly cleans up implementation of new 
Locator types for the in-memory backend. I am not sure how easy it will be 
to port this to the Ozone backend. The LocatorBase abstract class should 
probably be modified too (to remove setFactory() and initialise(), although 
it might be necessary to retain something like this for the 
OzoneLocatorBase class (because it is easier to have no-arg constructors 
with Ozone objects) but the necessary casts that would be required would be 
localised within the OzoneLocatorFactoryImpl class, so that shouldn't be a 
problem.

Could you apply the patches and check them in ?

Cheers,

Kal

At 18:19 17/02/2002 +0100, Florian G. Haas wrote:
>Hello.
>
>I've hacked up some changes to LocatorFactory-related classes and would ask
>anyone who's interested to evaluate them. Just take a look -- I'd greatly
>appreciate any comments. Note that this is a patch against the current
>status of the CVS tree, not a TM4J distribution, which is why I only post it
>to this list, not the patch management system at SourceForge. What this
>patch includes:
>
>* A LocatorFactoryBase class, serving as an abstract base class for locator
>factories (who would've guessed), with an implementation of the
>createLocator() method, a generic getImplementation() method returning the
>implementing class for a given notation, and overloaded
>removeImplementation() and registerImplementation() convenience methods with
>String instead of Class arguments.
>* An in-memory LocatorFactoryImpl altered to extend LocatorFactoryBase.
>* An additional test in LocatorFactoryTest with a dummy Locator
>implementation to make sure everything works.
>
>I think the LocatorFactoryBase class with the implemented createLocator()
>method and the abstract getImplementation() method makes locator factory
>implementations a lot more straightforward. Extending LocatorFactoryBase
>means that the implementing class only has to define ways to register and
>remove implementations, and to return a corresponding implementing class for
>a locator notation. No need to worry about actually creating locators.
>
>LocatorFactoryBase.createLocator() uses a bit of metaclass hacking in order
>to actually instantiate the locator. If you're interested, please take a
>look at it and tell me how you feel about this. What it assumes is that any
>valid locator implementation has a constructor with a (LocatorFactory,
>String, String) signature. I think this is reasonable because locators
>should not be created outside the context of a factory and should always
>have a notation and address. If it can't detect such a constructor,
>createLocator() throws a LocatorFactoryException with an explanatory detail
>message. With this approach, it obsoletes the use of initialise() and
>setFactory() on the locator altogether, and I think that's a Good Thing
>because it ultimately means that we could do away with these methods, and a
>locator without a factory, notation, and address would never exist. The way
>things are now, we allow locators to float in free space without an owning
>factory and in an unitialized state, and this IMHO is downright ugly. :-)
>There are obviously some disadvantages to my alternative, too -- such as the
>fact that an implementation design error (not providing a decent
>constructor) will only be detected at run-time, not compile-time. This calls
>for making the constructor requirement absolutely clear in the Locator
>interface documentation. So we have to weigh alternatives here. Certainly no
>hard feelings on my part if we leave things the way they are now.
>
>Furthermore, I think a getImplementation() method should actually be
>specified by the Locator interface. But that's a detail.
>
>- PATCH INSTRUCTIONS (just for completeness' sake)
>
>* Applying the patch
>1. Unzip/untar the attached archive in the root directory of your "tm4j" CVS
>module.
>2. Run "./tm4j-net-patch-2002-02-17" This will patch the ant buildfile and
>call the "tm4j-net-patch-2002-02-17" target. On Windows, you'll have to
>patch the build file manually and then run that target.
>3. Build the "tm4j-net-build" and/or "tm4j-net-test" target.
>
>* Un-applying the patch
>Either restore the affected files
>(src/org/tm4j/net/memory/LocatorFactoryImpl.java and
>src/org/tm4j/net/test/LocatorFactoryTest.java) with "cvs update -C", or
>overwrite the patched files with the ".orig" files in the same respective
>directories. Then build tm4j-net-build.
>
>Hope you like it! :-)
>
>-- Florian

[Tm4j-developers] [PATCH] Some improvements for LocatorFactory

[Florian G. H. <f.g...@gm...>]

Hello.

I've hacked up some changes to LocatorFactory-related classes and would ask
anyone who's interested to evaluate them. Just take a look -- I'd greatly
appreciate any comments. Note that this is a patch against the current
status of the CVS tree, not a TM4J distribution, which is why I only post it
to this list, not the patch management system at SourceForge. What this
patch includes:

* A LocatorFactoryBase class, serving as an abstract base class for locator
factories (who would've guessed), with an implementation of the
createLocator() method, a generic getImplementation() method returning the
implementing class for a given notation, and overloaded
removeImplementation() and registerImplementation() convenience methods with
String instead of Class arguments.
* An in-memory LocatorFactoryImpl altered to extend LocatorFactoryBase.
* An additional test in LocatorFactoryTest with a dummy Locator
implementation to make sure everything works.

I think the LocatorFactoryBase class with the implemented createLocator()
method and the abstract getImplementation() method makes locator factory
implementations a lot more straightforward. Extending LocatorFactoryBase
means that the implementing class only has to define ways to register and
remove implementations, and to return a corresponding implementing class for
a locator notation. No need to worry about actually creating locators.

LocatorFactoryBase.createLocator() uses a bit of metaclass hacking in order
to actually instantiate the locator. If you're interested, please take a
look at it and tell me how you feel about this. What it assumes is that any
valid locator implementation has a constructor with a (LocatorFactory,
String, String) signature. I think this is reasonable because locators
should not be created outside the context of a factory and should always
have a notation and address. If it can't detect such a constructor,
createLocator() throws a LocatorFactoryException with an explanatory detail
message. With this approach, it obsoletes the use of initialise() and
setFactory() on the locator altogether, and I think that's a Good Thing
because it ultimately means that we could do away with these methods, and a
locator without a factory, notation, and address would never exist. The way
things are now, we allow locators to float in free space without an owning
factory and in an unitialized state, and this IMHO is downright ugly. :-)
There are obviously some disadvantages to my alternative, too -- such as the
fact that an implementation design error (not providing a decent
constructor) will only be detected at run-time, not compile-time. This calls
for making the constructor requirement absolutely clear in the Locator
interface documentation. So we have to weigh alternatives here. Certainly no
hard feelings on my part if we leave things the way they are now.

Furthermore, I think a getImplementation() method should actually be
specified by the Locator interface. But that's a detail.

- PATCH INSTRUCTIONS (just for completeness' sake)

* Applying the patch
1. Unzip/untar the attached archive in the root directory of your "tm4j" CVS
module.
2. Run "./tm4j-net-patch-2002-02-17" This will patch the ant buildfile and
call the "tm4j-net-patch-2002-02-17" target. On Windows, you'll have to
patch the build file manually and then run that target.
3. Build the "tm4j-net-build" and/or "tm4j-net-test" target.

* Un-applying the patch
Either restore the affected files
(src/org/tm4j/net/memory/LocatorFactoryImpl.java and
src/org/tm4j/net/test/LocatorFactoryTest.java) with "cvs update -C", or
overwrite the patched files with the ".orig" files in the same respective
directories. Then build tm4j-net-build.

Hope you like it! :-)

-- Florian

Re: [Tm4j-developers] TM4J 0.7.0 Features (Long)

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

At 14:23 15/02/2002 +0100, you wrote:
>Hi,
>
>the list of new possible features looks quite impressive.
>Beside the access and storage APIs I think that the
>creation and display part of it still lacks some code.
>I really love the idea of having XSLT and SVG display
>capabilities (or even XSP sheets). But I think Gerd
>is right. Every more general display capability will
>depend upon a query language.

Eventually, I would like to build support for TMQL - whatever that turns 
out to look like when ISO are done with it. In the short term, though I 
think that Gerd's suggestion of Tolog support is an excellent one and would 
certainly help with both display and editing/creationg applications.

>What is really missing for me is some basic editing
>environment for topicmaps (yes i tried and I failed).
>It would be quite cool to have some XUL based App-/
>Webfrontend to edit maps. But I think that this is
>much of an overhead we cannot cope with, isn't it?

I think that a form-based editing environment would probably have to be 
built on some form of "topic map schema" support - we could use one of the 
proposed schema forms, or create our own or wait for ISO. I too would like 
to see a "pure" topic map editing application, but in the meantime, you 
could use TMTab (http://www.techquila.com/tmtab/index.html) - you cannot 
edit XTM sources directly with it, but you can create ontologies and then 
export them in XTM syntax.

Cheers,

Kal

Re: [Tm4j-developers] svg and question

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

At 10:15 15/02/2002 +1100, Smith, Tim wrote:


>&-----Original Message-----
>&From: Kal Ahmed [mailto:ka...@te...]
>&Sent: Thursday, 14 February 2002 7:24 PM
>&To: Florian G. Haas; tm4...@li...
>&Subject: RE: [Tm4j-developers] TM4J 0.7.0 Features (Long)
>&
>&
>&At 18:56 13/02/2002 +0100, Florian G. Haas wrote:
>&>Kal,
>&>
>&>I very much like your ideas. Sound like a lot of work, but great ideas
>&>nevertheless! :-)
>&>
>&>Well, as for another feature, I realize I might be jumping
>&the gun a little
>&>bit, but while we're talking about dynamic, possibly XSLT-centered web
>&>applications, shouldn't we give an SVG front-end a thought?
>&Anyone up for
>&>that? (I realize this definitely sounds like a post-0.7.0 or
>&even post-1.0
>&>feature)
>&
>&That sounds way cool - actually, I saw a presentation on this
>&subject at
>&XML 2001 last year - the presenter had combined SVG graphics for
>&presentation with some statistically-based filtering which
>&"clusters" the
>&topic map into regions and subregions. Sounds like the kind of
>&interesting
>&thing which should be built on TM4J ;-)
>
>That sounds extremely cool... I may be the only one here wondering, but what
>is "SVG graphics" please?

SVG is an XML vocabulary for defining two-dimensional graphics (vectors and 
bitmaps) and text - it is quite a rich format, allowing grouping, 
transformations (such as rotation), clipping and so on. It is also possible 
to do Flash-style interactive animations with SVG.

>Also, can anyone help em with this:
>The people I work with all say
>"but couldn't everything you do with TMs be done with relational databases
>and a bit more work? Or maybe with a Semantic web?"
>I tell them that yes, everything in TMs can be done with relational
>databases (TM4J maps to Ozone, so I guess it is true) in much the same way
>that everything you do with C++ can be done in assembler.
>TMs add STANDARDISATION (an approved yet flexible specification), METAPHOR
>(the circle/association/occurence brain like diagrams work well) and
>EASE-OF-USE (should be a hell of a lot easier to build related TMs than
>innterrelate and maintain a host of seperate dbs).
>Am I wrong or missing anything?

You aren't at all wrong, IMHO - though I may be biased ;-).  See 
http://www.techquila.com/bcase.html for a paper I presented at XML 2001 - 
this paper doesn't talk about why people *should* use topic maps, it talks 
about why people *are using* topic maps - makes for a much more convincing 
argument, and as you will see, the arguments for topic maps break down into 
those three categories you have listed above.

Cheers,

Kal

Re: [Tm4j-developers] TM4J 0.7.0 Features (Long)

[Norbert H. <rue...@se...>]

Hi,

the list of new possible features looks quite impressive.
Beside the access and storage APIs I think that the
creation and display part of it still lacks some code.
I really love the idea of having XSLT and SVG display
capabilities (or even XSP sheets). But I think Gerd
is right. Every more general display capability will
depend upon a query language.
What is really missing for me is some basic editing
environment for topicmaps (yes i tried and I failed).
It would be quite cool to have some XUL based App-/
Webfrontend to edit maps. But I think that this is
much of an overhead we cannot cope with, isn't it?

just to say a few words :)

NoB

[Tm4j-developers] svg and question

[Smith, T. <Tim...@ds...>]

&-----Original Message-----
&From: Kal Ahmed [mailto:ka...@te...]
&Sent: Thursday, 14 February 2002 7:24 PM
&To: Florian G. Haas; tm4...@li...
&Subject: RE: [Tm4j-developers] TM4J 0.7.0 Features (Long)
&
&
&At 18:56 13/02/2002 +0100, Florian G. Haas wrote:
&>Kal,
&>
&>I very much like your ideas. Sound like a lot of work, but great ideas
&>nevertheless! :-)
&>
&>Well, as for another feature, I realize I might be jumping 
&the gun a little
&>bit, but while we're talking about dynamic, possibly XSLT-centered web
&>applications, shouldn't we give an SVG front-end a thought? 
&Anyone up for
&>that? (I realize this definitely sounds like a post-0.7.0 or 
&even post-1.0
&>feature)
&
&That sounds way cool - actually, I saw a presentation on this 
&subject at 
&XML 2001 last year - the presenter had combined SVG graphics for 
&presentation with some statistically-based filtering which 
&"clusters" the 
&topic map into regions and subregions. Sounds like the kind of 
&interesting 
&thing which should be built on TM4J ;-)

That sounds extremely cool... I may be the only one here wondering, but what
is "SVG graphics" please?

Also, can anyone help em with this: 
The people I work with all say
"but couldn't everything you do with TMs be done with relational databases
and a bit more work? Or maybe with a Semantic web?"
I tell them that yes, everything in TMs can be done with relational
databases (TM4J maps to Ozone, so I guess it is true) in much the same way
that everything you do with C++ can be done in assembler. 
TMs add STANDARDISATION (an approved yet flexible specification), METAPHOR
(the circle/association/occurence brain like diagrams work well) and
EASE-OF-USE (should be a hell of a lot easier to build related TMs than
innterrelate and maintain a host of seperate dbs).
Am I wrong or missing anything?
Thanks in advance
Tim 

[Tm4j-developers] TM4J 0.7.0 Features Survey

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

Please take a few minutes to complete the survey now online at:

https://sourceforge.net/survey/survey.php?group_id=27895&survey_id=12717

This will help us prioritise features to be developed in 0.7.0 and beyond. 
This survey will be active from today through to Monday.

Feel free to continue discussion on the mailing lists too!

Cheers,

Kal

RE: [Tm4j-developers] TM4J 0.7.0 Features (Long)

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

At 18:56 13/02/2002 +0100, Florian G. Haas wrote:
>Kal,
>
>I very much like your ideas. Sound like a lot of work, but great ideas
>nevertheless! :-)
>
>Well, as for another feature, I realize I might be jumping the gun a little
>bit, but while we're talking about dynamic, possibly XSLT-centered web
>applications, shouldn't we give an SVG front-end a thought? Anyone up for
>that? (I realize this definitely sounds like a post-0.7.0 or even post-1.0
>feature)

That sounds way cool - actually, I saw a presentation on this subject at 
XML 2001 last year - the presenter had combined SVG graphics for 
presentation with some statistically-based filtering which "clusters" the 
topic map into regions and subregions. Sounds like the kind of interesting 
thing which should be built on TM4J ;-)

>BUT, aside from all that, let me humbly pitch in my idea that perhaps we
>shouldn't get all too excited now about new cool stuff we are planning to
>incorporate into TM4J. Maybe we should take a little time for QA issues, and
>documentation. The dev guide is great (hats off, Kal), but as Tim Smith has
>thankfully pointed out, the rest of the documentation may still be lacking a
>number of touch-ups. I realize I may be spoiling everybody's fun to a
>certain extent, but I believe that if we want to get people working with
>this thing, we had better get it into a condition where they can use it as
>an out-of-the-box tool. So I agree with you, Kal, about the issues you
>consider "REQUIRED" (because those are the ones that will get TM4J into
>exactly that condition), but I really believe we should put other insane
>features -- like the one I mention above :-) -- off for the moment.

Ah ! The voice of reason ! ;-)

I deliberately threw a lot of stuff into the feature list so that we could 
start by choosing the stuff we really really want in 0.7.0 and then try and 
work out a longer term road-map for implementing the other stuff. But I 
must admit that I did miss out documentation improvements and I shouldn't 
have done so. We *do* need much better documentation. Preferably topic 
mapped! The developer's guide is a start, but the work that Florian has 
done on the project topic map and the start of a FAQ topic map should 
definitely be persued.

So lets add

  - Developer's documentation
       Installation and Building Guide
       Developer's Guide
       Developer's FAQ

to the list.


>A couple of QA issues that would jump to my mind:
>
>* Have we yet even decided on whether we want to follow Appendix F of the
>XTM spec (http://www.topicmaps.org/xtm/1.0/#processing) or PMTM
>(http://www.topicmaps.net/pmtm4.htm) in terms of TM processing? Or do we
>want to make this pluggable functionality, leaving it up to the user to
>decide on the processing model? The implementations available indicate that
>for now, we're sticking to Annex F, but have we ever put that down for other
>people to realize?

It is true that I developed a data model with the intention to support 
Annex F, rather than PMTM4 (which didn't really exist when I started on 
this). PMTM4 could probably be supported in a layer over an Annex F 
compliant TM processor (actually, it would be an interesting exercise to 
try this and see where any mismatches occur). We should document that we 
are working towards full XTM 1.0 Conformance (including Annex F).

>* Assuming for a moment that we do go for Annex F, how are we doing on
>association merging? Role player duplicate suppression? Equality and
>equivalence principles? Hierarchical variant-inside-variant processing?
>Equivalence of <instanceOf> and the class-instance association in XTM
>parsing?

Some of these are already handled - e.g. Topic.addType() creates a 
class-instance association as well as updating the types property of the 
topic. The XTM Compressor (possible a bad name) - 
org.tm4j.topicmap.utils.Compressor implements much of Annex F, but it does 
so as a post-processing operation which can be quite time-consuming for 
bigger topic maps.

One of the issues of full XTM 1.0 conformance is that XTM 1.0 assumes that 
when two topics are merged only one topic remains - this is not true in 
TM4J - I wanted to allow programmers to merge and "unmerge" topics and to 
be able to programmatically find out what topics were merged together - I 
believe that these will be useful features in manual topic map generation 
and merging ("Wait, I didn't want those topics to merge! Let me just change 
the scope name of the second topic..." - that would be impossible if the 
processor had already compressed the two topics into a single object).

However, I don't think that this is an insurmountable problem - there are a 
couple of different ways of handling it and we should discuss this further.


>Have I crushed anyone's enthusiasm? If so, I apologize. ;-)

Not at all! These are good points - thanks for giving it this much thought!

Cheers,

Kal

RE: [Tm4j-developers] TM4J 0.7.0 Features (Long)

[Florian G. H. <f.g...@gm...>]

Kal,

I very much like your ideas. Sound like a lot of work, but great ideas
nevertheless! :-)

Well, as for another feature, I realize I might be jumping the gun a little
bit, but while we're talking about dynamic, possibly XSLT-centered web
applications, shouldn't we give an SVG front-end a thought? Anyone up for
that? (I realize this definitely sounds like a post-0.7.0 or even post-1.0
feature)

BUT, aside from all that, let me humbly pitch in my idea that perhaps we
shouldn't get all too excited now about new cool stuff we are planning to
incorporate into TM4J. Maybe we should take a little time for QA issues, and
documentation. The dev guide is great (hats off, Kal), but as Tim Smith has
thankfully pointed out, the rest of the documentation may still be lacking a
number of touch-ups. I realize I may be spoiling everybody's fun to a
certain extent, but I believe that if we want to get people working with
this thing, we had better get it into a condition where they can use it as
an out-of-the-box tool. So I agree with you, Kal, about the issues you
consider "REQUIRED" (because those are the ones that will get TM4J into
exactly that condition), but I really believe we should put other insane
features -- like the one I mention above :-) -- off for the moment.

A couple of QA issues that would jump to my mind:

* Have we yet even decided on whether we want to follow Appendix F of the
XTM spec (http://www.topicmaps.org/xtm/1.0/#processing) or PMTM
(http://www.topicmaps.net/pmtm4.htm) in terms of TM processing? Or do we
want to make this pluggable functionality, leaving it up to the user to
decide on the processing model? The implementations available indicate that
for now, we're sticking to Annex F, but have we ever put that down for other
people to realize?
* Assuming for a moment that we do go for Annex F, how are we doing on
association merging? Role player duplicate suppression? Equality and
equivalence principles? Hierarchical variant-inside-variant processing?
Equivalence of <instanceOf> and the class-instance association in XTM
parsing?

Have I crushed anyone's enthusiasm? If so, I apologize. ;-) If you consider
this worth discussing, though, you'll make me a very happy camper.

Later,
-- Florian

[Tm4j-developers] Re: [TM4J-users] TM4J 0.7.0 Features (Long)

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

Hi,

I'd like to add one more issue, although I don't think that this will be part
of 0.7.0. I think we need a query language and I vote for Tolog. Maybe my
company will hire a student in the next few months who will write his
diploma thesis about Tolog. I'll get back to you if I know more about it.

Also I'm particular interested in developing the TM4J frontends for Cocoon
and the graph visualisation. If I can spare some time I'll give a helping
hand on this issues.

Best Regards,
gerd

> Now that 0.6.0 has been released, I am starting work on collecting the 
> features list for 0.7.0. Below is a list of some of the features I have in 
> mind. I would like to hear from anyone that has suggestions for additional 
> features. I would like to make the release cycle for 0.7.0 much shorter 
> than we had for 0.6.0, but that does mean that , without a lot of help, not 
> all of these features will make it in to the release. What I am proposing 
> to do is to collect together a list of the features proposed and create a 
> survey on SourceForge which we can all vote in and then try and partition 
> the voted on list into 0.7.0 and post-0.7.0 features.
> 
> Here are the features I have so far:
> 
> Locator resolution interfaces [REQUIRED]
>    The current Locator interface provides no way to retrieve the data at 
> the end of the locator.
>    This is *required* in order to be able to properly support the mergeMap 
> feature (see below).
>    This would probably take the form of a separate LocatorResolver 
> interface which would return
>    a data stream for a given Locator. The architecture for this would be 
> flexible and support
>    plug-in extensibility for different locator notations. This feature 
> would include the following
>    sub-features:
>    o  Pluggable URI resolution implementation
>    o    http: URI resolution
>    o    file: URI resolution
>    o  Catalog-based locator resolution implementation
> 
> ID round-tripping [REQUIRED]
>    Support the direct mapping of -id- attribute values in the input XTM 
> file into the value of the
>    ID property of the Java objects created by the XTMBuilder. This would 
> enable complete
>    round-tripping of -id- attribute values in most trivial cases. When 
> loading multiple XTM files
>    into a single TopicMap object, some additional attribute processing may 
> be required to
>    prevent DuplicateObjectIDExceptions getting thrown (alternatively, this 
> could just happen...)
> 
> Merge-map support [REQUIRED]
>    This is the last major piece of XTM support required for TM4J.
> 
> External topic reference processing [REQUIRED]
>    This is the *other* last major piece of XTM support required for TM4J ;-)
> 
> More flexible indexing architecture
>    Split the indexes away from the TopicMap object - this would make it 
> easier to interface
>    with persistent storage systems which provide an alternative means of 
> query (e.g. Ozone
>    or an RDBMS). It would also significantly simplify the TopicMap 
> implementations.
>    Elements of this feature include:
>      o  Basic index interface
>      o  In-memory Index implementations
>      o  Ozone Index implementations
> 
> Rework DOM implementation to work on XML-DB (http://www.xmldb.org/index.html)
>    XML-DB is a standard API for XML repositories, which is based on DOM and
>    XPath. The work already started on the DOM implementation should be pretty
>    straightforward to port to XML-DB. The original intention of building a 
> TM4J interface
>    on an in-memory DOM structure does not need to be abandoned - the two
>    could probably be supported by a single interface.
> 
> JDBC/RDBMS implementation
>    Apparently some people still like relational systems...
> 
> New TMNav architecture
>    This would include:
>    o  TMNav browser implementation
>    o  Touchgraph visualisation
>    o  TMNav editor implementation
> 
> Improve consistency of use of Log4J
>    o  Ensure only Log4J is used for logging warnings/errors
>    o  Ensure command line apps and other apps initialise Log4J correctly
>    o  Create default Log4J initialisation object
> 
> Support for ISO Topic Map Syntax
>    o  Support at least import of topic maps in ISO syntax (with the
>        HyTime links replaced with URI references.
> 
> Dynamic web publishing application (based on Cocoon)
>    o  Cocoon generator for topic maps
>    o  Some XSLT templates for viewing topics
>    o   Additional utility classes for extracting and sorting topic names,
>        occurrences associations etc.
> 
> Static/dynamic web publishing application (based on Velocity)
>    o Utility classes for extracting and sorting topic names, occurrences,
>       associations etc.
>    o Configurable framework for using Velocity templates to view topic map
>       objects
>     o Wrapper application to allow deployment in a servlet container
>     o Wrapper application to allow invocation of the processing from the 
> command line
> 
> Support Canonical XTM output
>    This could form the basis for conformance testing.
>    See http://www.ontopia.net/topicmaps/materials/cxtm.html for a description
>    of Canonical XTM format
> 
> Support LTM input
>    This is a simple text format for topic maps (without the XML verbosity)
>    See http://www.ontopia.net/download/ltm.html for a description of LTM.
> 
> Please note, this is not a closed list ! If you have other suggestions, 
> feel free to add them. And just because something is not initially 
> suggested or not voted in for release 0.7.0 does not necessarily mean that 
> it cannot be included in that release - as long as some one is willing to 
> take on the work.
> 
> I look forward to hearing your thoughts!
> 
> Cheers,
> 
> Kal
> 
> 
> _______________________________________________
> Tm4j-users mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-users


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

Re: [Tm4j-developers] TM4J 0.7.0 Features (Long)

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

Kal,
I like all of these very much.
Particularly, integration with projects like Cocoon, Xindices (was dbXML), 
and so forth.

Cheers
Jack

At 08:53 PM 2/11/2002 +0000, Kal Ahmed wrote:
>Hi,
>
>Now that 0.6.0 has been released, I am starting work on collecting the 
>features list for 0.7.0. Below is a list of some of the features I have in 
>mind. I would like to hear from anyone that has suggestions for additional 
>features. I would like to make the release cycle for 0.7.0 much shorter 
>than we had for 0.6.0, but that does mean that , without a lot of help, 
>not all of these features will make it in to the release. What I am 
>proposing to do is to collect together a list of the features proposed and 
>create a survey on SourceForge which we can all vote in and then try and 
>partition the voted on list into 0.7.0 and post-0.7.0 features.
>
>Here are the features I have so far:
>
>Locator resolution interfaces [REQUIRED]
>   The current Locator interface provides no way to retrieve the data at 
> the end of the locator.
>   This is *required* in order to be able to properly support the mergeMap 
> feature (see below).
>   This would probably take the form of a separate LocatorResolver 
> interface which would return
>   a data stream for a given Locator. The architecture for this would be 
> flexible and support
>   plug-in extensibility for different locator notations. This feature 
> would include the following
>   sub-features:
>   o  Pluggable URI resolution implementation
>   o    http: URI resolution
>   o    file: URI resolution
>   o  Catalog-based locator resolution implementation
>
>ID round-tripping [REQUIRED]
>   Support the direct mapping of -id- attribute values in the input XTM 
> file into the value of the
>   ID property of the Java objects created by the XTMBuilder. This would 
> enable complete
>   round-tripping of -id- attribute values in most trivial cases. When 
> loading multiple XTM files
>   into a single TopicMap object, some additional attribute processing may 
> be required to
>   prevent DuplicateObjectIDExceptions getting thrown (alternatively, this 
> could just happen...)
>
>Merge-map support [REQUIRED]
>   This is the last major piece of XTM support required for TM4J.
>
>External topic reference processing [REQUIRED]
>   This is the *other* last major piece of XTM support required for TM4J ;-)
>
>More flexible indexing architecture
>   Split the indexes away from the TopicMap object - this would make it 
> easier to interface
>   with persistent storage systems which provide an alternative means of 
> query (e.g. Ozone
>   or an RDBMS). It would also significantly simplify the TopicMap 
> implementations.
>   Elements of this feature include:
>     o  Basic index interface
>     o  In-memory Index implementations
>     o  Ozone Index implementations
>
>Rework DOM implementation to work on XML-DB (http://www.xmldb.org/index.html)
>   XML-DB is a standard API for XML repositories, which is based on DOM and
>   XPath. The work already started on the DOM implementation should be pretty
>   straightforward to port to XML-DB. The original intention of building a 
> TM4J interface
>   on an in-memory DOM structure does not need to be abandoned - the two
>   could probably be supported by a single interface.
>
>JDBC/RDBMS implementation
>   Apparently some people still like relational systems...
>
>New TMNav architecture
>   This would include:
>   o  TMNav browser implementation
>   o  Touchgraph visualisation
>   o  TMNav editor implementation
>
>Improve consistency of use of Log4J
>   o  Ensure only Log4J is used for logging warnings/errors
>   o  Ensure command line apps and other apps initialise Log4J correctly
>   o  Create default Log4J initialisation object
>
>Support for ISO Topic Map Syntax
>   o  Support at least import of topic maps in ISO syntax (with the
>       HyTime links replaced with URI references.
>
>Dynamic web publishing application (based on Cocoon)
>   o  Cocoon generator for topic maps
>   o  Some XSLT templates for viewing topics
>   o   Additional utility classes for extracting and sorting topic names,
>       occurrences associations etc.
>
>Static/dynamic web publishing application (based on Velocity)
>   o Utility classes for extracting and sorting topic names, occurrences,
>      associations etc.
>   o Configurable framework for using Velocity templates to view topic map
>      objects
>    o Wrapper application to allow deployment in a servlet container
>    o Wrapper application to allow invocation of the processing from the 
> command line
>
>Support Canonical XTM output
>   This could form the basis for conformance testing.
>   See http://www.ontopia.net/topicmaps/materials/cxtm.html for a description
>   of Canonical XTM format
>
>Support LTM input
>   This is a simple text format for topic maps (without the XML verbosity)
>   See http://www.ontopia.net/download/ltm.html for a description of LTM.
>
>Please note, this is not a closed list ! If you have other suggestions, 
>feel free to add them. And just because something is not initially 
>suggested or not voted in for release 0.7.0 does not necessarily mean that 
>it cannot be included in that release - as long as some one is willing to 
>take on the work.
>
>I look forward to hearing your thoughts!
>
>Cheers,
>
>Kal
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers

[Tm4j-developers] TM4J 0.7.0 Features (Long)

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

Hi,

Now that 0.6.0 has been released, I am starting work on collecting the 
features list for 0.7.0. Below is a list of some of the features I have in 
mind. I would like to hear from anyone that has suggestions for additional 
features. I would like to make the release cycle for 0.7.0 much shorter 
than we had for 0.6.0, but that does mean that , without a lot of help, not 
all of these features will make it in to the release. What I am proposing 
to do is to collect together a list of the features proposed and create a 
survey on SourceForge which we can all vote in and then try and partition 
the voted on list into 0.7.0 and post-0.7.0 features.

Here are the features I have so far:

Locator resolution interfaces [REQUIRED]
   The current Locator interface provides no way to retrieve the data at 
the end of the locator.
   This is *required* in order to be able to properly support the mergeMap 
feature (see below).
   This would probably take the form of a separate LocatorResolver 
interface which would return
   a data stream for a given Locator. The architecture for this would be 
flexible and support
   plug-in extensibility for different locator notations. This feature 
would include the following
   sub-features:
   o  Pluggable URI resolution implementation
   o    http: URI resolution
   o    file: URI resolution
   o  Catalog-based locator resolution implementation

ID round-tripping [REQUIRED]
   Support the direct mapping of -id- attribute values in the input XTM 
file into the value of the
   ID property of the Java objects created by the XTMBuilder. This would 
enable complete
   round-tripping of -id- attribute values in most trivial cases. When 
loading multiple XTM files
   into a single TopicMap object, some additional attribute processing may 
be required to
   prevent DuplicateObjectIDExceptions getting thrown (alternatively, this 
could just happen...)

Merge-map support [REQUIRED]
   This is the last major piece of XTM support required for TM4J.

External topic reference processing [REQUIRED]
   This is the *other* last major piece of XTM support required for TM4J ;-)

More flexible indexing architecture
   Split the indexes away from the TopicMap object - this would make it 
easier to interface
   with persistent storage systems which provide an alternative means of 
query (e.g. Ozone
   or an RDBMS). It would also significantly simplify the TopicMap 
implementations.
   Elements of this feature include:
     o  Basic index interface
     o  In-memory Index implementations
     o  Ozone Index implementations

Rework DOM implementation to work on XML-DB (http://www.xmldb.org/index.html)
   XML-DB is a standard API for XML repositories, which is based on DOM and
   XPath. The work already started on the DOM implementation should be pretty
   straightforward to port to XML-DB. The original intention of building a 
TM4J interface
   on an in-memory DOM structure does not need to be abandoned - the two
   could probably be supported by a single interface.

JDBC/RDBMS implementation
   Apparently some people still like relational systems...

New TMNav architecture
   This would include:
   o  TMNav browser implementation
   o  Touchgraph visualisation
   o  TMNav editor implementation

Improve consistency of use of Log4J
   o  Ensure only Log4J is used for logging warnings/errors
   o  Ensure command line apps and other apps initialise Log4J correctly
   o  Create default Log4J initialisation object

Support for ISO Topic Map Syntax
   o  Support at least import of topic maps in ISO syntax (with the
       HyTime links replaced with URI references.

Dynamic web publishing application (based on Cocoon)
   o  Cocoon generator for topic maps
   o  Some XSLT templates for viewing topics
   o   Additional utility classes for extracting and sorting topic names,
       occurrences associations etc.

Static/dynamic web publishing application (based on Velocity)
   o Utility classes for extracting and sorting topic names, occurrences,
      associations etc.
   o Configurable framework for using Velocity templates to view topic map
      objects
    o Wrapper application to allow deployment in a servlet container
    o Wrapper application to allow invocation of the processing from the 
command line

Support Canonical XTM output
   This could form the basis for conformance testing.
   See http://www.ontopia.net/topicmaps/materials/cxtm.html for a description
   of Canonical XTM format

Support LTM input
   This is a simple text format for topic maps (without the XML verbosity)
   See http://www.ontopia.net/download/ltm.html for a description of LTM.

Please note, this is not a closed list ! If you have other suggestions, 
feel free to add them. And just because something is not initially 
suggested or not voted in for release 0.7.0 does not necessarily mean that 
it cannot be included in that release - as long as some one is willing to 
take on the work.

I look forward to hearing your thoughts!

Cheers,

Kal

Re: [Tm4j-developers] Docbook Stylesheets

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

I think putting revised style sheets in CVS makes sense. +1 for that.

Jack
At 06:59 PM 2/9/2002 +0000, Kal Ahmed wrote:
>Hi Folks,
>
>Currently the CVS tree contains the Docbook DTD, but *not* the 
>stylesheets. I feel that uploading and then maintaining this in CVS would 
>be too much of an administrative overhead and that it would be easier to 
>simply point people who want to build the documentation for themselves to 
>the appropriate page to download the stylesheets. However, there is also 
>an argument for making it possible to build everything with a clean 
>checkout from CVS (which is currently not possible if the stylesheets are 
>missing). I also found that I needed to fix a (very minor) bug with one of 
>the XSL files to get it to work with SAXON - so that is possibly another 
>good reason for maintaining our own set of "approved" stylesheets in CVS.
>
>What do we want to do:
>
>1) Add the stylesheets to CVS
>2) Keep things as they are but add some documentation (to a README ?) 
>telling people where to get the Docbook stylesheets.
>
>I'd like to hear your opinions...
>
>Cheers,
>
>Kal
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers

[Tm4j-developers] Docbook Stylesheets

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

Hi Folks,

Currently the CVS tree contains the Docbook DTD, but *not* the stylesheets. 
I feel that uploading and then maintaining this in CVS would be too much of 
an administrative overhead and that it would be easier to simply point 
people who want to build the documentation for themselves to the 
appropriate page to download the stylesheets. However, there is also an 
argument for making it possible to build everything with a clean checkout 
from CVS (which is currently not possible if the stylesheets are missing). 
I also found that I needed to fix a (very minor) bug with one of the XSL 
files to get it to work with SAXON - so that is possibly another good 
reason for maintaining our own set of "approved" stylesheets in CVS.

What do we want to do:

1) Add the stylesheets to CVS
2) Keep things as they are but add some documentation (to a README ?) 
telling people where to get the Docbook stylesheets.

I'd like to hear your opinions...

Cheers,

Kal 

[Tm4j-developers] Updating Xerces

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

Hi all,

I have just (locally) updated my TM4J build to use the new Xerces 2.0.0 
parser. I found (and fixed) a minor bug in the Xerces XMLSerializer, but 
other than that it seems OK - all of our test suite passes with the fixed 
version of the Xerces JAR file. However, before I commit the changes to the 
lib directory, could anyone let me know if there are any delicate 
dependencies that I should check out first ?

Cheers,

Kal

PS - If I don't hear anything about this by this evening, I will assume all 
is OK and commit my changes - we can always back them out later...