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

RE: [Tm4j-developers] Index interface proposal checked in

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

Kal,

here are a few comments.

1. The fact that the methods returning an IndexMeta object are called
getIndexMeta() in IndexProvider and getIndexMetaData() in IndexManager seems
like an inconsistency to me.

2. Perhaps IndexManager.hasIndex(String) should be renamed to
isRegistered(String) or isRegisteredIndex(String). In addition, I think that
since already have IndexMeta.isAutomaticallyUpdated(), we should also have
an isAutomaticallyOpened() replacing requiresOpen() (with return values
reversed, of course).

3. I think that IndexProvider.getIndexNames() should be renamed to
getIndexClassNames(), or perhaps be amended/replaced by a getIndexClasses()
method returning a Class[] array. A boolean isSupportedIndex(Class
indexClass) method may also be helpful. Or one might go the whole nine yards
and overload close(), getIndex(), getIndexMeta() and open() in such a way
that they also accept an argument of type Class, representing the index
class. The same could be done to the methods in IndexManager.

4. Index.reindex() documents that it throws UnsupportedOperationException
which does not exist.

5. IndexProvider.getIndex() and IndexProvider.close() both document two
exceptions which they do not throw.

6. IndexManager.getIndex() documents one exception which it does not throw.

Hope I'm making sense,
-- Florian


| -----Original Message-----
| From: tm4...@li...
| [mailto:tm4...@li...]On Behalf Of Kal
| Ahmed
| Sent: Donnerstag, 28. Februar 2002 19:18
| To: tm4...@li...
| Subject: RE: [Tm4j-developers] Index interface proposal checked in
|
|
| I have just checked in a cleaned up version of the index interfaces for a
| quick peer review before I start coding some implementations of
| this stuff.
|
| All comments welcome.
|
| Cheers,
|
| Kal

RE: [Tm4j-developers] Index interface proposal checked in

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

I have just checked in a cleaned up version of the index interfaces for a 
quick peer review before I start coding some implementations of this stuff.

All comments welcome.

Cheers,

Kal

At 11:07 27/02/2002 +0000, Kal Ahmed wrote:

>Oops - forgot to cc the list on this one.
>
>>Date: Wed, 27 Feb 2002 09:28:10 +0000
>>To: "Florian G. Haas" <f.g...@gm...>
>>From: Kal Ahmed <ka...@te...>
>>Subject: RE: [Tm4j-developers] Index interface proposal checked in
>>
>>At 00:25 27/02/2002 +0100, you wrote:
>>>Hello!
>>>
>>>I must admit I'm certainly no expert at this, but what you are saying about
>>>the general purpose of these indexing mechanisms makes sense to me. Having
>>>had a look at the interface definitions themselves, I have a couple of
>>>questions:
>>>
>>>* What's the difference between an "open" and an "initialized" index? In
>>>other words, how would IndexProvider.getIndex().isOpen() be different from
>>>IndexProvider.getIndexMeta().isInitialised()? And how would that, in turn,
>>>differ from IndexManager.getIndexMetaData().isInitialised()?
>>
>>I think that is an inconsistency that needs to be removed. The close() 
>>method was actually added after I had sketched out the design, so I think 
>>that changing "initialise" to "open" in most places would make sense.
>>
>>The difference between IndexProvider and IndexManager is that a 
>>IndexProvider is essentially an SPI (service provider interface) that 
>>needs to be implemented by developers wishing to add their own indexes to 
>>a TM4J application. IndexManager is an API for developers wishing to use 
>>indexes through TM4J. So there should be no way for a "user" of the 
>>IndexManager interface to ever get hold of a handle to the IndexProvider 
>>- hence the extra layers.
>>
>>I think that the IndexMeta.isInitialised should probably be removed - 
>>that is more state information than meta information about the index. I 
>>think that the state information should be accessible through the Index 
>>object itself.
>>
>>I'll update the interfaces accordingly.
>>
>>>* What would be an "explicit runtime initialisation" as mentioned in the
>>>documentation for IndexManager?
>>
>>My thought was that some of these indexes might be quite heavy in terms 
>>of local resources used and so you wouldn't necessarily want them open as 
>>soon as the IndexProvider is loaded (seeing as an IndexProvider might be 
>>providing a set of indexes). So I originally intended explicit runtime 
>>initilisation to be the act of calling IndexProvider.getIndex(), but I 
>>think in retrospect that adding Index.open() would make sense and would 
>>put the explicit initialisation in the right place.
>>
>>Cheers,
>>
>>Kal
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>

Re: [Tm4j-developers] Graph presentation

[Murray A. <m.a...@op...>]

Kal Ahmed wrote:
[...]
>> I have a preliminary XTM-to-TouchGraph converter working, though it is
>> missing a good deal of the topic map (such as occurrences and any sort
>> of interactive features). As a display tool for topics, associations,
>> and *some* of the scopes it works passably. But for now I won't be
>> spending so much time on it as my Ph.D duties are calling louder. But
>> perhaps working together on a Java API for XTM-in-TG I'd be happy to
>> lend a hand
> 
> That sounds cool. I think that there are two independent things which we 
> could collaborate on here - one is a common visualisation for XTM in TG 
> (e.g. what should be displayed as TG nodes and what should be TG arcs, 
> conventions on the use of colour, shapes and labels) such that two 
> different apps displaying XTM in TG could do so in a consistent manner. 
> The second would be a generic topic map viewer using TG (possibly built 
> on top of TMAPI). The third thing might be if I can just pick your 
> brains if I get stuck on the TG coding... ;-)

Gad, I hope you don't have to pick my brains. I was thinking it'd be
the other way around. Sometime this spring I hope to be able to release
my Ceryle application, which should provide a framework upon which some
of this can be built. It has a working implementation of Xindice plus
XNode (the API I wrote for putting metadata-laden XML into Xindice that
will hopefully make it into the Apache submission), plus a working
of TG that will (hopefully) have some sort of import and export to and
from GXL and XTM, though currently I'm not at all happy with it.

[...]
>> I instead decided to look at how GXL could be used for this purpose,
>> and that's when the light bulb went off -- it was an obvious choice for
>> a common syntax. I've also written a TG-to-GXL converter in the process,
>> then realized I wanted a more generalized approach.
>
> An XML graph vocabulary is the obvious lowest-common-denominator 
> representation for TMs, CGs, RDF et al. I haven't (yet) looked deeply 
> into GXL - I have skimmed over some of the pages from Jacks's reference. 
> My feeling is that GXL as a vocabulary is interesting though as you 
> point out somewhat limiting for use by humans because of its verbosity. 
> In using it as a lingua-franca for different represntational forms, you 
> will undoubtedly run into semantic problems. However, having said all 
> that, the nice simple graph model that GXL encodes would be an 
> interesting basis for a "node engine" that handles multiple higher-level 
> representations of which TM4J could be one.

I don't think GXL will be any more limiting than RDF, in fact I like it
a lot better than RDF as a syntax because it doesn't mix the lexical
with the grammar, no XML namespaces, etc. I think Jack, you and I are
thinking pretty alike on this. I'm just watching as the GXL researchers
develop a suitable schema language -- there's been a post recently in
this regard on their mailing list, but I've not had time to investigate
further.

Cheers,

Murray

Re: [Tm4j-developers] Graph presentation

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

At 10:20 28/02/2002 +0000, Murray Altheim wrote:
>Kal Ahmed wrote:
>
>>At 09:22 27/02/2002 -0800, Jack Park wrote:
>>
>>>It may be that this group is familiar with 
>>>http://touchgraph.sourceforge.net. (Apache)
>>I have had a brief discussion with Alex Shapiro (developer of Touchgraph) 
>>about using it as a visualisation for a topic map in TM4J. Since that 
>>discussion I kind of got bogged down in 0.6.0 release stuff. But now that 
>>the TMNav application is back on the cards I will resume experimenting with it.
>
>
>I have a preliminary XTM-to-TouchGraph converter working, though it is
>missing a good deal of the topic map (such as occurrences and any sort
>of interactive features). As a display tool for topics, associations,
>and *some* of the scopes it works passably. But for now I won't be
>spending so much time on it as my Ph.D duties are calling louder. But
>perhaps working together on a Java API for XTM-in-TG I'd be happy to
>lend a hand.

That sounds cool. I think that there are two independent things which we 
could collaborate on here - one is a common visualisation for XTM in TG 
(e.g. what should be displayed as TG nodes and what should be TG arcs, 
conventions on the use of colour, shapes and labels) such that two 
different apps displaying XTM in TG could do so in a consistent manner. The 
second would be a generic topic map viewer using TG (possibly built on top 
of TMAPI). The third thing might be if I can just pick your brains if I get 
stuck on the TG coding... ;-)


>>>Another one I just discovered (though others may be familiar with it) is 
>>>http://jgraph.sourceforge.net (LGPL)
>>
>>>An interesting point about jGraph is that it exports to GXL (Graph 
>>>Exchange Language) http://www.gupro.de/GXL/
>>I hadn't realised that...interesting!
>>
>>>Which brings to mind an interesting set of issues.
>>>
>>>For instance: the world seems to be awash in ontology expression 
>>>languages, like DAML+OIL, OWL (just getting started), CG, RDF, XTM, and 
>>>so forth (assuming you'll allow me to group XTM into that cluster).
>>>
>>>One wonders if the persistence layer of any knowledge product ought not 
>>>to consist of something a bit more "universal" (whatever that means) 
>>>than XTM.  GXL comes to mind, and Murray Altheim seems to be heading in 
>>>that direction. It may be that the GooseWorks package is going in that 
>>>direction as well, but I'm not sure yet.
>>>
>>>This would imply that the next generation of TM4J could be a 
>>>wrapper/mapper for a GXL backside.  From the same backside, we could 
>>>wrap/map to Conceptual Graphs, DAML+OIL, OWL, and who knows what else.
>>That sounds like an interesting approach - in a way it is somewhat 
>>similar to what the DOM backend is intending to do - take some standard 
>>representation form with a standard API (in this case XTM in the DOM) and 
>>add the necessary processing layer to expose that as a topic map with 
>>TM4J APIs to it. I have toyed with the idea of a generic node-arc 
>>back-end for TM4J, but have decided recently to focus more on building up 
>>the front-end (with client apps, web-app frameworks, higher-level 
>>utilities, query languages and so on).
>
>
>I had a minor competition with Peter Becker last fall in developing an
>XML serialization of CGs, but have somewhat abandoned that after John
>Sowa took all of the development efforts back into the ANSI committee.

That is a shame - it would be good to have some XML vocabulary for a well 
researched formalism such as CG.

>I instead decided to look at how GXL could be used for this purpose,
>and that's when the light bulb went off -- it was an obvious choice for
>a common syntax. I've also written a TG-to-GXL converter in the process,
>then realized I wanted a more generalized approach.

An XML graph vocabulary is the obvious lowest-common-denominator 
representation for TMs, CGs, RDF et al. I haven't (yet) looked deeply into 
GXL - I have skimmed over some of the pages from Jacks's reference. My 
feeling is that GXL as a vocabulary is interesting though as you point out 
somewhat limiting for use by humans because of its verbosity. In using it 
as a lingua-franca for different represntational forms, you will 
undoubtedly run into semantic problems. However, having said all that, the 
nice simple graph model that GXL encodes would be an interesting basis for 
a "node engine" that handles multiple higher-level representations of which 
TM4J could be one.


>>>Your thoughts on the notion of going in the direction of a universal, 
>>>graph-theoretic backside with wrapper/mappers?
>>I think that there shouldn't be anything in the current TM4J back-end 
>>architecture that should prevent this from happening and I also think 
>>that it could be a very interesting thing to do. If it turns out that 
>>something in the way TM4J's backend architecture works prevents this from 
>>being possible then we should change that. To be honest, right now my 
>>focus is not on creating new backends, but I would certainly support 
>>anyone who wants to give it a go!
>
>
>A little healthy competition is a good thing I think, especially
>among friends. I'm hoping over the next few months to hitch up my
>TG toolkit to my Xindice DB so that Very Large Graphs (>100K nodes)
>can be displayed via locality (ie., n nodes from a selected node).

V. Cool !

>I once for an experiment tried opening one of my ITIS topic maps
>and it took my machine down. Well, not completely, but you get the
>picture.

I do - I tried to create a VLTM from the RPMFind RDF dump and had a similar 
experience with TM4J :-( at some point I need to free up enough disk space 
to regenerate the TM and retest with the Ozone backend.

Cheers,

Kal

Re: [Tm4j-developers] Graph presentation

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

This is probably drifting off topic, but as no one is complaining yet, my 
comments are below:

At 07:21 28/02/2002 -0800, Jack Park wrote:
>Comments below...
>Cheers,
>Jack
>At 09:00 AM 2/28/2002 +0000, Kal Ahmed wrote:
>>At 09:22 27/02/2002 -0800, Jack Park wrote:
>>>It may be that this group is familiar with 
>>>http://touchgraph.sourceforge.net. (Apache)
>>
>>I have had a brief discussion with Alex Shapiro (developer of Touchgraph) 
>>about using it as a visualisation for a topic map in TM4J. Since that 
>>discussion I kind of got bogged down in 0.6.0 release stuff. But now that 
>>the TMNav application is back on the cards I will resume experimenting with it.
>>
>>>Another one I just discovered (though others may be familiar with it) is 
>>>http://jgraph.sourceforge.net (LGPL)
>>
>>>An interesting point about jGraph is that it exports to GXL (Graph 
>>>Exchange Language) http://www.gupro.de/GXL/
>>
>>I hadn't realised that...interesting!
>>
>>>Which brings to mind an interesting set of issues.
>>>
>>>For instance: the world seems to be awash in ontology expression 
>>>languages, like DAML+OIL, OWL (just getting started), CG, RDF, XTM, and 
>>>so forth (assuming you'll allow me to group XTM into that cluster).
>>>
>>>One wonders if the persistence layer of any knowledge product ought not 
>>>to consist of something a bit more "universal" (whatever that means) 
>>>than XTM.  GXL comes to mind, and Murray Altheim seems to be heading in 
>>>that direction. It may be that the GooseWorks package is going in that 
>>>direction as well, but I'm not sure yet.
>>>
>>>This would imply that the next generation of TM4J could be a 
>>>wrapper/mapper for a GXL backside.  From the same backside, we could 
>>>wrap/map to Conceptual Graphs, DAML+OIL, OWL, and who knows what else.
>>
>>That sounds like an interesting approach - in a way it is somewhat 
>>similar to what the DOM backend is intending to do - take some standard 
>>representation form with a standard API (in this case XTM in the DOM) and 
>>add the necessary processing layer to expose that as a topic map with 
>>TM4J APIs to it. I have toyed with the idea of a generic node-arc 
>>back-end for TM4J, but have decided recently to focus more on building up 
>>the front-end (with client apps, web-app frameworks, higher-level 
>>utilities, query languages and so on).
>
>Very smart!  Very important thing to be doing.
>
>
>>>Your thoughts on the notion of going in the direction of a universal, 
>>>graph-theoretic backside with wrapper/mappers?
>>
>>I think that there shouldn't be anything in the current TM4J back-end 
>>architecture that should prevent this from happening and I also think 
>>that it could be a very interesting thing to do. If it turns out that 
>>something in the way TM4J's backend architecture works prevents this from 
>>being possible then we should change that. To be honest, right now my 
>>focus is not on creating new backends, but I would certainly support 
>>anyone who wants to give it a go!
>
>What's really interesting about this offer is that the other forum you are 
>running, Tmapi-discuss, is that what is suggested would be a forum called, 
>say, graphapi-discuss, in which the api for a generic graph backend is 
>constructed.  What falls out of that are front sides for xtm, daml/oil, 
>owl, cg, and who knows what else.  My thinking has been going along the 
>lines of a generic nodes and arcs layout.  Then, the Xindice and Ozone 
>designs resolve to two simple classes (I think), and the rdbms schema is 
>two tables.  Doing the mapping, however, does not seem trivial.

Looking at the GXL DTD, I would venture as far as to say that a graph API 
need do no more than realize the data model of GXL. Adding the relation 
(<rel> in GXL or hyperedge in graph-land) could probably be used to enable 
an easier mapping of a more complex structure such as a constrained topic 
map (i.e a topic map with attendant schema) into the hypergraph structure. 
I think that a naive version of a GXL-based API would be relatively trivial 
to implement. There is already an implementation of a more complete graph 
database - GRAS 
(http://www-i3.informatik.rwth-aachen.de/research/projects/gras/index.html) 
- but this appears to be done in C, and so would either require 
reimplementing or wrapping with JNI.


>If that becomes a reality, then it makes sense to me to map Nexist over to 
>TM4J sooner rather than later.

I would see the architecture with a graph database as being something like 
this (fixed pitch font required for the next bit)

+------+---------+
| TM4J | RDF API |
+------+---------+
|   GRAPH API    |
+-------+--------+
| RDBMS | OODBMS |
+-------+--------+

I'm not sure where Nexist would necessarily fit in to this, would it be 
above the high-level bindings (TM4J, RDF API, CG API etc) or next to them ?

Cheers,

Kal

Re: [Tm4j-developers] Graph presentation

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

Comments below...
Cheers,
Jack
At 09:00 AM 2/28/2002 +0000, Kal Ahmed wrote:
>At 09:22 27/02/2002 -0800, Jack Park wrote:
>>It may be that this group is familiar with 
>>http://touchgraph.sourceforge.net. (Apache)
>
>I have had a brief discussion with Alex Shapiro (developer of Touchgraph) 
>about using it as a visualisation for a topic map in TM4J. Since that 
>discussion I kind of got bogged down in 0.6.0 release stuff. But now that 
>the TMNav application is back on the cards I will resume experimenting with it.
>
>>Another one I just discovered (though others may be familiar with it) is 
>>http://jgraph.sourceforge.net (LGPL)
>
>>An interesting point about jGraph is that it exports to GXL (Graph 
>>Exchange Language) http://www.gupro.de/GXL/
>
>I hadn't realised that...interesting!
>
>>Which brings to mind an interesting set of issues.
>>
>>For instance: the world seems to be awash in ontology expression 
>>languages, like DAML+OIL, OWL (just getting started), CG, RDF, XTM, and 
>>so forth (assuming you'll allow me to group XTM into that cluster).
>>
>>One wonders if the persistence layer of any knowledge product ought not 
>>to consist of something a bit more "universal" (whatever that means) than 
>>XTM.  GXL comes to mind, and Murray Altheim seems to be heading in that 
>>direction. It may be that the GooseWorks package is going in that 
>>direction as well, but I'm not sure yet.
>>
>>This would imply that the next generation of TM4J could be a 
>>wrapper/mapper for a GXL backside.  From the same backside, we could 
>>wrap/map to Conceptual Graphs, DAML+OIL, OWL, and who knows what else.
>
>That sounds like an interesting approach - in a way it is somewhat similar 
>to what the DOM backend is intending to do - take some standard 
>representation form with a standard API (in this case XTM in the DOM) and 
>add the necessary processing layer to expose that as a topic map with TM4J 
>APIs to it. I have toyed with the idea of a generic node-arc back-end for 
>TM4J, but have decided recently to focus more on building up the front-end 
>(with client apps, web-app frameworks, higher-level utilities, query 
>languages and so on).

Very smart!  Very important thing to be doing.


>>Your thoughts on the notion of going in the direction of a universal, 
>>graph-theoretic backside with wrapper/mappers?
>
>I think that there shouldn't be anything in the current TM4J back-end 
>architecture that should prevent this from happening and I also think that 
>it could be a very interesting thing to do. If it turns out that something 
>in the way TM4J's backend architecture works prevents this from being 
>possible then we should change that. To be honest, right now my focus is 
>not on creating new backends, but I would certainly support anyone who 
>wants to give it a go!

What's really interesting about this offer is that the other forum you are 
running, Tmapi-discuss, is that what is suggested would be a forum called, 
say, graphapi-discuss, in which the api for a generic graph backend is 
constructed.  What falls out of that are front sides for xtm, daml/oil, 
owl, cg, and who knows what else.  My thinking has been going along the 
lines of a generic nodes and arcs layout.  Then, the Xindice and Ozone 
designs resolve to two simple classes (I think), and the rdbms schema is 
two tables.  Doing the mapping, however, does not seem trivial.

If that becomes a reality, then it makes sense to me to map Nexist over to 
TM4J sooner rather than later.

>Cheers,
>
>Kal

Re: [Tm4j-developers] Graph presentation

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

It seems worth noting that jgraph uses a "spring" arranger, probably the 
same one that Alex started with.  At the same time, jgraph comes with an 
export to svg -- something we should have no matter which way we go.  Mind 
you, I'm not selling jgraph over touchgraph.  Just pointing out some 
differences.

Jack

At 10:20 AM 2/28/2002 +0000, Murray Altheim wrote:
>Kal Ahmed wrote:
>
>>At 09:22 27/02/2002 -0800, Jack Park wrote:
>>
>>>It may be that this group is familiar with 
>>>http://touchgraph.sourceforge.net. (Apache)
>>I have had a brief discussion with Alex Shapiro (developer of Touchgraph) 
>>about using it as a visualisation for a topic map in TM4J. Since that 
>>discussion I kind of got bogged down in 0.6.0 release stuff. But now that 
>>the TMNav application is back on the cards I will resume experimenting with it.
>
>
>I have a preliminary XTM-to-TouchGraph converter working, though it is
>missing a good deal of the topic map (such as occurrences and any sort
>of interactive features). As a display tool for topics, associations,
>and *some* of the scopes it works passably. But for now I won't be
>spending so much time on it as my Ph.D duties are calling louder. But
>perhaps working together on a Java API for XTM-in-TG I'd be happy to
>lend a hand.
>
>
>>>Another one I just discovered (though others may be familiar with it) is 
>>>http://jgraph.sourceforge.net (LGPL)
>>
>>>An interesting point about jGraph is that it exports to GXL (Graph 
>>>Exchange Language) http://www.gupro.de/GXL/
>>I hadn't realised that...interesting!
>>
>>>Which brings to mind an interesting set of issues.
>>>
>>>For instance: the world seems to be awash in ontology expression 
>>>languages, like DAML+OIL, OWL (just getting started), CG, RDF, XTM, and 
>>>so forth (assuming you'll allow me to group XTM into that cluster).
>>>
>>>One wonders if the persistence layer of any knowledge product ought not 
>>>to consist of something a bit more "universal" (whatever that means) 
>>>than XTM.  GXL comes to mind, and Murray Altheim seems to be heading in 
>>>that direction. It may be that the GooseWorks package is going in that 
>>>direction as well, but I'm not sure yet.
>>>
>>>This would imply that the next generation of TM4J could be a 
>>>wrapper/mapper for a GXL backside.  From the same backside, we could 
>>>wrap/map to Conceptual Graphs, DAML+OIL, OWL, and who knows what else.
>>That sounds like an interesting approach - in a way it is somewhat 
>>similar to what the DOM backend is intending to do - take some standard 
>>representation form with a standard API (in this case XTM in the DOM) and 
>>add the necessary processing layer to expose that as a topic map with 
>>TM4J APIs to it. I have toyed with the idea of a generic node-arc 
>>back-end for TM4J, but have decided recently to focus more on building up 
>>the front-end (with client apps, web-app frameworks, higher-level 
>>utilities, query languages and so on).
>
>
>I had a minor competition with Peter Becker last fall in developing an
>XML serialization of CGs, but have somewhat abandoned that after John
>Sowa took all of the development efforts back into the ANSI committee.
>I instead decided to look at how GXL could be used for this purpose,
>and that's when the light bulb went off -- it was an obvious choice for
>a common syntax. I've also written a TG-to-GXL converter in the process,
>then realized I wanted a more generalized approach.
>
>
>>>Your thoughts on the notion of going in the direction of a universal, 
>>>graph-theoretic backside with wrapper/mappers?
>>I think that there shouldn't be anything in the current TM4J back-end 
>>architecture that should prevent this from happening and I also think 
>>that it could be a very interesting thing to do. If it turns out that 
>>something in the way TM4J's backend architecture works prevents this from 
>>being possible then we should change that. To be honest, right now my 
>>focus is not on creating new backends, but I would certainly support 
>>anyone who wants to give it a go!
>
>
>A little healthy competition is a good thing I think, especially
>among friends. I'm hoping over the next few months to hitch up my
>TG toolkit to my Xindice DB so that Very Large Graphs (>100K nodes)
>can be displayed via locality (ie., n nodes from a selected node).
>I once for an experiment tried opening one of my ITIS topic maps
>and it took my machine down. Well, not completely, but you get the
>picture.
>
>Murray
>
>......................................................................
>Murray Altheim                         <mailto:m.altheim @ open.ac.uk>
>Knowledge Media Institute
>The Open University, Milton Keynes, Bucks, MK7 6AA, UK
>
>      In the evening
>      The rice leaves in the garden
>      Rustle in the autumn wind
>      That blows through my reed hut.  -- Minamoto no Tsunenobu

Re: [Tm4j-developers] Graph presentation

[Murray A. <m.a...@op...>]

Kal Ahmed wrote:

> At 09:22 27/02/2002 -0800, Jack Park wrote:
> 
>> It may be that this group is familiar with 
>> http://touchgraph.sourceforge.net. (Apache)
> 
> I have had a brief discussion with Alex Shapiro (developer of 
> Touchgraph) about using it as a visualisation for a topic map in TM4J. 
> Since that discussion I kind of got bogged down in 0.6.0 release stuff. 
> But now that the TMNav application is back on the cards I will resume 
> experimenting with it.


I have a preliminary XTM-to-TouchGraph converter working, though it is
missing a good deal of the topic map (such as occurrences and any sort
of interactive features). As a display tool for topics, associations,
and *some* of the scopes it works passably. But for now I won't be
spending so much time on it as my Ph.D duties are calling louder. But
perhaps working together on a Java API for XTM-in-TG I'd be happy to
lend a hand.


>> Another one I just discovered (though others may be familiar with it) 
>> is http://jgraph.sourceforge.net (LGPL)
> 
>> An interesting point about jGraph is that it exports to GXL (Graph 
>> Exchange Language) http://www.gupro.de/GXL/
> 
> I hadn't realised that...interesting!
> 
>> Which brings to mind an interesting set of issues.
>>
>> For instance: the world seems to be awash in ontology expression 
>> languages, like DAML+OIL, OWL (just getting started), CG, RDF, XTM, 
>> and so forth (assuming you'll allow me to group XTM into that cluster).
>>
>> One wonders if the persistence layer of any knowledge product ought 
>> not to consist of something a bit more "universal" (whatever that 
>> means) than XTM.  GXL comes to mind, and Murray Altheim seems to be 
>> heading in that direction. It may be that the GooseWorks package is 
>> going in that direction as well, but I'm not sure yet.
>>
>> This would imply that the next generation of TM4J could be a 
>> wrapper/mapper for a GXL backside.  From the same backside, we could 
>> wrap/map to Conceptual Graphs, DAML+OIL, OWL, and who knows what else.
> 
> That sounds like an interesting approach - in a way it is somewhat 
> similar to what the DOM backend is intending to do - take some standard 
> representation form with a standard API (in this case XTM in the DOM) 
> and add the necessary processing layer to expose that as a topic map 
> with TM4J APIs to it. I have toyed with the idea of a generic node-arc 
> back-end for TM4J, but have decided recently to focus more on building 
> up the front-end (with client apps, web-app frameworks, higher-level 
> utilities, query languages and so on).


I had a minor competition with Peter Becker last fall in developing an
XML serialization of CGs, but have somewhat abandoned that after John
Sowa took all of the development efforts back into the ANSI committee.
I instead decided to look at how GXL could be used for this purpose,
and that's when the light bulb went off -- it was an obvious choice for
a common syntax. I've also written a TG-to-GXL converter in the process,
then realized I wanted a more generalized approach.

 
>> Your thoughts on the notion of going in the direction of a universal, 
>> graph-theoretic backside with wrapper/mappers?
> 
> I think that there shouldn't be anything in the current TM4J back-end 
> architecture that should prevent this from happening and I also think 
> that it could be a very interesting thing to do. If it turns out that 
> something in the way TM4J's backend architecture works prevents this 
> from being possible then we should change that. To be honest, right now 
> my focus is not on creating new backends, but I would certainly support 
> anyone who wants to give it a go!


A little healthy competition is a good thing I think, especially
among friends. I'm hoping over the next few months to hitch up my
TG toolkit to my Xindice DB so that Very Large Graphs (>100K nodes)
can be displayed via locality (ie., n nodes from a selected node).
I once for an experiment tried opening one of my ITIS topic maps
and it took my machine down. Well, not completely, but you get the
picture.

Murray

......................................................................
Murray Altheim                         <mailto:m.altheim @ open.ac.uk>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

[Tm4j-developers] Re: Graph presentation

[Murray A. <m.a...@op...>]

Sam Hunting wrote:

>>One wonders if the persistence layer of any knowledge product ought
>>not to  consist of something a bit more "universal" (whatever that 
>>means) than XTM.  GXL comes to mind, and Murray Altheim seems to be
>>heading in that direction.
> 
> Elaine Svenonius says that "objectives determine ontology" (and not the
> other way round). So I am not clear on what the objectives are here. I
> can see "universal" meaning "closer to the data struture" (more
> nodes-and-arcs-ish) or "closer to the knowledge interchanged" (more
> subject-and-association-ish).


The objectives seem very similar to what Steve and Michel provided
with TMPM4, ie., a graph representation of a topic map. When they
provided that graph DTD it set me off looking for a graph DTD designed
more generically, and GXL seems to fit that bill so far as I can see.
Once a TM is in memory it seems more natural to serialize it to something
that others can read. The community of worker bees around GXL are moving
toward having a schema language ready, one expressed not in some other
language (such as DTDs or RDF schema, the latter using a different
namespace and grammar) but in GXL itself.


>>It may be that the GooseWorks package is
>>going in that direction as well, but I'm not sure yet.
>>
> 
> We are focusing more on making the topic map paradigm "omnivorous with
> respect to markup." We want to eat everything... So far, we only
> excrete XTM, though that could change depending on what people's needs
> are, or what people volunteer to do.


Well, my project so far reads XTM, Cyc (to some extent), ITIS, and LTM.
Same approach as you I believe...

 
>>Your thoughts on the notion of going in the direction of a universal,
>>graph-theoretic backside with wrapper/mappers?
>>
> 
> That is very close to the direction GW is headed in -- whatever
> "universal" might mean. (I don't think there is anything universal, at
> least that we can have knowledge of. There are only agreements and
> agreements to agree....) 
> 
> It's also very close to the ISO submission of the "road map." 


I think keeping the lexical/grammatical layer somewhat generic is
a good thing. This doesn't mean that specific syntaxes aren't a
good way of expressing complex structures, as for example a GXL
representation of a topic map would have the same liabilities as
Steve and Michel's graph DTD (verbosity, difficulty to read and
edit, etc.) but all the advantages and more.

Murray

......................................................................
Murray Altheim                         <mailto:m.altheim @ open.ac.uk>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

Re: [Tm4j-developers] Graph presentation

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

At 09:22 27/02/2002 -0800, Jack Park wrote:
>It may be that this group is familiar with 
>http://touchgraph.sourceforge.net. (Apache)

I have had a brief discussion with Alex Shapiro (developer of Touchgraph) 
about using it as a visualisation for a topic map in TM4J. Since that 
discussion I kind of got bogged down in 0.6.0 release stuff. But now that 
the TMNav application is back on the cards I will resume experimenting with it.

>Another one I just discovered (though others may be familiar with it) is 
>http://jgraph.sourceforge.net (LGPL)

>An interesting point about jGraph is that it exports to GXL (Graph 
>Exchange Language) http://www.gupro.de/GXL/

I hadn't realised that...interesting!

>Which brings to mind an interesting set of issues.
>
>For instance: the world seems to be awash in ontology expression 
>languages, like DAML+OIL, OWL (just getting started), CG, RDF, XTM, and so 
>forth (assuming you'll allow me to group XTM into that cluster).
>
>One wonders if the persistence layer of any knowledge product ought not to 
>consist of something a bit more "universal" (whatever that means) than 
>XTM.  GXL comes to mind, and Murray Altheim seems to be heading in that 
>direction. It may be that the GooseWorks package is going in that 
>direction as well, but I'm not sure yet.
>
>This would imply that the next generation of TM4J could be a 
>wrapper/mapper for a GXL backside.  From the same backside, we could 
>wrap/map to Conceptual Graphs, DAML+OIL, OWL, and who knows what else.

That sounds like an interesting approach - in a way it is somewhat similar 
to what the DOM backend is intending to do - take some standard 
representation form with a standard API (in this case XTM in the DOM) and 
add the necessary processing layer to expose that as a topic map with TM4J 
APIs to it. I have toyed with the idea of a generic node-arc back-end for 
TM4J, but have decided recently to focus more on building up the front-end 
(with client apps, web-app frameworks, higher-level utilities, query 
languages and so on).

>Your thoughts on the notion of going in the direction of a universal, 
>graph-theoretic backside with wrapper/mappers?

I think that there shouldn't be anything in the current TM4J back-end 
architecture that should prevent this from happening and I also think that 
it could be a very interesting thing to do. If it turns out that something 
in the way TM4J's backend architecture works prevents this from being 
possible then we should change that. To be honest, right now my focus is 
not on creating new backends, but I would certainly support anyone who 
wants to give it a go!

Cheers,

Kal

Re: [Tm4j-developers] New TM4J web site design proposal [Long]

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

I think that "web sites as topic maps" is a great idea.  In fact, I've been=
=20
thinking about ways to break the entire XML Topic Maps book into a topic=20
map itself on the web.  These images give me some ideas.  Thanks.

Jack

At 11:55 AM 2/27/2002 +0100, Gerd Mueller wrote:
>On Wed, 27 Feb 2002 00:25:04 +0100
>"Florian G. Haas" <f.g...@gm...> wrote:
>
> > Hello all,
> >
> > as I'm sure most of you are aware, we (Thomas Bauer, to a major extent,=
 and
> > Florian Haas, to a minor one) have put some thought into a possible
> > re-design of the TM4J project web site. We have completed some design=20
> drafts
> > and would greatly appreciate your comments.
> >
> > OK, so we (plus Kal) thought about making the project web site design=
 much
> > more Topic-Map-ish, so we could eventually use it for a Velocity- or
> > Cocoon-centered application. What we have for now are Photoshop dummies
> > (we're working on HTML versions), and please feel free to look at them=
 at
> > http://tm4j.org/tmp/HP_DESIGN_9_WEB.JPG and
> > http://tm4j.org/tmp/HP_DESIGN_9FLORIAN_WEB.JPG (just two versions of the
> > same thing with different "topics"), and let us hear your thoughts.
> > Christoph Fr=F6hlich has already provided some very valuable feedback in=
 an
> > E-Mail to Kal, which we've attached to this message. Christoph, if=
 you're
> > monitoring this list, we hope you don't mind our doing this. Please keep
> > telling us stuff like this, it's really more than helpful.
> >
> > Some other issues that have already come up in informal discussion:
> > * Keep the "newsticker"? Or is it just a confusing attention-catcher?
> > * Keep the "search" box? It would certainly be nice to have a full-text
> > topic map search (or even TMQL, or Tolog), but how would we implement=
 it?
> >
> > Let's hope we get some good discussion going about this! :-)
>
>I like the overall design. It's frugal but very distinctive.
>
>But I agree with Christoph that the 'a topic map
>engine for java' line in the header is to much. Also the shadow of
>'topic maps 4 java' is to heavy. Perhaps you should drop the 'topic maps=20
>for java'
>from the TM4J logo and leave 'topic maps 4 java'.
>
>The navgation bar doesn't stand out enough. So you have to search for at=20
>first.
>I would suggest another background color for it and maybe we should also=20
>move it
>to left side.
>
>Also I think the newsticker isn't necessary if we have the 'news' box.
>
>I would also drop the 'optimized for explorer' hint. The site should work=
 for
>all browsers in the same quality.
>
>Best Regards,
>Gerd
>
>___________________________________________________________________________=
___
>Gerd=20
>Mueller                                                  ge...@sm...
>SMB GmbH                                               =
 http://www.smb-tec.com
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers

Re: [Tm4j-developers] Re: Graph presentation

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

Comments below...
Cheers,
Jack

At 10:14 AM 2/27/2002 -0800, Sam Hunting wrote:
> > One wonders if the persistence layer of any knowledge product ought
> > not to  consist of something a bit more "universal" (whatever that
> > means) than XTM.  GXL comes to mind, and Murray Altheim seems to be
> > heading in that direction.
>
>Elaine Svenonius says that "objectives determine ontology" (and not the
>other way round). So I am not clear on what the objectives are here. I
>can see "universal" meaning "closer to the data struture" (more
>nodes-and-arcs-ish) or "closer to the knowledge interchanged" (more
>subject-and-association-ish).

Yup. When I said "whatever that means" I had in mind the idea that the 
persistence layer would simply store nodes and arcs and their attending 
attributes, and so forth, and that layer can be mapped out by 
mappers.  Originally, I was thinking that the class files (ala those 
involved in Ozone and (I presume) Xindice) would then be GXL classes, with 
mappers starting with that.  If I were to go with a RDBMS, as I presently 
do in Nexist, I can have class files that map directly from tables to 
whatever I want -- Nexist presently maps to XTM.

The reason for this thinking is that, presently, Nexist RDBMS schema makes 
pretty concrete the idea of topics, associations, and so forth.  Nexist 
anticipates layering XTM documents on top of DAML/OIL ontologies, so the 
persistence layer needs to model that as well.  It became clear to me, 
following Murray's comments, that a revised strategy aimed at generalizing 
the persistence layer to satisfy a broader range of use cases is in 
order.  All in all, I can see Nexist doing CG, DAML/OIL, and XTM, all in 
the same system.


> > It may be that the GooseWorks package is
> > going in that direction as well, but I'm not sure yet.
>
>We are focusing more on making the topic map paradigm "omnivorous with
>respect to markup." We want to eat everything... So far, we only
>excrete XTM, though that could change depending on what people's needs
>are, or what people volunteer to do.
>
> > Your thoughts on the notion of going in the direction of a universal,
> > graph-theoretic backside with wrapper/mappers?
>
>That is very close to the direction GW is headed in -- whatever
>"universal" might mean. (I don't think there is anything universal, at
>least that we can have knowledge of. There are only agreements and
>agreements to agree....)

To which, I agree!


>It's also very close to the ISO submission of the "road map."
>
>S.
>
>
>=====
><!-- Topic map consulting:          www.etopicality.com
>      Open source topic map toolkit: www.goose-works.org
>
>"A human is a topic map's way of making another topic map."
>
>-->

[Tm4j-developers] Re: Graph presentation

[Sam H. <sam...@ya...>]

> One wonders if the persistence layer of any knowledge product ought
> not to  consist of something a bit more "universal" (whatever that 
> means) than XTM.  GXL comes to mind, and Murray Altheim seems to be
> heading in that direction. 

Elaine Svenonius says that "objectives determine ontology" (and not the
other way round). So I am not clear on what the objectives are here. I
can see "universal" meaning "closer to the data struture" (more
nodes-and-arcs-ish) or "closer to the knowledge interchanged" (more
subject-and-association-ish).

> It may be that the GooseWorks package is
> going in that direction as well, but I'm not sure yet.

We are focusing more on making the topic map paradigm "omnivorous with
respect to markup." We want to eat everything... So far, we only
excrete XTM, though that could change depending on what people's needs
are, or what people volunteer to do.

> Your thoughts on the notion of going in the direction of a universal,
> graph-theoretic backside with wrapper/mappers?

That is very close to the direction GW is headed in -- whatever
"universal" might mean. (I don't think there is anything universal, at
least that we can have knowledge of. There are only agreements and
agreements to agree....) 

It's also very close to the ISO submission of the "road map." 

S.


=====
<!-- Topic map consulting:          www.etopicality.com 
     Open source topic map toolkit: www.goose-works.org 

"A human is a topic map's way of making another topic map."

-->

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

[Tm4j-developers] Graph presentation

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

It may be that this group is familiar with 
http://touchgraph.sourceforge.net. (Apache)
Another one I just discovered (though others may be familiar with it) is 
http://jgraph.sourceforge.net (LGPL)

An interesting point about jGraph is that it exports to GXL (Graph Exchange 
Language) http://www.gupro.de/GXL/

Which brings to mind an interesting set of issues.

For instance: the world seems to be awash in ontology expression languages, 
like DAML+OIL, OWL (just getting started), CG, RDF, XTM, and so forth 
(assuming you'll allow me to group XTM into that cluster).

One wonders if the persistence layer of any knowledge product ought not to 
consist of something a bit more "universal" (whatever that means) than 
XTM.  GXL comes to mind, and Murray Altheim seems to be heading in that 
direction. It may be that the GooseWorks package is going in that direction 
as well, but I'm not sure yet.

This would imply that the next generation of TM4J could be a wrapper/mapper 
for a GXL backside.  From the same backside, we could wrap/map to 
Conceptual Graphs, DAML+OIL, OWL, and who knows what else.

Your thoughts on the notion of going in the direction of a universal, 
graph-theoretic backside with wrapper/mappers?

Cheers
Jack 

Re: [Tm4j-developers] New TM4J web site design proposal [Long]

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

At 00:25 27/02/2002 +0100, Florian G. Haas wrote:
>Hello all,
>
>as I'm sure most of you are aware, we (Thomas Bauer, to a major extent, and
>Florian Haas, to a minor one) have put some thought into a possible
>re-design of the TM4J project web site. We have completed some design=
 drafts
>and would greatly appreciate your comments.
>
>OK, so we (plus Kal) thought about making the project web site design much
>more Topic-Map-ish, so we could eventually use it for a Velocity- or
>Cocoon-centered application. What we have for now are Photoshop dummies
>(we're working on HTML versions), and please feel free to look at them at
>http://tm4j.org/tmp/HP_DESIGN_9_WEB.JPG and
>http://tm4j.org/tmp/HP_DESIGN_9FLORIAN_WEB.JPG (just two versions of the
>same thing with different "topics"), and let us hear your thoughts.
>Christoph Fr=F6hlich has already provided some very valuable feedback in an
>E-Mail to Kal, which we've attached to this message. Christoph, if you're
>monitoring this list, we hope you don't mind our doing this. Please keep
>telling us stuff like this, it's really more than helpful.
>
>Some other issues that have already come up in informal discussion:
>* Keep the "newsticker"? Or is it just a confusing attention-catcher?
>* Keep the "search" box? It would certainly be nice to have a full-text
>topic map search (or even TMQL, or Tolog), but how would we implement it?

Adding a search with Tolog would be a great feature for the "second stage"=
=20
of the website (once we get it hosted on a machine that supports a servlet=
=20
environment). But for now, perhaps the search should just make use of some=
=20
third-party indexing (e.g. search the site with Google/Lycos) - of course,=
=20
this has the disadvantage that the results will end up taking people away=20
from the website. Does anyone have any experience of setting up search on a=
=20
SourceForge-hosted site ?

Cheers,

Kal

RE: [Tm4j-developers] Index interface proposal checked in

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

Oops - forgot to cc the list on this one.

>Date: Wed, 27 Feb 2002 09:28:10 +0000
>To: "Florian G. Haas" <f.g...@gm...>
>From: Kal Ahmed <ka...@te...>
>Subject: RE: [Tm4j-developers] Index interface proposal checked in
>
>At 00:25 27/02/2002 +0100, you wrote:
>>Hello!
>>
>>I must admit I'm certainly no expert at this, but what you are saying about
>>the general purpose of these indexing mechanisms makes sense to me. Having
>>had a look at the interface definitions themselves, I have a couple of
>>questions:
>>
>>* What's the difference between an "open" and an "initialized" index? In
>>other words, how would IndexProvider.getIndex().isOpen() be different from
>>IndexProvider.getIndexMeta().isInitialised()? And how would that, in turn,
>>differ from IndexManager.getIndexMetaData().isInitialised()?
>
>I think that is an inconsistency that needs to be removed. The close() 
>method was actually added after I had sketched out the design, so I think 
>that changing "initialise" to "open" in most places would make sense.
>
>The difference between IndexProvider and IndexManager is that a 
>IndexProvider is essentially an SPI (service provider interface) that 
>needs to be implemented by developers wishing to add their own indexes to 
>a TM4J application. IndexManager is an API for developers wishing to use 
>indexes through TM4J. So there should be no way for a "user" of the 
>IndexManager interface to ever get hold of a handle to the IndexProvider - 
>hence the extra layers.
>
>I think that the IndexMeta.isInitialised should probably be removed - that 
>is more state information than meta information about the index. I think 
>that the state information should be accessible through the Index object 
>itself.
>
>I'll update the interfaces accordingly.
>
>>* What would be an "explicit runtime initialisation" as mentioned in the
>>documentation for IndexManager?
>
>My thought was that some of these indexes might be quite heavy in terms of 
>local resources used and so you wouldn't necessarily want them open as 
>soon as the IndexProvider is loaded (seeing as an IndexProvider might be 
>providing a set of indexes). So I originally intended explicit runtime 
>initilisation to be the act of calling IndexProvider.getIndex(), but I 
>think in retrospect that adding Index.open() would make sense and would 
>put the explicit initialisation in the right place.
>
>Cheers,
>
>Kal

Re: [Tm4j-developers] New TM4J web site design proposal [Long]

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

On Wed, 27 Feb 2002 00:25:04 +0100
"Florian G. Haas" <f.g...@gm...> wrote:

> Hello all,
> 
> as I'm sure most of you are aware, we (Thomas Bauer, to a major extent, and
> Florian Haas, to a minor one) have put some thought into a possible
> re-design of the TM4J project web site. We have completed some design drafts
> and would greatly appreciate your comments.
> 
> OK, so we (plus Kal) thought about making the project web site design much
> more Topic-Map-ish, so we could eventually use it for a Velocity- or
> Cocoon-centered application. What we have for now are Photoshop dummies
> (we're working on HTML versions), and please feel free to look at them at
> http://tm4j.org/tmp/HP_DESIGN_9_WEB.JPG and
> http://tm4j.org/tmp/HP_DESIGN_9FLORIAN_WEB.JPG (just two versions of the
> same thing with different "topics"), and let us hear your thoughts.
> Christoph Fröhlich has already provided some very valuable feedback in an
> E-Mail to Kal, which we've attached to this message. Christoph, if you're
> monitoring this list, we hope you don't mind our doing this. Please keep
> telling us stuff like this, it's really more than helpful.
> 
> Some other issues that have already come up in informal discussion:
> * Keep the "newsticker"? Or is it just a confusing attention-catcher?
> * Keep the "search" box? It would certainly be nice to have a full-text
> topic map search (or even TMQL, or Tolog), but how would we implement it?
> 
> Let's hope we get some good discussion going about this! :-)

I like the overall design. It's frugal but very distinctive.

But I agree with Christoph that the 'a topic map
engine for java' line in the header is to much. Also the shadow of 
'topic maps 4 java' is to heavy. Perhaps you should drop the 'topic maps for java'
from the TM4J logo and leave 'topic maps 4 java'.

The navgation bar doesn't stand out enough. So you have to search for at first.
I would suggest another background color for it and maybe we should also move it
to left side. 

Also I think the newsticker isn't necessary if we have the 'news' box.

I would also drop the 'optimized for explorer' hint. The site should work for
all browsers in the same quality.

Best Regards,
Gerd

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

[Tm4j-developers] New TM4J web site design proposal [Long]

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

Hello all,

as I'm sure most of you are aware, we (Thomas Bauer, to a major extent, and
Florian Haas, to a minor one) have put some thought into a possible
re-design of the TM4J project web site. We have completed some design drafts
and would greatly appreciate your comments.

OK, so we (plus Kal) thought about making the project web site design much
more Topic-Map-ish, so we could eventually use it for a Velocity- or
Cocoon-centered application. What we have for now are Photoshop dummies
(we're working on HTML versions), and please feel free to look at them at
http://tm4j.org/tmp/HP_DESIGN_9_WEB.JPG and
http://tm4j.org/tmp/HP_DESIGN_9FLORIAN_WEB.JPG (just two versions of the
same thing with different "topics"), and let us hear your thoughts.
Christoph Fröhlich has already provided some very valuable feedback in an
E-Mail to Kal, which we've attached to this message. Christoph, if you're
monitoring this list, we hope you don't mind our doing this. Please keep
telling us stuff like this, it's really more than helpful.

Some other issues that have already come up in informal discussion:
* Keep the "newsticker"? Or is it just a confusing attention-catcher?
* Keep the "search" box? It would certainly be nice to have a full-text
topic map search (or even TMQL, or Tolog), but how would we implement it?

Let's hope we get some good discussion going about this! :-)

Best regards,

Florian
Thomas


| >Envelope-to: ka...@on...
| >X-Sender: pt7...@po...
| >Date: Tue, 26 Feb 2002 13:17:26 +0200
| >To: ka...@te...
| >From: Christoph Fröhlich  <cf...@fo...>
| >Subject: Site Design
| >
[...]
| >What I can do for now is to make some suggestions for  the proposed site
| >design.
| >
| >
| >I like the "boxy" layout. It appears straight to me, with focus on the
| >content and no too much illustrative elements.
| >Furthermore, the designers know about proportions, setting fontsizes in
| >relation to each other etc.
| >So. Yes, I like it. Nevertheless, I have some suggestions
| >
| >1.
| >The typo "topic maps 4 java" with the shadow.
| >I think, that element doesn't tell you anything new. It provides
| just the
| >same info as the logo-like TM4J-Typo in the upper left corner,
| along with
| >the subline "Topic maps for Java". What makes it worse, is,  that the
| >shadow attracts the visitors attention. Visually it serves as the "first
| >read", while it provides absolute no info. It is a bit like a
| black hole,
| >where your visitors attention will get lost. The "first read" on
| that page
| >should be the name of the topic in focus, eg. "Florian G. Haas". So I
| >think you should dispose the typo and the shadow.
| >
| >
| >2.
| >Rearrange the boxes.
| >My understanding of the layout says: While the visitor is navigating
| >through the map the content of the three boxes "main information",
| >"navigation bar" and "abstract" changes with the topic in focus.
| Is that right?
| >The other three boxes show site-related info and do not change while
| >exploring the map.
| >i think you should arrange all boxes which display info from the
| map close
| >to each other and do not spread them all over the page
| >If you follow my argumentation in 1. and dispose shadow and
| typo, then you
| >will gain some space at the top of the page for the news and the
| search boxes.
| >
| >
| >3.
| >I miss  some "global navigation".
| >I think you should provide the visitors with some entrypoints to the map.
| >Perhaps something like "Projects", "Persons" etc.
| >While the content of the boxes "main", "navigatioN" and
| "abstract" changes
| >with every click, there should be some stable landmarks, which gives you
| >the chance to start over, after you got lost in the sea of knowledge.
| >
| >
| >
| >  Please kay, keep in mind, that i am not too comfortable with writing
| > english. If it is not possible to understand what I have
| written, please
| > feel free to ask.
| >
| >
| >Regards
| >
| >cf
| >
| >
|

RE: [Tm4j-developers] Index interface proposal checked in

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

Hello!

I must admit I'm certainly no expert at this, but what you are saying about
the general purpose of these indexing mechanisms makes sense to me. Having
had a look at the interface definitions themselves, I have a couple of
questions:

* What's the difference between an "open" and an "initialized" index? In
other words, how would IndexProvider.getIndex().isOpen() be different from
IndexProvider.getIndexMeta().isInitialised()? And how would that, in turn,
differ from IndexManager.getIndexMetaData().isInitialised()?

* What would be an "explicit runtime initialisation" as mentioned in the
documentation for IndexManager?

Later,
-- Florian

[Tm4j-developers] Index interface proposal checked in

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

Hi all,

I have checked in a batch of new interfaces in the package 
org.tm4j.topicmap.index. These are intended to be an approach to 
rationalising the provision of indexing services in TM4J. Basically the 
idea is that each topic map has an associated IndexManager which is 
responsible for maintaining a collection of IndexProviders. Each 
IndexProvider may provide one or more interfaces which must support an 
interface derived from the (very simple) Index interface. In the user code, 
the intention is that you would do something like this:

IndexManager ixMgr = tm.getIndexManager();
TopicTypeIndex tti = 
(TopicTypeIndex)ixMgr.getIndex("org.tm4j.topicmap.index.basic.TopicTypeIndex");
Collection results = tti.getTopicsOfType(myType);

In this case, org.tm4j.topicmap.index.basic.TopicTypeIndex would be an 
interface derived from org.tm4j.topicmap.index.Index which adds the 
getTopicsOfType() method (and maybe some others). Although the caller knows 
which interface she is using, she does not need to know how that interface 
is implemented. From an in-memory TopicMap, the implementation returned may 
use a Map internally, or it may do a brute-force iteration through all of 
the topics in the map. A relational DB might use a query against a 
TOPIC_TYPES table. The available indexes will be initialised by the 
TopicMapProvider, although the IndexManager interface also allows callers 
to extend the set of provided indexes by registering their own indexes at 
run-time. We may also want to think about allowing extensions to be 
automatically read from a properties file.

Comments ?

Cheers,

Kal

[Tm4j-developers] XTM Conformance Models

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

Hi all,

I am currently thinking about ways to support complete conformance with 
Annex F of XTM 1.0. Briefly, XTM defines the concept of a "consistent" 
topic map in which all topics are merged and all duplicates are suppressed 
in conformance with XTM 1.0  Annex F.

In my mind there are three possible approaches to supporting this:

1) A "static translation" approach - you can construct any topic map you 
like which may or may not be a "consistent" topic map. You then use a 
utility to process the topic map into a consistent topic map - this would 
remove the dynamic merges from the topic map and would eliminate all 
duplicates. This is currently implemented as org.tm4j.topicmap.Compressor 
(needs a better name!)

2) A "dynamic" layer over the basic TM4J implementation - This approach is 
a shim layer which wraps any TopicMapProvider and creates a layer of 
consistency validation around all methods which can update the topic - the 
shim makes sure that no call is allowed to violate the consistency of the 
topic map. Persistent implementations might also want to store a flag that 
indicates whether or not a particular TopicMap object should be wrapped in 
the consistency-enforcing layer.

I think that there is room for / need for both of these approaches - The 
tradeoff as I see it is that (2) eliminates a lot of the freedom and 
flexibility of TM4J (particularly in the dynamic merging), so simply making 
the core API enforce consistency is not an option IMHO; whereas  (1) is 
nice as it only enforces consistency at the point of use, but it is 
extremely processor intensive (though additional indexing layers could 
probably improve this) and so is not really a viable alternative when 
dealing with large topic maps in a persistent store.

I would like to hear others thoughts

Cheers,

Kal

Re: [Tm4j-developers] New source branch

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

At 10:44 25/02/2002 +0100, Norbert Hartl wrote:
>Hi,
>
>>I will freely admit that I have very little experience in developing with 
>>CVS branches - any hints and tips from pros on the list would be 
>>gratefully received!
>On which checkpoint did you create the branch? On a date checkpoint?
>Usually you would tag a current state for possible branch action.
>If you have a tag you can branch whenever you like to based on the
>tag. It is also a lot easier to check things changed when working
>with tags.

At least I started off in the right direction then! The branch was created 
from the R_0_6_0 tag

>Joining the branch in the HEAD trunk needs just a little discipline.
>While it isn't necessary to freeze the tree while joining in the HEAD
>trunk I would recommmend to do so. It keeps the level of cvs command
>complexity low.
>
>A good style would always be:
>
>- tag the tree for a branch candidate
>- if it is necessary branch at that tag
>- everybody works on his branch of intereset
>- prevent others to commit changes while
>   you are joining the branch
>- tag the tree at the point you joined the branch
>- decide if you need the branch any longer
>- if not make sure everybody switched his local copy
>   from branch to the HEAD tree
>
>I hope this is of any help,

A lot of help, thanks Norbert.

Cheers,

Kal

Re: [Tm4j-developers] New source branch

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

Hi,

> I will freely admit that I have very little experience in developing 
> with CVS branches - any hints and tips from pros on the list would be 
> gratefully received!
> 
On which checkpoint did you create the branch? On a date checkpoint?
Usually you would tag a current state for possible branch action.
If you have a tag you can branch whenever you like to based on the
tag. It is also a lot easier to check things changed when working
with tags.

Joining the branch in the HEAD trunk needs just a little discipline.
While it isn't necessary to freeze the tree while joining in the HEAD
trunk I would recommmend to do so. It keeps the level of cvs command
complexity low.

A good style would always be:

- tag the tree for a branch candidate
- if it is necessary branch at that tag
- everybody works on his branch of intereset
- prevent others to commit changes while
   you are joining the branch
- tag the tree at the point you joined the branch
- decide if you need the branch any longer
- if not make sure everybody switched his local copy
   from branch to the HEAD tree

I hope this is of any help,

Norbert

[Tm4j-developers] New source branch

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

Hi all,

I have created a new branch for bug fixes to 0.6.0. The branch label is 
R_0_6_1. If you fix a bug in release 0.6.0, please fix it in this branch - 
I am planning on making a release from this branch next week sometime to 
fix bug #520084. I have fixed this bug in both branches of the tree 
(actually fixed in the main branch before creating the patches branch.

I will freely admit that I have very little experience in developing with 
CVS branches - any hints and tips from pros on the list would be gratefully 
received!

Cheers,

Kal

[Tm4j-developers] Survey results

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

Hi all,

Unfortunately, SourceForge's survey system seems to have let us down - very 
few questions had any results logged for them at all. So rather than try 
and repeat that experiment, I have entered all of the proposed features as 
tasks in the SourceForge Task tracker 
(http://sourceforge.net/pm/?group_id=27895). As you will see, there are 
currently 3 subprojects - Unassigned, 0.6.1 and 0.7.0. My feeling now is 
that 0.6.1 should contain only bug fix tasks (in fact, there is probably no 
need to enter tasks as they are already tracked in the bug system). I have 
added what I think are the key priorities for 0.7.0 to the 0.7.0 
subproject. If anyone would like to volunteer for any of these tasks, that 
would be great!. If any one would like to propose another task for the 
0.7.0 release, please let me know - I would not mind moving some more of 
the tasks into 0.7.0, but only if we have volunteers to do the extra work.

Cheers,

Kal