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

Re: [Tm4j-developers] TMEdit

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

Hello!

[norbert]
> >Hi,
> >
> >as you know I started to build an editing tool for topic maps.
> >I did a swing approach defining widgets for topicmaps object
> >types. Now I don't thing the code is useful anymore.
> >First thing is I'm quite too unexperienced building swing
> >stuff. Second is that I would prefer doing other stuff than
> >GUIs :)
> >
> >How do you edit your topicmaps, guys? Do you generate them
> >dynamically or are there tools right now which I can use?

[kal] 
> Emacs ? ;-)
> 
> Seriously, if I am hacking together a small map in a single session, I use
> a text editor (usually Emacs) - but this is really painful with XTM
> syntax. 

I either use vi or XML Spy (www.xmlspy.com), the latter being the XML editor
we commonly use at the place where I work (and which is made by an Austrian
company, as I'm happy to report :-) ). It's a very nice and handy XML editor
which will alleviate much of the well-formedness and validity issues stemming
from banal typos, along with providing built-in XSLT and schema editing.
It's not free software, though, that might be a problem. :-) 

-- Florian

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: [Tm4j-developers] TMEdit

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

At 10:24 23/01/2002 +0100, Norbert Hartl wrote:
>Hi,
>
>as you know I started to build an editing tool for topic maps.
>I did a swing approach defining widgets for topicmaps object
>types. Now I don't thing the code is useful anymore.
>First thing is I'm quite too unexperienced building swing
>stuff. Second is that I would prefer doing other stuff than
>GUIs :)
>
>How do you edit your topicmaps, guys? Do you generate them
>dynamically or are there tools right now which I can use?

Emacs ? ;-)

Seriously, if I am hacking together a small map in a single session, I use 
a text editor (usually Emacs) - but this is really painful with XTM syntax. 
Ontopia's LTM syntax (http://www.ontopia.net/download/ltm.html) is much 
simpler to hand-code - anyone fancy hacking up support for it in TM4J ?

For bigger topic maps, I use TMTab 
(http://www.techquila.com/tmtab/index.html) - which is a plug-in for 
Protege. Unfortunately, this is an export-only plug-in, so you have to 
develop your topic map ontology from scratch in Protege - but if you do 
this, you get a nice forms-based interface and you can make restrictions on 
associations (e.g. composed-by can only have an instance of Person playing 
the composer role and an instance of Work playing the composed-piece role). 
TMTab  uses TM4J :-), and despite what it says on the website, it works 
fine with Protege 1.6.2 (the latest release version of Protege).

Cheers,

Kal

[Tm4j-developers] TMEdit

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

Hi,

as you know I started to build an editing tool for topic maps.
I did a swing approach defining widgets for topicmaps object
types. Now I don't thing the code is useful anymore.
First thing is I'm quite too unexperienced building swing
stuff. Second is that I would prefer doing other stuff than
GUIs :)

How do you edit your topicmaps, guys? Do you generate them
dynamically or are there tools right now which I can use?

Norbert

RE: [Tm4j-developers] question about hierachial relationships

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

Hello Tim,

[Tim Smith]
| I can create an association "mamanges" from employee to manager
| but how do I know which is the appropriate scope? For Mark he is both a
| manager and employee and hence would fit both scopes.

wherever there are two relationships, you'll use two associations. In order
to define the roles of association players, you'll use role specs. For an
XTM example, take Mark:

	<!-- Mark is managed by Paul. -->
	<association>
		<instanceOf>
			<topicRef xlink:href="#manage"/>
		</instanceOf>
		<member>
			<roleSpec>
				<topicRef xlink:href="#manager"/>
			</roleSpec>
			<topicRef xlink:href="#paul"/>
		</member>
		<!-- In this case, Mark is the one getting managed, hence he plays the
role of "subordinate". -->
		<member>
			<roleSpec>
				<topicRef xlink:href="#subordinate"/>
			</roleSpec>
			<topicRef xlink:href="#mark"/>
		</member>
	</association>
	<!-- Tim is managed by Mark. -->
	<association>
		<instanceOf>
			<topicRef xlink:href="#manage"/>
		</instanceOf>
		<!-- Here, Mark is the one managing, hence he plays the role of
"manager". -->
		<member>
			<roleSpec>
				<topicRef xlink:href="#manager"/>
			</roleSpec>
			<topicRef xlink:href="#mark"/>
		</member>
		<member>
			<roleSpec>
				<topicRef xlink:href="#subordinate"/>
			</roleSpec>
			<topicRef xlink:href="#tim"/>
		</member>
	</association>

Of course, you would have to define the typing and role-defining topics
beforehand.
Am I making sense?

hth
-- Florian

[Tm4j-developers] question about hierachial relationships

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

Hi All,
I'm having some trouble with this problem

My name is Tim. I am an employee 

My manager's name is Mark. he is an employee and a manager

My manager's manager's name is Paul. he is an employee and a manager

(etc)

how do I represent this such that I can retrieve
Mark
	manages Tim
	is managed by Paul

Paul
	manges Mark
	(is managed by someone else)

Tim
	is managed by Mark


I can create an association "mamanges" from employee to manager
but how do I know which is the appropriate scope? For Mark he is both a
manager and employee and hence would fit both scopes.

I know I can do this using a hierachy
(Tim is APS5, Mark is APS6, Pual is APS7) but this gets very cumbersome and
isn't always strictly accurate!

Help please!
Thanks
Tim

[Tm4j-developers] From a Cocoon novice: some research [long]

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

Hello all,

First of all: welcome back, Norbert! :-)

As I suppose most of you know, I've lately been looking into Cocoon as a
possibly useful mechanism of providing TM4J-based dynamic XML applications.
I'D ask you to take a moment so I can share my thoughts with you. Comments
would be more than appreciated.

First of all, I'm pretty much thrilled of what Cocoon is capable of. Looks
like Stefano and crew have put together a really impressive piece of work.
:-) One of the things I like best about it is that most webapp-specific
setup is purely of the administrative type -- no coding necessary at all.
Handling request parameters and headers, XSLT transformation, session
tracking, all that's taken care of, so no need to reinvent the wheel. As
soon as you have you XML sources and your XSLT stylesheets, you hack a few
config files (which, admittedly, isn't exactly a piece of cake for a novice
like me, but absolutely feasible), boom, there you go. Caching facility
included, needless to say.

The following paragraph is just my interpretation of what Cocoon does, in
general. Feel free to skip this if you're already familiar with Cocoon. :-)

Firstly, a Cocoon app involves a Generator (an XML source provider), used to
create a SAX event stream from a variety of sources. At the simplest, this
is an XML file available in the local filesystem or via a URL, but it may
also be something like a directory full of image files from which the
Generator creates an XML meta info source. About a dozen different
Generators are readily available. Shoot, this thing even provides its Java
exceptions as XML sources. :-)
Secondly, this XML event stream is transformed using one of a dozen
transformers, the basic one of which is XSLT. Of course, one is able to
provide parameters for stylesheet execution (to be used with <xsl:param>),
and there's also a provision for including a "browser capability database"
for useragent-specific processing.
Thirdly, Cocoon applies a Serializer to produce the actual output. If one
feels like keeping things simple, one would use the HTML, XML, or text
Serializer, but there's also one for PDF (via FOP), for SVG, and for cool
stuff like creating JPEG images from SVG sources (via the batik
transcoder) -- for the SVG plugin impaired. Caveat on the last bit: I
haven't gotten the SVG/JPEG thing to work on my machine yet.
This whole sequence ("pipeline") can be administered and parameterized by a
single "sitemap" XML document providing a ton of config options (including
the kitchen sink). I have to admit that that file still looks *very*
confusing to me -- but I sure wasn't feeling any different when I first
looked at, say, squid.conf. :-) So I guess it just takes a little getting
used to.

By the way, getting Cocoon itself up & running was a piece of cake.
Installed Tomcat, copied the WAR archive from the Cocoon binary distro,
started Tomcat, done. My config is Tomcat 4.0.1 with Cocoon 2.0 on a Win2k
box (sorry).

So, at first glance, Cocoon should seem like a very nice approach for a
TM-based web app, provided it has *consistent* Topic Maps available.
However, what we want, I assume, is an app which we feed really ugly topic
maps, then merge and resolve like lunatics using TM4J, whereupon we get
consistent TM's, then do the whole transformation bit. We might achieve this
using Cocoon's XSP facility, allowing JSP-like functionality, only that it's
not limited to Java as a programming language. There's even a provision for
using Python (via Jython) -- I thought Kal might like that. :-)

I'd really appreciate your thoughts & comments on this issue. In case I got
you curious, you might want to visit http://xml.apache.org/cocoon for
further info. Two things that might be specifically interesting for TM4J is
the "Extending Cocoon" section at
http://xml.apache.org/cocoon/developing/extending.html, especially the
paragraph titled "When To Write A Generator", and the XSP section,
http://xml.apache.org/cocoon/userdocs/xsp/xsp.html.

From your point of view: could we use Cocoon?

-- Florian

Re: [Tm4j-developers] back to life

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

Hi Norbert

Nice to have you back :-)

Kal

At 10:54 22/01/2002 +0100, Norbert Hartl wrote:
>Hi guys,
>
>I'm back to reality. A lot of things happened at the end
>of last year which forced me to discontinue working
>for tm4j.
>Now I hope that I'll have a little more time to participate
>again.
>
>just to say hello again,
>
>Norbert
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>

[Tm4j-developers] back to life

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

Hi guys,

I'm back to reality. A lot of things happened at the end
of last year which forced me to discontinue working
for tm4j.
Now I hope that I'll have a little more time to participate
again.

just to say hello again,

Norbert

Re: [Tm4j-developers] Some thoughts about Variant and VariantContainer

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

At 14:13 19/01/2002 +0100, Florian G. Haas wrote:
>Hi all,
>
>while doing some documentation for the Variant and VariantContainer
>interfaces, I noticed two things, one of which I think is an outright
>implementation error and the other just a missing feature. If I'm just
>misinterpreting things here, though, please correct me! :-)
>
>Firstly, about Variant. We have getVariantNames(), addVariantName(), and
>setVariantNames() methods in there which IMHO don't make too much sense
>because XTM dictates that a <variant> either has one <variantName>, or none
>at all:
>
><!-- variant: Alternate forms of Base Name ....................... -->
>
><!ELEMENT variant  ( parameters, variantName?, variant* ) >
><!ATTLIST variant
>    id              ID        #IMPLIED
> >

Yep, you are right on this. I don't know how that managed to slip through...

>I've submitted this as bug #505083. I guess replacing these methods by
>getVariantName() and setVariantName() should be on the to-do list for the
>0.7.0 release.
>
>Secondly, about VariantContainer. It's not quite clear from the interface
>definition what getVariants() is supposed to be doing -- return just the
>immediate Variant children of the Variant or BaseName in question (which
>VariantContainerImpl does, for example), or drill down any potential
>Variant-inside-Variant hierarchy. Perhaps we should look at overloading this
>method with getVariants(boolean deep), so if deep is true, it drills down,
>if false, it just returns the immediate children. And then just invoking
>getVariants() would imply getVariants(false), so the default behavior is to
>only return the immediate children.

getVariants() currently returns just the immediate child Variants of the 
container. A getVariants(deep) sounds like a useful thing to have. However, 
if we have a method returning a collection of Variants, it would also be 
useful to have Variant.getEffectiveScope() which traverses back up the 
parent hierarchy gathering all the scoping topics together.


>I know I'm jumping ahead of things here, but I guess it wouldn't be much use
>to toss in such interface changes for 0.6.0, of which we have already seen
>the alpha release.

I was hoping to keep the interfaces stable from the start of the alpha 
cycle, but I've found it necessary to modify some interfaces to fix a 
different bug. Sigh.

I would like 0.6.0 to be out soon, but I would also like it to be as near 
to a 1.0 release as possible. For that reason I suggest that we make the 
changes now and instead go for stability of interfaces with 0.6.0 beta 1 
(which I think should be the next release).

Comments anyone ?

Kal

[Tm4j-developers] Some thoughts about Variant and VariantContainer

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

Hi all,

while doing some documentation for the Variant and VariantContainer
interfaces, I noticed two things, one of which I think is an outright
implementation error and the other just a missing feature. If I'm just
misinterpreting things here, though, please correct me! :-)

Firstly, about Variant. We have getVariantNames(), addVariantName(), and
setVariantNames() methods in there which IMHO don't make too much sense
because XTM dictates that a <variant> either has one <variantName>, or none
at all:

<!-- variant: Alternate forms of Base Name ....................... -->

<!ELEMENT variant  ( parameters, variantName?, variant* ) >
<!ATTLIST variant
   id              ID        #IMPLIED
>

I've submitted this as bug #505083. I guess replacing these methods by
getVariantName() and setVariantName() should be on the to-do list for the
0.7.0 release.

Secondly, about VariantContainer. It's not quite clear from the interface
definition what getVariants() is supposed to be doing -- return just the
immediate Variant children of the Variant or BaseName in question (which
VariantContainerImpl does, for example), or drill down any potential
Variant-inside-Variant hierarchy. Perhaps we should look at overloading this
method with getVariants(boolean deep), so if deep is true, it drills down,
if false, it just returns the immediate children. And then just invoking
getVariants() would imply getVariants(false), so the default behavior is to
only return the immediate children.

I know I'm jumping ahead of things here, but I guess it wouldn't be much use
to toss in such interface changes for 0.6.0, of which we have already seen
the alpha release.

Comments, please! :-)

Later,
-- Florian

RE: [Tm4j-developers] Potential bug in 0.6.0

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

Hi Tim,

At 10:39 18/01/2002 +1100, Smith, Tim wrote:

>Hi, I may have found a bug in 0.6.0
>
>I had 2 topics with the same base name but different subject indicators, but
>was given the incorrect topic by utils.getObjectsOfType.
>
>EXAMPLE 5 topics
>A1, A2, B, C and D
>C has 2 children, A2 and B
>A1 has 1 child, D
>A1 and A2 have the same base name (A) but different subject indicators
>
>I used utils.getObjectsOfType on C
>I got back 2 children A and B (so far so good)
>BUT further examination seems to suggest it was actually A1 (not A2) that
>was being returned as the A returned had a child, D
>
>Might just be my crazy code, but I don't think so.

Not your crazy code, mate, just your crazy topic map ! ;-)

What I think has happened is that A1 and A2 have been merged - this would 
have happened because of the base name match. Having different subject 
indicators does not prevent two topics merging if they have the same base 
name in the same scope. So my guess is that you will find that A1 and A2 
have been merged and that you are being returned the "base topic" of that 
merged pair. Exactly which of the topics it is is dependent on the order in 
which they were parsed from the topic map (not necessarily the order in 
which they were declared in the XTM file, though this is usually the case). 
Because of the "dynamic" merging model of TM4J, the two topics actually 
still exist independently, but one is the controlling "base topic" and the 
other is a "merged topic". When you call a method to get the properties of 
the base topic, what you are actually returned is the combination of the 
properties of the base topic and all of its merged topics (unless you use 
the versions of the accessors which accept a single boolean parameter and 
set that parameter to false).

If I have got this right, I expect that you will find that:

A.equals(A1) || A.equals(A2)
A.getSubjectIndicators().size() == 2
A.getMergedTopics().size() == 1

BTW, this has an important consequence. When you get a topic from a method 
call such as Member.getPlayers() or Topic.getType(), it is wise to call 
Topic.getBaseTopic(). If the topic is not merged, or if it is the "base 
topic" of a merged set, it will simply return itself. If the topic is 
merged with some other topics, you will get a different Topic object.

Cheers,

Kal

RE: [Tm4j-developers] Merging

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

Hi Tim,

Mergemap is not currently supported by TM4J. Almost all of the "plumbing" 
is done with the sole exception of Locator resolution to get a data stream 
- I do expect the 0.6.0 beta release to contain this functionality. 
Hopefully I should have the opportunity to get something operational in CVS 
by the end of this month.

In the meantime, you should be able to merge topic maps "manually" using 
the command-line Merge application (not ideal, I realise, but a short-term 
work-around perhaps)

Cheers,

Kal

At 10:48 18/01/2002 +1100, Smith, Tim wrote:
>Hello again all,
>
>just to check, is the xtm mergemap directive supported by tm4j? It doesn't
>seem to work for me, and I'm not sure if it is just the way I am doing
>things or the way it is.
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers

RE: [Tm4j-developers] Merging

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

Hello again all,

just to check, is the xtm mergemap directive supported by tm4j? It doesn't
seem to work for me, and I'm not sure if it is just the way I am doing
things or the way it is.

RE: [Tm4j-developers] Potential bug in 0.6.0

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

Hi, I may have found a bug in 0.6.0

I had 2 topics with the same base name but different subject indicators, but
was given the incorrect topic by utils.getObjectsOfType.

EXAMPLE 5 topics
A1, A2, B, C and D 
C has 2 children, A2 and B
A1 has 1 child, D
A1 and A2 have the same base name (A) but different subject indicators

I used utils.getObjectsOfType on C
I got back 2 children A and B (so far so good)
BUT further examination seems to suggest it was actually A1 (not A2) that
was being returned as the A returned had a child, D

Might just be my crazy code, but I don't think so.

Thanks

Tim

RE: [Tm4j-developers] Please Help!

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

Hi Tim,

Firstly, the associations can be ignored as long as your typing is done 
using <instanceOf>. Topic types are represented in two ways in TM4J - as 
properties of the topics (retrievable with Topic.getTypes()) and as 
associations between the class topic and the instance topic. The XTM 
specification declares these representations as equivalent and TM4J takes 
the approach of keeping both of the representations in its internal model. 
Typically, it is easier to use the properties of Topic than to traverse the 
associations, so:

To find all topics which are instances of B, you need to use the 
getObjectsOfType() method in TopicMapUtils:
getObjectsOfType actually works as a filter over a collection of the typed 
objects you want it to look at -  it will then return those objects which 
include the specified topic as one of their types.

Skeleton code:

TopicMap tm;
// Set up your map here
Topic b;
// Grab b from tm
TopicMapUtils utils = tm.getUtils();
Collection kids = utils.getObjectsOfType(b, tm.getTopics());
// At this point, kids should contain topics C and D

To find the topics of which B is itself an instance, simply use 
Topic.getTypes():
Collection parents = b.getTypes();
// At this point parents should contain just A

Of course, you might also be wanting to iterate through the associations of 
the topic map and only process those which are not representing the 
class-instance association. You can easily determine whether an association 
is a class-instance association as these associations are typed by a topic 
which has a fixed PSI as one of its subject indicators, so given an 
association a:

Topic assocType = a.getType();
boolean isTypeInstanceAssoc = false;
if ((assocType != null) && (assocType.contains(PSI.ASSOC_CLASS_INSTANCE)))
{
   isTypeInstanceAssoc  = true;
}

Hope this helps

Cheers,

Kal

At 12:11 10/01/2002 +1100, you wrote:
>Hi everyone,
>I am just starting to look at TM4J, 0.5.0
>I have been analysing output and reading APIs, but I just cannot crack this
>one...
>I have 4 topics A, B, C and D
>C and D are instances of B.
>B is an instance of A
>
>How do I write an application that, given B, can find B's children C and D,
>and B's parent A?
>
>At the moment I can that C and D have the same type (let's call it Z) and
>are therefore siblings.
>B has type Y
>
>There are associations that show arelationship between B and Y, C and Z and
>D and Z.
>
>Knowing the structure I can see that Z is a "metaphor" for B and Y is a
>"metaphor" for A but I don't know how to make the machine realise this
>without knowing the structure!
>
>Please help!
>Thanks
>Tim Smith
>
>PS in the developers document guarantee has been spelt guaruntee
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers

RE: [Tm4j-developers] Please Help!

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

Hi everyone,
I am just starting to look at TM4J, 0.5.0
I have been analysing output and reading APIs, but I just cannot crack this
one...
I have 4 topics A, B, C and D
C and D are instances of B.
B is an instance of A

How do I write an application that, given B, can find B's children C and D,
and B's parent A?

At the moment I can that C and D have the same type (let's call it Z) and
are therefore siblings.
B has type Y

There are associations that show arelationship between B and Y, C and Z and
D and Z.

Knowing the structure I can see that Z is a "metaphor" for B and Y is a
"metaphor" for A but I don't know how to make the machine realise this
without knowing the structure!

Please help!
Thanks
Tim Smith

PS in the developers document guarantee has been spelt guaruntee 

Re: [Tm4j-developers] TMNav status

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

+1 for a separate module

> I would just like to explain why I am proposing to remove TMNav from the 
> main TM4J distribution. Basically, it is my feeling that the application 
> needs a complete ground-up rewrite - this is quite a big task and I don't 
> want to hold up releases of TM4J while this happens. Reasons for needing a 
> rewrite include
> 
> 1) The major changes to the TM4J API mean that some things in TMNav could 
> be done more efficiently
> 2) TMNav never supported multiple backends
> 3) TheBrain SDK is no longer freely downloadable, so a new visualisation is 
> needed
> 4) The interfaces of TMNav need reworking to support pluggable UI elements.
> 
> How do you all feel about making TMNav a separate project ? It could still 
> be hosted under the TM4J SourceForge project but should probably have its 
> own CVS module and its own separate release packages.



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

Re: [Tm4j-developers] TopicMapProvider and TopicMapFactory

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

On Sat, 05 Jan 2002 11:37:22 +0000
Kal Ahmed <ka...@te...> wrote:

> Hi,
> 
> This is to explain some quite significant changes made to the 
> TopicMapProvider and TopicMapFactory interfaces.
> 
> The TopicMapFactory interface is essentially tied to a particular topic 
> map. For example, the semantics of createTopic() are that a Topic object is 
> created and added to a TopicMap object (this should also be the semantics 
> of createAssociation(), BTW). The TopicMap object is provided to the 
> TopicMapFactory by one of the following methods:
> a) Provided at creation of the TopicMapFactory object
> b) Provided by a setTopicMap() method on the factory
> c) Created by a call to TopicMapFactory.createTopicMap()
> 
> Additionally, when a new TopicMap is created, it must be registered with 
> the Provider (typically by calling addTopicMap()).
> 
> My feeling is that, especially in dealing with persistent stores such as 
> Ozone, this could be simplified, and I have had a go at doing this. What I 
> propose is that:
> 
> a) TopicMapFactory.createTopicMap() is deprecated / removed
> b) Instead, TopicMap objects are created by the TopicMapProvider by calling 
> createTopicMap()
> 
> All other objects are still created by the TopicMapFactory interface which 
> may itself be retrieved by calling TopicMap.getFactory().

+1 from me. Another possiblity would a getTopicMapFactory()-method 
at TopicMapProvider and but since all methods there are TopicMap
related, I guess, your solution is the best.

Best Regards,
Gerd

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

Re: [Tm4j-developers] 0.6.0 Release Status

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

> Hi all and Happy New Year !

The same to you.

I've got no status to report since you did all the work with ozone. 

Thank you,

Gerd


> You may have noticed a big batch of CVS check-ins just prior to New Year. 
> Most of it was to do with bringing the Ozone implementation up to the new 
> core interfaces. In the course of doing that I found that it made sense to 
> change one or two other interfaces too.
> 
> Now, it has been quite a while since the last release of source and binary 
> distributions and I am considering an 0.6.0 release to be made over the 
> next couple of weeks. What I would like to know from everyone involved in 
> development is what the state of their subsystems are. Here is my list:
> 
> Core Interfaces: Many updates from 0.5.0 completed. Need a final review of 
> the way in which TopicMapProvider and TopicMapFactory interact
> 
> Net Interfaces: Basic interfaces complete. Ready for release
> 
> In-memory Core Implementation: Implements current set of core interfaces.
> 
> In-memory Net Implementation: Implements current set of core interfaces.
> 
> Ozone Core Implementation: Implements current set of core interfaces. 0.6.0 
> implementation is currently NOT backwards compatible with 0.5.0 databases.
> 
> Ozone Net Implementation: Implements current set of net interfaces.
> 
> DOM Core implementation: ???
> 
> DOM Net Implementation: ???
> 
> TMNav application: Not updated. TheBrain is no longer freely available. 
> Propose removal from main TM4J release.
> 
> Command-line applications: Compile under the new interfaces, but need some 
> changes to make the source code clearer for newbies.
> 
> Florian, could you let me know what the state of the DOM implementation is ?
> 
> There are a number of issues to discuss in this list, which I will put in 
> separate threads.
> 
> Cheers,
> 
> Kal
> 
> 
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers


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

Re: [Tm4j-developers] Regarding the Filter to remove the Default Topics

[<tec...@te...>]

I'll have a go at creating this filter today and let you know when I've checked it in to the source tree.

Cheers,

Kal

--------------------------------------------------------
"gautham kasinath" <gka...@re...> wrote:
>
>Hi! Kal! 
>Well I still havent broken thru the removal of the three default topics that are created if I type a subtopic to a main topic. 
>Please send me a woking, complete example source code, since I dont have much time now to experiment.:( 
>Wish you all a very happy new year!! 
>Regds
>Lupo 
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>

[Tm4j-developers] Regarding the Filter to remove the Default Topics

[gautham k. <gka...@re...>]

Hi! Kal! =0D=0AWell I still havent broken thru the removal of the three def=
ault topics that are created if I type a subtopic to a main topic. =0D=0APl=
ease send me a woking, complete example source code, since I dont have much=
 time now to experiment.:( =0D=0AWish you all a very happy new year!! =0D=
=0ARegds=0D=0ALupo =0A

Re [Tm4j-developers] TMNav status

[gautham k. <gka...@re...>]

I vote +1 for this proposal of removing TMNav from the TM4J and putting it =
up as a seperate project.=0D=0ARegds=0D=0ALupo=0D=0A=0D=0AOn Sat, 05 Jan 20=
02 Kal Ahmed wrote :=0D=0A> Hi again!=0D=0A> =0D=0A> I would just like to e=
xplain why I am proposing to =0D=0A> remove TMNav from the =0D=0A> main TM4=
J distribution. Basically, it is my feeling =0D=0A> that the application =
=0D=0A> needs a complete ground-up rewrite - this is quite a =0D=0A> big ta=
sk and I don't =0D=0A> want to hold up releases of TM4J while this happens.=
 =0D=0A> Reasons for needing a =0D=0A> rewrite include=0D=0A> =0D=0A> 1) Th=
e major changes to the TM4J API mean that some =0D=0A> things in TMNav coul=
d =0D=0A> be done more efficiently=0D=0A> 2) TMNav never supported multiple=
 backends=0D=0A> 3) TheBrain SDK is no longer freely downloadable, so a =0D=
=0A> new visualisation is =0D=0A> needed=0D=0A> 4) The interfaces of TMNav =
need reworking to support =0D=0A> pluggable UI elements.=0D=0A> =0D=0A> How=
 do you all feel about making TMNav a separate =0D=0A> project ? It could s=
till =0D=0A> be hosted under the TM4J SourceForge project but should =0D=0A=
> probably have its =0D=0A> own CVS module and its own separate release pac=
kages.=0D=0A> =0D=0A> Cheers,=0D=0A> =0D=0A> Kal=0D=0A> =0D=0A> =0D=0A> ___=
____________________________________________=0D=0A> Tm4j-developers mailing=
 list=0D=0A> Tm4...@li...=0D=0A> https://lists.sou=
rceforge.net/lists/listinfo/tm4j-develo-=0D=0A> pers=0D=0A =0A

[Tm4j-developers] TMNav status

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

Hi again!

I would just like to explain why I am proposing to remove TMNav from the 
main TM4J distribution. Basically, it is my feeling that the application 
needs a complete ground-up rewrite - this is quite a big task and I don't 
want to hold up releases of TM4J while this happens. Reasons for needing a 
rewrite include

1) The major changes to the TM4J API mean that some things in TMNav could 
be done more efficiently
2) TMNav never supported multiple backends
3) TheBrain SDK is no longer freely downloadable, so a new visualisation is 
needed
4) The interfaces of TMNav need reworking to support pluggable UI elements.

How do you all feel about making TMNav a separate project ? It could still 
be hosted under the TM4J SourceForge project but should probably have its 
own CVS module and its own separate release packages.

Cheers,

Kal

[Tm4j-developers] TopicMapProvider and TopicMapFactory

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

Hi,

This is to explain some quite significant changes made to the 
TopicMapProvider and TopicMapFactory interfaces.

The TopicMapFactory interface is essentially tied to a particular topic 
map. For example, the semantics of createTopic() are that a Topic object is 
created and added to a TopicMap object (this should also be the semantics 
of createAssociation(), BTW). The TopicMap object is provided to the 
TopicMapFactory by one of the following methods:
a) Provided at creation of the TopicMapFactory object
b) Provided by a setTopicMap() method on the factory
c) Created by a call to TopicMapFactory.createTopicMap()

Additionally, when a new TopicMap is created, it must be registered with 
the Provider (typically by calling addTopicMap()).

My feeling is that, especially in dealing with persistent stores such as 
Ozone, this could be simplified, and I have had a go at doing this. What I 
propose is that:

a) TopicMapFactory.createTopicMap() is deprecated / removed
b) Instead, TopicMap objects are created by the TopicMapProvider by calling 
createTopicMap()

All other objects are still created by the TopicMapFactory interface which 
may itself be retrieved by calling TopicMap.getFactory().

Comments ?

Cheers,

Kal

[Tm4j-developers] 0.6.0 Release Status

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

Hi all and Happy New Year !

You may have noticed a big batch of CVS check-ins just prior to New Year. 
Most of it was to do with bringing the Ozone implementation up to the new 
core interfaces. In the course of doing that I found that it made sense to 
change one or two other interfaces too.

Now, it has been quite a while since the last release of source and binary 
distributions and I am considering an 0.6.0 release to be made over the 
next couple of weeks. What I would like to know from everyone involved in 
development is what the state of their subsystems are. Here is my list:

Core Interfaces: Many updates from 0.5.0 completed. Need a final review of 
the way in which TopicMapProvider and TopicMapFactory interact

Net Interfaces: Basic interfaces complete. Ready for release

In-memory Core Implementation: Implements current set of core interfaces.

In-memory Net Implementation: Implements current set of core interfaces.

Ozone Core Implementation: Implements current set of core interfaces. 0.6.0 
implementation is currently NOT backwards compatible with 0.5.0 databases.

Ozone Net Implementation: Implements current set of net interfaces.

DOM Core implementation: ???

DOM Net Implementation: ???

TMNav application: Not updated. TheBrain is no longer freely available. 
Propose removal from main TM4J release.

Command-line applications: Compile under the new interfaces, but need some 
changes to make the source code clearer for newbies.

Florian, could you let me know what the state of the DOM implementation is ?

There are a number of issues to discuss in this list, which I will put in 
separate threads.

Cheers,

Kal