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

[Tm4j-developers] [ tm4j-Bugs-1077865 ] Association.createAssociationRole (null, type);

[SourceForge.net <no...@so...>]

Bugs item #1077865, was opened at 2004-12-02 20:11
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1077865&group_id=27895

Category: In-Memory Impl
Group: TM4J 0.9.7
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Tryfon (gtryfon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Association.createAssociationRole (null, type);

Initial Comment:
the call:
      AssociationRole createAssociationRole(Topic player, 
Topic type) 


if gets player!=null, type!=null works fine

if gets player==null, type!=null
returns AssociationRole!=null
but there is a problem

in details:
Associatin a
AssociationRole ar = a.createAssociationRole (null, t);

ar.getAssociation().getAssociationRoles().size()  ( does 
not increase )

and also: ar.getAssociation() != a 
while: ar.getAssociation().getObjectId() is EQUAL with 
a.getObjectId()


I thing there is a similar problem with (player!=null, 
type==null)

cheers
George


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1077865&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1077865 ] Association.createAssociationRole (null, type);

[SourceForge.net <no...@so...>]

Bugs item #1077865, was opened at 2004-12-02 22:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1077865&group_id=27895

Category: In-Memory Impl
Group: TM4J 0.9.7
Status: Open
Resolution: None
Priority: 5
Submitted By: George Tryfon (gtryfon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Association.createAssociationRole (null, type);

Initial Comment:
the call:
      AssociationRole createAssociationRole(Topic player, 
Topic type) 


if gets player!=null, type!=null works fine

if gets player==null, type!=null
returns AssociationRole!=null
but there is a problem

in details:
Associatin a
AssociationRole ar = a.createAssociationRole (null, t);

ar.getAssociation().getAssociationRoles().size()  ( does 
not increase )

and also: ar.getAssociation() != a 
while: ar.getAssociation().getObjectId() is EQUAL with 
a.getObjectId()


I thing there is a similar problem with (player!=null, 
type==null)

cheers
George


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1077865&group_id=27895

Re: [Tm4j-developers] Can Locators be removed?

[Lars M. G. <la...@on...>]

* Khalil Ahmed
| 
| Can you add a bug report to the tracker for this please ?

For the record: we just removed the concept of locators from TMDM (at
the Washington DC meeting), in favour of typed strings. (Ie: there's
one type for strings, and another for URIs, and potentially a third
one for people wanting HyTime locators.) If this has any effect on
this you may want to reconsider.

Slides from the meeting with rationale in them will be posted shortly.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

RE: [Tm4j-developers] Locator.resolveRelative() behaviour

[Andy P. <an...@il...>]

Hi Kal,

> the leading slash on /abc/123 causes the behaviour you see. You would 
> get http://stuff/home/abc/123 by resolving abc/123 against the base 
> locator.

Thanks, I misread the example in http://www.w3.org/TR/xmlbase/ spec... 


Andy.

Re: [Tm4j-developers] Locator.resolveRelative() behaviour

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

Hi Andy,

the leading slash on /abc/123 causes the behaviour you see. You would 
get http://stuff/home/abc/123 by resolving abc/123 against the base 
locator.

Cheers,

Kal

On 11 Nov 2004, at 12:57, Andy Peel wrote:

> Hi,
>
> I may be expecting the wrong thing here, but I have a topic map with a 
> base
> locator of http://stuff/home/ and an occurrence in that map with a 
> locator
> of /abc/123.
>
> I have some code that looks like this:
>
> 	String relativeURL = occurrence.getResource().toExternalForm();
> 	String occurrenceURL =
> map.getBaseLocator().resolveRelative(relativeURL).toExternalForm();
>
> I was expecting to get http://stuff/home/abc/123 but I got
> http://stuff/abc/123. In other words, the resolution process is 
> ignoring the
> "home/" on the end of the base URL.
>
> Is this correct?
>
> Thanks,
>
>
> Andy.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>
>

[Tm4j-developers] Locator.resolveRelative() behaviour

[Andy P. <an...@il...>]

Hi,

I may be expecting the wrong thing here, but I have a topic map with a base
locator of http://stuff/home/ and an occurrence in that map with a locator
of /abc/123.

I have some code that looks like this:

	String relativeURL = occurrence.getResource().toExternalForm();
	String occurrenceURL =
map.getBaseLocator().resolveRelative(relativeURL).toExternalForm();

I was expecting to get http://stuff/home/abc/123 but I got
http://stuff/abc/123. In other words, the resolution process is ignoring the
"home/" on the end of the base URL.

Is this correct?

Thanks,


Andy.

[Tm4j-developers] [ tm4j-Bugs-1063104 ] Unused locators aren't removed

[SourceForge.net <no...@so...>]

Bugs item #1063104, was opened at 2004-11-09 13:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1063104&group_id=27895

Category: Locators
Group: TM4J 0.9.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Andy Peel (atpeel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unused locators aren't removed

Initial Comment:
I have a topic map for which I've changed the base
locator using:

	org.tm4j.topicmap.TopicMap.setBaseLocator(Locator base)

However, this leaves a row in the locator table (I'm
using Hibernate) for the old locator.

Kal says that the problem is that locators can be used
in more than one context  and there's no cleanup of
unused locators:

> the data model allows a locator to be referenced as
the value of an 
> occurrence, as a subject indicator, a subject
address, a source locator 
> or a topic map base locator and potentially there
could be other 
> references to the same object.


In my case I'd be happy to remove the old base locator
as I know it's no longer used, although there's no API
method to do this.

Another possible solution might be to change the data
model so that locators aren't shared, though I don't
know what downside there might be to this.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1063104&group_id=27895

Re: [Tm4j-developers] Can Locators be removed?

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

Hi Andy,

Currently the code doesn't clean up unused locators. The issue is that 
the data model allows a locator to be referenced as the value of an 
occurrence, as a subject indicator, a subject address, a source locator 
or a topic map base locator and potentially there could be other 
references to the same object. I guess I could add code to check if a 
locator is unused and remove it from the database in that case. This 
would potentially slow down some property changes (if it requires an 
additional lookup to check if the removed/modified locator is now 
unused) but it might be beneficial in topic maps with a high rate of 
churn (e.g. new topics being regularly imported and then destroyed).

Can you add a bug report to the tracker for this please ?

Cheers,

Kal

On 9 Nov 2004, at 06:51, Andy Peel wrote:

> Hello,
>
> I have a topic map for which I've changed the base locator using:
>
> 	org.tm4j.topicmap.TopicMap.setBaseLocator(Locator base)
>
> However, this leaves a row in the locator table (I'm using Hibernate) 
> for
> the old locator.
>
> Is there a way to remove the old locator?
>
> Thanks,
>
>
> Andy.
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>
>

[Tm4j-developers] Can Locators be removed?

[Andy P. <an...@il...>]

Hello,

I have a topic map for which I've changed the base locator using:

	org.tm4j.topicmap.TopicMap.setBaseLocator(Locator base)

However, this leaves a row in the locator table (I'm using Hibernate) for
the old locator.

Is there a way to remove the old locator?

Thanks,


Andy.

[Tm4j-developers] [ tm4j-Bugs-1062461 ] Topic.setSubjectIndicators() problem

[SourceForge.net <no...@so...>]

Bugs item #1062461, was opened at 2004-11-08 17:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1062461&group_id=27895

Category: In-Memory Impl
Group: TM4J 0.9.7
Status: Open
Resolution: None
Priority: 5
Submitted By: George Tryfon (gtryfon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Topic.setSubjectIndicators() problem

Initial Comment:
the Topic.setSubjectIndicators()
does not seems to work when the Topic does 
not "already contain" anySubject Indicators

if Topic already contains Subject Indicators, the 
Topic.setSubjectIndicators() works ok.

(the Topic.addSubjectIndicator() works OK)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1062461&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1058822 ] Deleting "Topic Type" does not throw Exception

[SourceForge.net <no...@so...>]

Bugs item #1058822, was opened at 2004-11-02 13:55
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1058822&group_id=27895

Category: In-Memory Impl
Group: TM4J 0.9.1
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: George Tryfon (gtryfon)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Deleting "Topic Type" does not throw Exception

Initial Comment:
when I delete a "Topic" that is a "Topic Type" or another 
Topic, I don't get exception.
The Deleteion completed.
The "other Topic" faces problems with i'ts "Types"

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-11-02 14:50

Message:
Logged In: YES 
user_id=176992

Hibernate backend is not affected by this bug. The bug is
now fixed for all backends.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-11-02 14:46

Message:
Logged In: YES 
user_id=176992

Fixed for Ozone and in-memory backends. Need to validate and
test against hibernate backend.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-11-02 14:28

Message:
Logged In: YES 
user_id=176992

Created a test that reproduces this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1058822&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1058822 ] Deleting "Topic Type" does not throw Exception

[SourceForge.net <no...@so...>]

Bugs item #1058822, was opened at 2004-11-02 13:55
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1058822&group_id=27895

Category: In-Memory Impl
Group: TM4J 0.9.1
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: George Tryfon (gtryfon)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Deleting "Topic Type" does not throw Exception

Initial Comment:
when I delete a "Topic" that is a "Topic Type" or another 
Topic, I don't get exception.
The Deleteion completed.
The "other Topic" faces problems with i'ts "Types"

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-11-02 14:46

Message:
Logged In: YES 
user_id=176992

Fixed for Ozone and in-memory backends. Need to validate and
test against hibernate backend.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-11-02 14:28

Message:
Logged In: YES 
user_id=176992

Created a test that reproduces this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1058822&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1058822 ] Deleting "Topic Type" does not throw Exception

[SourceForge.net <no...@so...>]

Bugs item #1058822, was opened at 2004-11-02 13:55
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1058822&group_id=27895

Category: In-Memory Impl
Group: TM4J 0.9.1
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: George Tryfon (gtryfon)
>Assigned to: Kal Ahmed (kal_ahmed)
Summary: Deleting "Topic Type" does not throw Exception

Initial Comment:
when I delete a "Topic" that is a "Topic Type" or another 
Topic, I don't get exception.
The Deleteion completed.
The "other Topic" faces problems with i'ts "Types"

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-11-02 14:28

Message:
Logged In: YES 
user_id=176992

Created a test that reproduces this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1058822&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1058822 ] Deleting "Topic Type" does not throw Exception

[SourceForge.net <no...@so...>]

Bugs item #1058822, was opened at 2004-11-02 15:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1058822&group_id=27895

Category: In-Memory Impl
Group: TM4J 0.9.1
Status: Open
Resolution: None
Priority: 5
Submitted By: George Tryfon (gtryfon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deleting "Topic Type" does not throw Exception

Initial Comment:
when I delete a "Topic" that is a "Topic Type" or another 
Topic, I don't get exception.
The Deleteion completed.
The "other Topic" faces problems with i'ts "Types"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1058822&group_id=27895

Fw: [Tm4j-developers] Concretizer

[George T. <geo...@fr...>]

Hello Harald

>I had a look at your atop projects code. As far as I could see, you seem to
use JDK 1.5 ?!

This started when I wanted to play a bit with Generics

>How are your development plans ? Are you still planning to use panckoucke ?

I don't have exactly "Time schedule", but I hope it will be usefull (the
program) within some months


>I also saw that you sended an email to the tm4j list on Oktober 5th which
> nobody seemed to have answered.
>The reasons for this is probably that I had to hand in my diploma thesis
> some days afterwards and christoph
>was on holiday without Internet computer).

I didn't know why the people did not answer, and I was wandering what
happened to panckoucke.
and also because I neaded some engine as soon as possible, I eventualy
decited and replaced panckoucke with a small "engine" (that I write) that
handles "Topic Maps specifically" using TM4J.
My engine has nodes and arcs (inspired from panckoucke), but changing these
nodes, the "topc map" underneeth changes. Also they can "refresh". I need
also listeners handling and such a kind of things.
My focus for the final project, remains a "customizable" "Topic Map" editor.

>Your suggestion to change the Node implementation so that it derives the
> Lable on its own would probably
>imporve TopicMap handling. However, there are some major drawbacks to this
>approach. The whole model
>implementation (as it is now and will probably be in the future) is only a
>data structure without any generation
>logic. These logic is seperated into the abstractors. Changes this would
> increase the complexity and would
>reduce the reusability of the code.

Maybe you could point from the AMMember into the Abstractor that created
this AMMember.
And so when you need "Topic Map Handling", the AMMember could call it's own
creator Abstractor,
when you need RDF handling, the RDF specific Abstractor could be called.
Could this work?


The next is more like phylosophical question:
Do you thing that Panckoucke could ever have "user rights" handling ?

Cheers
Giorgos

> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.773 / Virus Database: 520 - Release Date: 5/10/2004
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.773 / Virus Database: 520 - Release Date: 5/10/2004


____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.

Re: [Tm4j-developers] Fonts in the tmnav touchgraph renderer

[Christoph F. <cf...@fo...>]

Hi Conal


Am Do, den 14.10.2004 schrieb Conal Tuohy um 4:05:
> I've got another little quibble with the UI of TMNav. I'd like to set
> the font for the topic objects in the TouchGraph rendering. At the
> moment on my system it appears as a fixed-width font and so long
> pieces of text (e.g. subject indicators) are too long, and get
> truncated. :-(
> 
> It looks like the TMOTouchgraphNode is responsible, and I think by
> implementing a getFont method or similar I could specify the font. I
> think the font itself should be taken from
> org.tm4j.tmnav.envTMAppearance, which already specifies a few fonts,
> namely:
> 
> "plainFont" which is returned by the getListFont() method,
> "boldFont" which appears to be unused?
> "popupMenuFont" which has get/set accessors
> 
> I think "plainFont" would be suitable for TouchGraph nodes. I haven't
> written anything just yet, but does this sound reasonable?
> 

Basically, I think, there should be a default font, that is used
tmnav-wide every time a font is needed and no font is specified in a
more narrow context.

This font should be accessible through a new method
TMAppearance.getDefaultFont() and should be configurable in
.tmnav/tmnav-defaults.xml just as the font used for popup menues already
is.

If this sounds reasonable, I would be able to implement it in the next
development release which should be published sometimes in the next two
weaks.


If this takes too long for you, and you want to make a quick change by
yourself, I would suggest to call setFont(the
_Font_you_want_to_use)-Method in TMOTouchgraphNode(String, String). This
would set the font of com.touchgraph.graphlayout.Node which is used for
rendering the labels in the TouchgraphRenderer.
 
Is this passable for you?

c

> Con
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Christoph Froehlich <cf...@fo...>

[Tm4j-developers] Fonts in the tmnav touchgraph renderer

[Conal T. <Con...@vu...>]

I've got another little quibble with the UI of TMNav. I'd like to set =
the font for the topic objects in the TouchGraph rendering. At the =
moment on my system it appears as a fixed-width font and so long pieces =
of text (e.g. subject indicators) are too long, and get truncated. :-(

It looks like the TMOTouchgraphNode is responsible, and I think by =
implementing a getFont method or similar I could specify the font. I =
think the font itself should be taken from =
org.tm4j.tmnav.envTMAppearance, which already specifies a few fonts, =
namely:

"plainFont" which is returned by the getListFont() method,
"boldFont" which appears to be unused?
"popupMenuFont" which has get/set accessors

I think "plainFont" would be suitable for TouchGraph nodes. I haven't =
written anything just yet, but does this sound reasonable?

Con

[Tm4j-developers] [ tm4j-Bugs-1042523 ] No default factory.props file

[SourceForge.net <no...@so...>]

Bugs item #1042523, was opened at 2004-10-07 21:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1042523&group_id=27895

Category: Distribution Files
Group: TM4Web/Velocity 0.2rc1
Status: Open
Resolution: None
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: No default factory.props file

Initial Comment:
TM4Web/Velocity looks for a file factory.props when it
runs. No factory.props file is included in the
distribution. A skeleton/sample factory.props file
should be included in the distro to:
a) prevent the error message appearing
b) serve as an example for customising factory.props

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1042523&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1041958 ] TMNav: UI tweak to free memory indicator

[SourceForge.net <no...@so...>]

Bugs item #1041958, was opened at 2004-10-07 16:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1041958&group_id=27895

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Conal Tuohy (conal_tuohy)
Assigned to: Nobody/Anonymous (nobody)
Summary: TMNav: UI tweak to free memory indicator

Initial Comment:
Just adds the words "free" and "total" to the free
memory indicator in TMNav.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1041958&group_id=27895

[Tm4j-developers] Panckoucke

[George T. <geo...@fr...>]

Hello Panckoucke developers
I would like to share some thoughts I have.

I am thinking of an AModel implementation witch:

instead of calls like:
AMNode createNode(String label,Object RepresentedObject,AMGestalt
gestalt);

should have calls like:
public AMNode createNode(Object representedObject,AMGestalt gestalt);

the AMNode should derive the "label" from the representedObject

also:
I thing that the AMNode could have closer relation to the Abstractor that
came from
(It could be customized by the Abstractor) and so:
Adding or removing AMNode(s) or AMArc(s) into a specific AMMember,
if this AMMember knows the architecture that represents, could call
Abstractor and change the "Topic Map" itself

There is another big advandage, if we are able to return from the AModel
into the Abstractor.

We could "Refresh" our AModel and make it "Up to date" with the "Topic Map",
if Topic Map changes.

And ofcource could implement listeners that listen changes in Topic Map in
inform the AModel, or AMMember

Cheers
Giorgos

ps.
because I don't see any public discussions, on Panckoucke development,
I would like to ask you about your "time schedule" for Panckoucke.
Our editor "ATop" is now "Open source" in sourceforge (no binaries yet),
ready to implement editing of Topic Maps, and I am eager to see Panckoucke
moving




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.767 / Virus Database: 514 - Release Date: 21/9/2004


____________________________________________________________________
http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου.
http://www.freemail.gr - free email service for the Greek-speaking.

[Tm4j-developers] [ tm4j-Bugs-1035301 ] SerializedTopicMapSource ignoring xml:base

[SourceForge.net <no...@so...>]

Bugs item #1035301, was opened at 2004-09-27 08:31
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035301&group_id=27895

Category: Import/Export
Group: TM4J 0.9.6
Status: Open
>Resolution: Postponed
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: SerializedTopicMapSource ignoring xml:base

Initial Comment:
When reading an XTM file using
SerializedTopicMapSource, it appears that the value of
an xml:base attribute on the document root element is
not being assigned to the topic map.

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-10-05 08:48

Message:
Logged In: YES 
user_id=176992

No response from the ISO WG, so I am going to postpone work
on this bug until after the 0.9.7 release.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-27 17:00

Message:
Logged In: YES 
user_id=176992

Update:

Up to now TM4J has used the xml:base attribute only for
resolving references to other documents. Same-document
reference (#foo) and element IDs are resolved against the
source locator of the topic map file being read. This is (I
believe) in line with the original position of the ISO
committee. However, RDF does it a different way and resolves
RDF:ID attributes and same-document references against the
xml:base value - and in a lot of ways that makes more sense.

I've put a query about this in to the ISO working group.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035301&group_id=27895

Re: [Tm4j-developers] Panckoucke again

[Christoph F. <cf...@fo...>]

Hi Giorgios

I would vote for writing a new implementation of the AMMember-Interface
that supports dynamic changes. I expect that the label wont remain the
the sole property that becomes editable...)

c

Am Sa, den 02.10.2004 schrieb George Tryfon um 15:26:
> Hello,
>=20
> the "label" in AMNodeImpl works like this:
>=20
> class AMNodeImpl
> {
>    String label;
>=20
>   AMNodeImpl (String id, String label)
>   {
>     this.label =3D label;
>     ...
>   }
>   public String getLabel()
>   {
>      return label;
>   }
> }
>=20
> when Concretizer (the class that makes the changes) needs to change a lab=
el,
> the AMMember needs to be reconstructed, and so the AModel.
>=20
> I would prefer to avoid this and suggest for the label to became dynamic,
> like:
>=20
>   public String getLabel()
>   {
>     return ...calculate label...;
>   }
>=20
> We could implement a new set of AMMember with dynamic label
> (that supports Concretizer)
>=20
> Of cource we could easily, just use a setLabel(String),
> and Concretizer could call it,
> (I would prefer the dynamic one).
>=20
> What is your opinion?
>=20
> Cheers
> Giorgos
>=20
>=20
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.767 / Virus Database: 514 - Release Date: 21/9/2004
>=20
>=20
> ____________________________________________________________________
> http://www.freemail.gr - =CE=B4=CF=89=CF=81=CE=B5=CE=AC=CE=BD =CF=85=CF=
=80=CE=B7=CF=81=CE=B5=CF=83=CE=AF=CE=B1 =CE=B7=CE=BB=CE=B5=CE=BA=CF=84=CF=
=81=CE=BF=CE=BD=CE=B9=CE=BA=CE=BF=CF=8D =CF=84=CE=B1=CF=87=CF=85=CE=B4=CF=
=81=CE=BF=CE=BC=CE=B5=CE=AF=CE=BF=CF=85.
> http://www.freemail.gr - free email service for the Greek-speaking.
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out mo=
re
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
--=20
Christoph Froehlich <cf...@fo...>

[Tm4j-developers] Panckoucke again

[George T. <geo...@fr...>]

Hello,

the "label" in AMNodeImpl works like this:

class AMNodeImpl
{
   String label;

  AMNodeImpl (String id, String label)
  {
    this.label = label;
    ...
  }
  public String getLabel()
  {
     return label;
  }
}

when Concretizer (the class that makes the changes) needs to change a label,
the AMMember needs to be reconstructed, and so the AModel.

I would prefer to avoid this and suggest for the label to became dynamic,
like:

  public String getLabel()
  {
    return ...calculate label...;
  }

We could implement a new set of AMMember with dynamic label
(that supports Concretizer)

Of cource we could easily, just use a setLabel(String),
and Concretizer could call it,
(I would prefer the dynamic one).

What is your opinion?

Cheers
Giorgos


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.767 / Virus Database: 514 - Release Date: 21/9/2004


____________________________________________________________________
http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου.
http://www.freemail.gr - free email service for the Greek-speaking.

[Tm4j-developers] [PATCH] Implementing org.tm4j.topicmap.memory.TopicMapUtilsImpl.getObjectsInScope method

[Conal T. <Con...@vu...>]

I had a need for this method so I implemented it. It is more or less a =
copy of the hibernate implementation.=20

BTW There are still a few other helper methods in that class which are =
implemented only as stubs that return null.

The patch is in Unified Diff format.

Cheers

Con

Re: [Tm4j-developers] Concretizer

[Harald K. <har...@we...>]

Hi George,

>Hello,

>I am posting you how I am thinking to go with "Concretizer"
>You can see the attacked Concretizer.java
>
>Do you thing that something like this is OK?

I do not know exactly what the changes you made to the Concretizer Interface are for. However i fear that you did not completely understand the concept of a Concretizer. The idea behind a concretizer was, do edit panckouckes abstract model and afterwards use the concretizer to synchronize these changes back into the original data structure (which at the moment is a TopicMap).

>Because I understend that Panckoucke is going to have a major
>reconstruction, I feel hesitated on developing, before relative discussions.

>This that I don't know is, if you you feel that "Concretizer" should be able
>to edit RDF together with "Topic Maps" and should have some common API for
>all of these technologies.

Actually the Concretizer will not be able to directly edit TopicMaps or RDF but rather as already said above, is used to transfer those changes from the abstract Model into the TopicMap or RDF.
So the way a cocretizer will work is somewhat like this:

1. An Abstractor creates a AbstractModel from a DataStructure
2. The user changes these AbstractModel to meet his / her demands
3. The Concretizer processes the AbstractModel and transfers the changes made inside the model back into the TopicMap ( and later on  RDF or whatever).

>Thank you very much
>Giorgos

The actual editing must be done inside a panckoucke application (e.g. TMNav) and is preferably done by using forms.

Hope this helps to clearify everything.

Cheers
Harald
____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist 
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200