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

[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

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)

[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