tm4j-developers

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

[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 

[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

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

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

[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

[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

[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

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:
[...]
>> 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

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

I've begun to make comments along this line at http://graphs.memes.net
Do you folks think that's an appropriate place to evolve a discussion on 
using, say, GXL as a base API on which database servers can plug into the 
backside and various wrappers can plug into the front side?

Cheers
Jack

At 05:33 PM 2/28/2002 +0000, Murray Altheim wrote:
>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] 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] 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...>]

At 21:02 28/02/2002 +0100, Florian G. Haas wrote:
>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.

Agree - will rename to getIndexMeta() as this matches the class name.

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

Good suggestions!

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

I wanted to keep the IndexProvider interface as small and easy to implement 
as possible - it really only needs to expose methods for the IndexManager 
implementations to use. So I'll keep these suggestions in my back pocket 
for now...but I do think that overloading the IndexManager functions to 
accept Class parameters as well as String parameters makes sense.

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

it is java.lang.UnsupportedOperationException.


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

Oops - my mistake - too eager to get the updates out :) They should both 
have a throws clause.

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

Another "itchy commit finger" error ;-)


>Hope I'm making sense,


Definitely!  Thanks for taking the time to review and comment.

Cheers,

Kal

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

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

Looks like we are getting close here. Another batch of changes just checked 
in. Comments are still welcome!

Cheers,

Kal