Menu
▾
▴
tm4j-developers — Forum for issues related to development of TM4J.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(26) |
Jul
(22) |
Aug
(31) |
Sep
(25) |
Oct
(9) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(50) |
Feb
(51) |
Mar
(6) |
Apr
(10) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(11) |
| 2003 |
Jan
(8) |
Feb
(21) |
Mar
(2) |
Apr
(29) |
May
(9) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(3) |
Oct
(21) |
Nov
(40) |
Dec
(14) |
| 2004 |
Jan
(32) |
Feb
(30) |
Mar
(24) |
Apr
(13) |
May
(25) |
Jun
(14) |
Jul
(9) |
Aug
(21) |
Sep
(52) |
Oct
(9) |
Nov
(12) |
Dec
(6) |
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
(14) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2006 |
Jan
|
Feb
(16) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(9) |
Dec
(2) |
| 2007 |
Jan
(2) |
Feb
(9) |
Mar
(1) |
Apr
(38) |
May
(7) |
Jun
(7) |
Jul
(12) |
Aug
(10) |
Sep
(10) |
Oct
(3) |
Nov
(7) |
Dec
(7) |
| 2008 |
Jan
(13) |
Feb
(12) |
Mar
(53) |
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Kal A. <ka...@te...> - 2002-12-13 15:59:52
|
Oops - itchy "Send" finger. What I meant to add was: I'm now in the process of going through the rest of the code base and upd= ating=20 it so as to remove any uses of the deprecated methods.=20 The createXXX() methods now throw an IntegrityViolationException if the p= arent=20 object is not from the same topic map as the factory you are using to cre= ate=20 the child object. I propose that a similar restriction be placed on the=20 addXXX methods such as Topic.addOccurrence() to trap such potential error= s. Cheers, Kal On Friday 13 December 2002 16:16, Kal Ahmed wrote: > Just to let you all know, the changes have now been checked into CVS. > > Cheers, > > Kal > > On Thursday 12 December 2002 16:20, Kal Ahmed wrote: > > Folks, > > > > Further to Ren=E9's comments, I am now considering refactoring > > TopicMapFactory so that all createXXX() methods require the parent ob= ject > > of the new object to be specified. This would mean that all the old > > createXXX() methods would be deprecated in 0.8.0 and removed in the > > following release. > > > > The alternative is to hold off on this change until after 0.8.0. So t= he > > question is, would you prefer to get an 0.8.0 release now or get one = with > > these API changes made in a little while (maybe another week...might = make > > a nice Xmas present ;-) > > > > At first I was reluctant to make the change for 0.8.0, but I'm now > > thinking that the change should be made now, so unless I hear voices > > raised against this course of action, I will start to make those chan= ges > > from tomorrow. > > > > Cheers, > > > > Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-12-13 15:49:13
|
Just to let you all know, the changes have now been checked into CVS. Cheers, Kal On Thursday 12 December 2002 16:20, Kal Ahmed wrote: > Folks, > > Further to Ren=E9's comments, I am now considering refactoring > TopicMapFactory so that all createXXX() methods require the parent obje= ct > of the new object to be specified. This would mean that all the old > createXXX() methods would be deprecated in 0.8.0 and removed in the > following release. > > The alternative is to hold off on this change until after 0.8.0. So the > question is, would you prefer to get an 0.8.0 release now or get one wi= th > these API changes made in a little while (maybe another week...might ma= ke a > nice Xmas present ;-) > > At first I was reluctant to make the change for 0.8.0, but I'm now thin= king > that the change should be made now, so unless I hear voices raised agai= nst > this course of action, I will start to make those changes from tomorrow= =2E > > Cheers, > > Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-12-12 15:54:55
|
Folks, Further to Ren=E9's comments, I am now considering refactoring TopicMapFa= ctory=20 so that all createXXX() methods require the parent object of the new obje= ct=20 to be specified. This would mean that all the old createXXX() methods wou= ld=20 be deprecated in 0.8.0 and removed in the following release. The alternative is to hold off on this change until after 0.8.0. So the=20 question is, would you prefer to get an 0.8.0 release now or get one with= =20 these API changes made in a little while (maybe another week...might make= a=20 nice Xmas present ;-) At first I was reluctant to make the change for 0.8.0, but I'm now thinki= ng=20 that the change should be made now, so unless I hear voices raised agains= t=20 this course of action, I will start to make those changes from tomorrow. Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-12-12 15:50:07
|
On Thursday 12 December 2002 15:31, Ren...@da... wrote=
:
> Hello again,
>
> I just saw that there is no protection against adding the same Topic to=
two
> different TopicMaps anyway:
>
> this.vosTopicMap =3D tmProvider.createTopicMap(vosTopicMapLocator);
> this.superClasses =3D tmProvider.createTopicMap(superClassesLocator);
> superClasses.addTopic(vosTopicMap.getFactory().createTopic("foobar"));
>
That was true in 0.7.x - although TopicMap.addTopic() has been deprecated=
for=20
quite a while now. In 0.8.0, that method is finally removed (I left some =
time=20
before removing it to allow people a chance to update their code).
> Ok - you might say if such things happen it is the fault of of the
> developer using your API. But I am really a little bit confused. If I w=
ant
> to create a Topic I use the specific TopicMapFactory and it is added
> automatically to its parent. But if I want to create a BaseName for my
> Topic I have to add it myself. And all the time I have to be very caref=
ul
> of not using the wrong TopicMapFactory because i could make my whole mo=
del
> inconsistent:
Yes, my next proposed big set of changes to the API would be to make the=20
construction/containment model more closely aligned to TMAPI, that means =
that=20
at the least I would make all TopicMapFactory methods require that the pa=
rent=20
of the created object be specified (so createBaseName(String) becomes=20
createBaseName(Topic, String)) or to go all the way along the TMAPI path =
and=20
remove the Factory class entirely and replace it with createXXX() methods=
on=20
the parent object (so TopicMapFactory.createBaseName() becomes=20
Topic.createBaseName())
>
> superClassesTopic.addBaseName(vosTopicMap.getFactory().createBaseName(.=
=2E.))
>;
>
> I prefer two solution:
>
> 1.)=09From a TopicMapProvider I can get a TopicMapObjectBuilder / Facto=
ry
> which belongs to a specific backend implementation. With the
> TopicMapObjectBuilder I can create any TopicMapObjects.
>
> =09a.)=09These TopicMapObjects could be added to their parent
> automatically by giving the wanted parent in a parameter:
>
> =09=09TopicMapObjectBuilder builder =3D
> myProvider.getTopicMapObjectBuilder();
> =09=09// When creating TopicMap I dont have to say where it should be
> added when dealing with a TopicMapObjectBuilder tied to a single
> TopicMapProvider
> =09=09TopicMap myTopicMap =3D builder.createTopicMap(locator);
> =09=09Topic myTopic =3D builder.createTopic(id1, myTopicMap);
> =09=09builder.createTopic(id2, myTopicMap);
> =09=09builder.createBasename("bla", myTopic);
> =09=09.... and so on
>
> =09b.)=09Or manually by the attaching idea I described in my last
> email. If a TopicMap Object is created I tell it to attach itself to a
> TopicMapObject which acts as a container.
> =09=09If it is already child of a parent and only it deregisters
> there and registers at a new parent. And a TopicMapObject can be the ch=
ild
> of only one parent with this strategy.
>
> =09=09TopicMapObjectFactory factory =3D
> myProvider.getTopicMapObjectFactory();
> =09=09// When creating TopicMap I dont have to say where it should be
> attach itself when dealing with a TopicMapObjectFactory tied to a singl=
e
> TopicMapProvider
> =09=09TopicMap myTopicMap =3D factory.createTopicMap(locator);
> =09=09Topic myTopic =3D factory.createTopic(id1);
> =09=09mytopic.attach(myTopicMap);
> =09=09factory.createTopic(id2).attach(myTopicMap)
> =09=09factory.createBasename("bla").attach(myTopic);
> =09=09myTopic.detach();
> =09=09.... and so on
>
These are good suggestions. 1b is very much like the original TM4J API - =
which=20
I eventually found got too confusing. 1a is a good idea though.
>
> 2.)=09There could be a factory tied to a single TopicMap which is calle=
d
> TopicMapBuilder. But if it is tied to a specific TopicMap it should add
> TopicMapObjects to it while creating them. Not only
> =09Topics and Associations but also all other elements. This would make
> the whole creating process more consistent.
>
> =09TopicMapProvider provider =3D .....
> =09TopicMap myTopicMap =3D provider.createTopicMap(...);
> =09TopicMapBuilder builder =3D myTopicMap.getFactory();
> =09// When creating with Topic I dont have to say where it should be ad=
ded
> when dealing with a TopicMapElementFactory tied to a single TopicMap
> =09Topic myTopic =3D builder.createTopic(id1);
> =09builder.createTopic(id2);
> =09// But I have to do when creating a BaseName
> =09builder.createBaseName("bla", myTopic);
>
> =09A manually attaching version is senseless here I think.
I agree.
>
> All in all I would say that solution 1b is the most flexible one while =
1a
> or 2a are more comfortable.
> Finally I want to say that I do not declare my ideas to be the right on=
es.
> Maybe I have forgotten to include some aspects into my considerations.?
>
The only other model I have seen is the TMAPI model where the "factory"=20
methods are found on the parent objects (e.g. Topic.createOccurrence()).
My preference at the moment is to implement 2b properly. Probably making =
those=20
changes for 0.9.0 so that the new Factory methods are implemented in 0.9.=
0=20
and the old methods are deprecated in that version - then the old methods=
can=20
be removed before 0.10.0 (or 1.0 even...lets think positively!)
How does that sound ?
Cheers,
Kal=20
PS - I'm kind of ruling out doing this for 0.8.0 as I am almost ready to =
go=20
with an 0.8.0a1 release. But if people prefer to get this nailed down now=
,=20
I'm happy to hold off until the implementation is done.=20
--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy
e: ka...@te...
p: +44 7968 529531
w: www.techquila.com
|
|
From: Kal A. <ka...@te...> - 2002-12-12 13:28:21
|
On Thursday 12 December 2002 11:48, mo...@gm... wrote: > Hi again, > > > 1) It goes against the standard topic map containment model. Every to= pic > > map API I > > > have worked with has a containment model in which topics, association= s > > and all the other topic map objects are contained in one and only one > > topic map. > > I understand the fact why you do not want a Topic to be an element of t= wo > different TopicMaps. But there are other ways to ensure, I think. I do = not > like the fact that if a TopicMapObject is created it is automatically p= ut > on a TopicMap. I just saw that a TopicMapObject like an Association or = a > Topic already know their parent. One could use that aspect to ensure th= at a > specific TopicMapObject has only one parent. > > You could say Topic.attach(TopicMap). If there is already a parent, the > Topic would deregister there and register at the TopicMap given as a > parameter. Moreover it would save the new TopicMap as its parent. If yo= u > want to have a "stand-alone-Topic" again, you could say Topic.detach(). > > The benefit I see is that you can create single containers and componen= ts > (can be containers as well) which you can put together and apart the wa= y u > need it. It would be similar to Java-Swing-Components. At the moment I > would need something like a "CacheTopicMap" to hold Topics I do not nee= d > right at the moment in a specific map. At the same time you could retai= n > the feature, that there is only one container for an TopicMapObject. > I can see the advantages of that approach, and it was the reason why I ha= d=20 originally structured the API in that way. However, the detach()/attach()= =20 methods would be somewhat more complex than you suggest as they would hav= e to=20 deal with objects contained by the Topic object and objects referenced by= the=20 Topic object. Using the mechanism of a "cache" or "scratchpad" topic map and then using= =20 TopicMapFactory.copy() methods, you can approximate this behaviour as you= =20 have already suggested. > > For example, under > > TM4J's dynamic merging model, your code could lead to myTopic being > > merged > > > > with one topic from myTopicMap1 and one from myTopicMap2, but I think= it > > would be messy if the API getMergedTopics() had to take a TopicMap as= a > > parameter or if it returned a set of topics from different topic maps= =2E > > This problem would not remain any longer if you can be sure that there = is > only one container for an TopicMapObject. > Thats true. I cannot argue that there are not advantages to structuring the API as yo= u=20 suggest. As is often the case, there are two equally good ways of approac= hing=20 this, each with strengths and weaknesses depending upon your application.= =20 Refactoring the code to support the structure you suggest is not a trivia= l=20 operation (especially as it would have knock-on effects on the different=20 implementations and on the relational database schema). So I would have t= o be=20 convinced by a show-stopper problem to change it at this stage...or by a = lot=20 of people shouting at me ;-) > I will also have a look at other TopicMapAPIs to see what the ideas the= re > were. Maybe you could tell me 1 or 2 you are refering to. But I still t= hink > TM4J is the best solution for our project and i am looking forward to y= our > next releases. > I am thinking of the TMAPI API (which TM4J also supports) -=20 http://www.tmapi.org/ and the Ontopia OKS API (I don't think that the API= =20 documentation is public for that though). > By the way: Shell i write such discussions in the public mailing list o= r do > you want me to write directly to you email address? > Lets keep discussing this, but on the tm4j-dev mailing list - that is the= best=20 place to discuss API issues I think; and it would be good to have some=20 thoughts from anyone else interested in this area. I have posted this rep= ly=20 to that list. Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-11-11 10:02:34
|
This is a warning to anyone using the latest CVS code. I have been making= a=20 few interface changes recently, but one in particular may cause problems=20 unless you are aware of it. Up until now, the relationship between a TopicMapFactory object and a Top= icMap=20 object has been a little badly defined. I have now fixed that so that eac= h=20 TopicMap object must have its own TopicMapFactory object, that is returne= d by=20 calling the getFactory() method on the TopicMap object. This change means that the getFactory() method on the TopicMapProvider=20 interface is now deprecated. The in-memory backend has been changed to re= turn=20 null from this method - so any code relying on this method will break. Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-11-04 18:03:07
|
Hi, I've just checked in the first set of files for a new back-end for TM4J. = This=20 back-end persists topic map data in an RDBMS using JDBC and an O-R mappin= g=20 tool called Hibernate [1]. The files checked in consist of the implementation of the basic topic map= =20 objects and factories. There are some methods of these classes that are n= ot=20 yet implemented and object deletion is not yet implemented. In addition, = the=20 indexes and index manager are not yet implemented either. If you want to play with this back-end, you will need to create a=20 build.properties file (in the top-level TM4J directory) with the followin= g=20 properties set: tm4j.jdbc.driver=3D[ full class name of the JDBC driver to use ] tm4j.jdbc.database=3D[ JDBC connection URL for the database to use ] tm4j.jdbc.username=3D[ User name for connection to the database ] tm4j.jdbc.password=3D[ Password for connection to the database ] The target hibernate.compile compiles the source - the database connectio= n=20 details are not needed for this step The target hibernate.install-mappings copies the XML O-R mapping files=20 (*.hbm.xml) to the classes directory so that they can be found by the=20 application at run-time. The target hibernate.initdb will create the necessary tables and views in= the=20 target database. If invoked again on the same database, the existing tabl= es=20 and views get dropped - so take care!!=20 The target hibernate.test runs a set of unit tests which cover most of wh= at=20 has been implemented so far. Note that the target hibernate.test always=20 invokes hibernate.initdb (to ensure that the database starts from a clean= =20 state), so keep the test database separate from any data you care about. ** IMPORTANT MESSAGE ** There are no guaruntees that the database schema will not have to change=20 between now and release 0.8.0, so don't commit any important data to this= =20 back-end. ** END IMPORTANT MESSAGE ** I have yet to do any perf. or scalability testing on this back-end. If an= yone=20 would like to do so, I would be very interested to hear the results. Cheers, Kal [1] http://hibernate.sourceforge.net/ --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Christoph <cf...@fo...> - 2002-10-21 12:16:44
|
Hi We are glad to announce the first alpha-release of TMNav. The goal of the TMNav project is to provide an intuitive graphical interface for Topic Map navigation and editing. This release of TMNav supports only the navigation of topic maps, editing facilities will be added in later releases. TMNav is a subproject of TM4J, the Java Open Source Topic Map toolkit (see http://www.tm4j.org) You may download the release via tm4js sourceforge - page (http://sourceforge.net/project/showfiles.php?group_id=27895) For comments, questions etc please contact Christoph Froehlich mailto:cf...@fo... or Niko Schmuck mailto:ni...@na... We will be happy to hear from you Christoph and Niko |
|
From: Christoph <cf...@fo...> - 2002-09-19 07:01:12
|
Hi all, Finally we are back on tmnav development. Yesterday I checked a first bunch of interfaces into the repository, which constitute a draft proposal for the core-library of tmnav. As Kal pointed out recently, one of the design goals of tmnav is the development of a general module which may be 'hosted' by different applications like i.e. NetBeans, Eclipse and for sure tmnav itself. We decided to call this module "panckoucke". Panckoucke was the second publisher of Diderots encyclopedia. His edition was relatively cheap, and was an enormous success. While Diderot developed a structure how knowledge could be represented in a modern medium (the book), Panckoucke gave people access to that knowledge. We thought this might be a good name, although Mr. Panckoucke wasn't that kind of guy you want to meet alone by night. The panckoucke package is divided into two parts, the core and the implementation. The core provides a description of the flow of a topic map object through an abstraction process into a application- specific renderer. Furthermore a simple event model is included to close the basic panckoucke circle, which may be read like this: abstraction - renderer - selection - abstraction - renderer - ... The implementation will be a basic one, and is intended to work in several hosting applications. Supplying the implementation will facilitate porting the module to different hosts. At least we hope so. I'm talking of we all the time because I'm glad to introduce a new contributor to tmnav, Niko Schmuck, who took active part on this design proposal. Please keep in mind, that panckoucke is in a very early state of development and open for contributions from everybody. We would be glad to hear from you, what you think about these proposals, and any further contribution is highly welcome. We will start with the implementation over the next weeks and we hope to have a first alpha of panckoucke and tmnav by the end of October. bye Christoph |
|
From: Kal A. <ka...@te...> - 2002-09-02 17:08:36
|
Hi All, Just to let you all know, I have just checked in a change which has an im= pact=20 on the way topic maps are created. Basically, I wanted to rationalise the= way=20 that LocatorFactory objects are created and used. You will now find that = the=20 TopicMapFactoryImpl and TopicMapImpl objects in the org.tm4j.topicmap.mem= ory=20 package require a LocatorFactory object to be passed to their constructor= s.=20 This may break some of your existing code if you create these objects=20 directly (if you use the "proper" way of creating a TopicMapProviderFacto= ry,=20 then there should be no changes needed). Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-08-12 20:41:58
|
Hi all, Just to let you know, I have now updated the TMAPI bindings to the latest= =20 TMAPI interface specifications (the 1.0 draft API). I have rerun all the=20 existing unit tests which all pass, but there are still some areas of the= =20 bindings not yet tested. If anyone uses the TMAPI bindings and finds a=20 problem with them, please report a bug. Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-07-26 10:32:51
|
Hi all, I propose to remove all methods deprecated prior to 0.7.0 in release 0.8.= 0.=20 This means that anything marked as deprecated from 0.7.0 on will remain i= n=20 0.8.0 but anything deprecated in 0.6.x or before will go. I think that gi= ving=20 a minimum 1 release leeway is enough. However, I won't do this right away= =2E So=20 if anyone has any major objections to this, please let me know ASAP. Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-07-26 10:31:11
|
Hi all, I've created a new branch with the name rel-0-7-x. This branch should be = used=20 for 0.7.0 bug-fix releases only. Hopefully, if SourceForge's FTP server c= omes=20 back up today, I will be making an 0.7.1 release. Meanwhile, we can now start on 0.8.0 changes in the CVS HEAD, Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-07-25 09:06:34
|
On Wednesday 24 July 2002 12:10, Christoph Fr=F6hlich wrote: > Hi kal > > this is a nice idea, using topic maps to keep the summary of a topic ma= p. > It sounds very charmig to me, though I have no clue, how to get there. > Perhaps you can share the name of the speaker. Maybe there is a paper > anywhere available for download? > The paper was written by Benedicte Le Grand and presented at XML 2001. Yo= u can=20 get a copy of the paper from=20 http://www.idealliance.org/papers/xml2001/papers/html/04-04-05.html > Nevertheless it seems to me, that we are talking of two related but > initially different things, using the same term "summarization". > > As I understand you, "summarization" enables us to control *what* > elements are displayed, while I put the focus on *how* they are > displayed. > > An example: An association may be displayed in a lot of different ways. > You may draw nodes and arcs for every element which is part - in an > underlying xtm-syntax - of that association. > Or you may draw something which ressembles more a shortcut and what > puts the focus on what the author might intended to express. > For the sake of clarification I produced two gifs, visualizing the > association "verdi is the composer of la traviata". > (Since I am unsure, if it's okay to attach gifs on this list, I put > them on my site > http://www.folge2.de/img/tmnav/latraviata1.gif > http://www.folge2.de/img/tmnav/latraviata2.gif > ) > Ah I understand now. What you call 'summarization', I would call 'abstrac= tion'=20 - you are creating an abstract representation of the topic map informatio= n=20 (in this case for the purposes of visualisation). I used such an approach= in=20 putting together the templates for generating the TM4J.org website - by=20 clustering together all associations of a specific type in which a given=20 topic plays a given role (e.g. find all the parent-child associations in=20 which this topic plays the role of parent). By creating an abstraction fo= r=20 this cluster of associations, it made development of the presentation lay= er=20 alot easier. I agree with you that having a collection of such abstractio= ns=20 would be very useful for visualisation technologies. I have been recently= =20 looking at a more functional approach to topic map processing which would= =20 allow small functional components to be connected together programmatical= ly=20 to create transformers and filters for topic map information. I think tha= t=20 these could be used to create a general toolkit of topic map processing=20 functionality on which visualisation abstractions could be built.=20 So I would see the stack as something like the following (you'll need a=20 fixed-width font for the ascii art...) +-------------------------+ | GUI Application | +-------------------------+ | TMNav APIs | | | | | and Components | | | | +----------------+ | | | | Visualisation | | | | Abstractions | | | +-------------------+ | | | General TM Tools | | +----------------------+ | | TM4J Core APIs | +-------------------------+ > Both visualisations are - to me - completly legal and useful in > particular contexts. Please note, that "latraviata1" is still far > away from being a > one to one representation of xtm-syntax. For example, labeling the node= s > "verdi" and "la traviata" may be the result of some rather complex > decisions. > > So my point is: > Computing the underlying model for a concrete visualisation should be > done in the library and the results should be usable for all > implementations. Yes! > It would be great, to have an api, which takes a topicmap-element > and a level-of-detail as input and returns a visualisation-independent > model. This model must be translated in order to use it with a concret= e > visualisation-toolkit. > I would like to also give application writers the freedom to pick and cho= ose=20 how the topic map model is abstracted for them too. It would certainly be= =20 good to have the high-level abstractions, but those should be built on a=20 (documented and accessible) toolkit of lower level functions with which=20 application writers can create their own abstractions. > I think, TopicMap - Summarization as you described it is an important > point,and I would be glad, if we manage to include it in TMNav. But > it's not what I meant when I used the term "summarization". > Furthermore it seems to me, that we should use "summarization" in the > future in the way you've used it. > Perhaps anybody has a proposal for a good term for the task: > "computing a generic visualisation-centered model" > Well, "abstraction" is a bit shorter ;-) > I hope, I managed to clarify some things with this mail. > You did indeed and I hope that I have understood you correctly now! Cheers, Kal > regards > christoph > > >On Thursday 18 July 2002 09:16, Christoph Fr=F6hlich wrote: > >> Hi kal, > >> > >> thanks for your analysis, with wich I agree completely > >> > >> I was busy over the last weeks and this will last until end of july= , > >> but in august I will find some time to proceed developing tmnav. I > >> would be glad to contribute to [5: lib] and since I am becoming an > >> eclipse addict, I would like to work on [3: Eclipse plugin] > > > >That would be great ! If we try and develop the stand-alone app and th= e > > two plugins in parallel with the lib, we should get a good spread of > > requirements for the library and have a good chance of making somethi= ng > > truly reusable. > > > >> When working on the prototype I stopped at a point, where two major > >> task arose. Since these tasks live at the very core of [5:lib], I wi= ll > >> briefly mention them. > >> > >> Firstly: > >> [5:lib] should support visualisation in different levels-of-detai= l. > >> A very detailed level may show everything down to the single > >> xml-elements, while a higher-level approach would summarize > >> information and provide something which resembles more an overview. > >> We talked about this before. > >> > >> I will call this process the "summarization". > >> > >> Summarization may leed to a model, where particular elements do not > >> necessarily correspond directly to TopicMapElements. In fact some > >> summarization-Elements will represent collections of topicMap > >> Elements while other may symbolise constructs which are not even > >> contained in the underlying map. > >> (Summarization will always be an interpretation, which may include > >> the wish to add helper constructs) > >> > >> So secondly, we need a model > >> - which is the result of the summarisation-process and > >> - which has a very loose binding to the TopicMap-Model > >> - which is flexible enough to represent different degrees of > >> visualisation and - which is implementation independant. > >> I think, this will lead us to some abstract graph-model. So far so > >> good. > >> > >> But now it's getting diffcult. > >> There comes a time when we want the user to be able to interact wit= h > >> our app. Perhaps he wants to delete the relation "all operas" from > >> "composer verdi". > >> > >> This means we must traverse the Summarization model back to the > >> TopicMap-Model, in order to identify all TopicMap-Elements which ar= e > >> affected by this operation. This is something like de-summarisatio= n. > >> It would be easy for isolated tasks, like deleting. But we need a > >> more general approach, in order to enable developpers of using > >> [5:lib] in a way, that we haven't had in mind, when implementing > >> [5:lib]. > >> This sounds difficult to me. > > > >I too can see the need for topic map summarization, but I think that t= he > > topic map structures can be used to do this. I am thinking that you c= ould > > use the summarization method to turn a big topic map (with all of its > > detail) into a smaller topic map (where connections between topics ar= e > > some sort of generic "is-related-to" association). The smaller topic = map > > could use subject indicators which point to the resourceLocator addre= sses > > of the topics in the detailed topic map. If a topic is a summary of a > > group of topics, then it could either use subject indicators or perha= ps > > occurrences to point to all of the topics that it summarizes. I saw a > > great presentation at XML 2001 on a method for statistical analysis o= f > > topic maps to do this sort of > >summarization work - the method could even be applied repeatedly to cr= eate > > a summary of a summary and so on...this gave the ability to generate > > multiple "scales" of navigation which the user could zooom in and out= of. > > Its a really cool idea - although a bit computationally expensive, so= it > > might be the kind of thing that you preprocess (and then store all of= the > > different levels of view as separate topic maps). > > > >To me, keeping the summary in topic map form makes a lot of sense - th= at > > way we can use the same navigation code and present the same > > look-and-feel to the end user regardless of the level at which he/she= is > > navigating the topic map. > > > >And is anybody up for doing the 3D-fly-throught version ? ;-) > > > >> Puh. Sorry, if this kind of discussion is a bit off topic on this l= ist. > > > >Not at all - topic map summarization is a great thing for us to discus= s on > >this list. If anyone has any ideas or pointers to other statistical > > methods that could be applied, please share them! > > > >> What I wanted to say is I would like to contribute to tmnav. > > > >YAY! You will be most welcome to! > > > >Cheers, > > > >Kal > > > > > > > >------------------------------------------------------- > >This sf.net email is sponsored by:ThinkGeek > >Welcome to geek heaven. > >http://thinkgeek.com/sf > >_______________________________________________ > >Tm4j-developers mailing list > >Tm4...@li... > >https://lists.sourceforge.net/lists/listinfo/tm4j-developers > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Oscar <le...@wz...> - 2002-07-25 09:00:39
|
suscribe |
|
From: Christoph <cf...@fo...> - 2002-07-24 12:10:57
|
Hi kal this is a nice idea, using topic maps to keep the summary of a topic map. It sounds very charmig to me, though I have no clue, how to get there. Perhaps you can share the name of the speaker. Maybe there is a paper anywhere available for download? Nevertheless it seems to me, that we are talking of two related but initially different things, using the same term "summarization". As I understand you, "summarization" enables us to control *what* elements are displayed, while I put the focus on *how* they are displayed. An example: An association may be displayed in a lot of different ways. You may draw nodes and arcs for every element which is part - in an underlyi= ng xtm-syntax - of that association. Or you may draw something which ressembles more a shortcut and what puts the focus on what the author might intended to express. =46or the sake of clarification I produced two gifs, visualizing the association "verdi is the composer of la traviata". (Since I am unsure, if it's okay to attach gifs on this list, I put them on my site http://www.folge2.de/img/tmnav/latraviata1.gif http://www.folge2.de/img/tmnav/latraviata2.gif ) Both visualisations are - to me - completly legal and useful in particular contexts. Please note, that "latraviata1" is still far away from being a one to one representation of xtm-syntax. For example, labeling the nodes "verdi" and "la traviata" may be the result of some rather complex decisions= =2E So my point is: Computing the underlying model for a concrete visualisation should be done in the library and the results should be usable for all implementations. It would be great, to have an api, which takes a topicmap-element and a level-of-detail as input and returns a visualisation-independent model= =2E This model must be translated in order to use it with a concrete visualisation-toolkit. I think, TopicMap - Summarization as you described it is an important point,and I would be glad, if we manage to include it in TMNav. But it's not what I meant when I used the term "summarization". =46urthermore it seems to me, that we should use "summarization" in the future in the way you've used it. Perhaps anybody has a proposal for a good term for the task: "computing a generic visualisation-centered model" I hope, I managed to clarify some things with this mail. regards christoph >On Thursday 18 July 2002 09:16, Christoph Fr=F6hlich wrote: >> Hi kal, >> >> thanks for your analysis, with wich I agree completely >> >> I was busy over the last weeks and this will last until end of july, >> but in august I will find some time to proceed developing tmnav. I >> would be glad to contribute to [5: lib] and since I am becoming an >> eclipse addict, I would like to work on [3: Eclipse plugin] >> > >That would be great ! If we try and develop the stand-alone app and the two >plugins in parallel with the lib, we should get a good spread of requiremen= ts >for the library and have a good chance of making something truly reusable. > >> When working on the prototype I stopped at a point, where two major task >> arose. Since these tasks live at the very core of [5:lib], I will briefl= y >> mention them. >> >> Firstly: >> [5:lib] should support visualisation in different levels-of-detail. >> A very detailed level may show everything down to the single >> xml-elements, while a higher-level approach would summarize >> information and provide something which resembles more an overview. >> We talked about this before. >> >> I will call this process the "summarization". >> >> Summarization may leed to a model, where particular elements do not >> necessarily correspond directly to TopicMapElements. In fact some >> summarization-Elements will represent collections of topicMap >> Elements while other may symbolise constructs which are not even >> contained in the underlying map. >> (Summarization will always be an interpretation, which may include >> the wish to add helper constructs) >> >> So secondly, we need a model >> - which is the result of the summarisation-process and >> - which has a very loose binding to the TopicMap-Model >> - which is flexible enough to represent different degrees of visualisati= on >> and - which is implementation independant. >> I think, this will lead us to some abstract graph-model. So far so good. >> >> But now it's getting diffcult. >> There comes a time when we want the user to be able to interact with our >> app. Perhaps he wants to delete the relation "all operas" from "composer >> verdi". >> >> This means we must traverse the Summarization model back to the >> TopicMap-Model, in order to identify all TopicMap-Elements which are >> affected by this operation. This is something like de-summarisation. >> It would be easy for isolated tasks, like deleting. But we need a >> more general approach, in order to enable developpers of using >> [5:lib] in a way, that we haven't had in mind, when implementing >> [5:lib]. >> This sounds difficult to me. >> > >I too can see the need for topic map summarization, but I think that the to= pic >map structures can be used to do this. I am thinking that you could use the >summarization method to turn a big topic map (with all of its detail) into = a >smaller topic map (where connections between topics are some sort of generi= c >"is-related-to" association). The smaller topic map could use subject >indicators which point to the resourceLocator addresses of the topics in th= e >detailed topic map. If a topic is a summary of a group of topics, then it >could either use subject indicators or perhaps occurrences to point to all = of >the topics that it summarizes. I saw a great presentation at XML 2001 on a >method for statistical analysis of topic maps to do this sort of >summarization work - the method could even be applied repeatedly to create = a >summary of a summary and so on...this gave the ability to generate multiple >"scales" of navigation which the user could zooom in and out of. Its a real= ly >cool idea - although a bit computationally expensive, so it might be the ki= nd >of thing that you preprocess (and then store all of the different levels of >view as separate topic maps). > >To me, keeping the summary in topic map form makes a lot of sense - that wa= y >we can use the same navigation code and present the same look-and-feel to t= he >end user regardless of the level at which he/she is navigating the topic ma= p. > >And is anybody up for doing the 3D-fly-throught version ? ;-) > >> >> Puh. Sorry, if this kind of discussion is a bit off topic on this list. >> > >Not at all - topic map summarization is a great thing for us to discuss on >this list. If anyone has any ideas or pointers to other statistical methods >that could be applied, please share them! > >> What I wanted to say is I would like to contribute to tmnav. >> > >YAY! You will be most welcome to! > >Cheers, > >Kal > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Tm4j-developers mailing list >Tm4...@li... >https://lists.sourceforge.net/lists/listinfo/tm4j-developers |
|
From: Kal A. <ka...@te...> - 2002-07-18 19:31:32
|
On Thursday 18 July 2002 09:16, Christoph Fr=F6hlich wrote: > Hi kal, > > thanks for your analysis, with wich I agree completely > > I was busy over the last weeks and this will last until end of july, > but in august I will find some time to proceed developing tmnav. I > would be glad to contribute to [5: lib] and since I am becoming an > eclipse addict, I would like to work on [3: Eclipse plugin] > That would be great ! If we try and develop the stand-alone app and the t= wo=20 plugins in parallel with the lib, we should get a good spread of requirem= ents=20 for the library and have a good chance of making something truly reusable= =2E > When working on the prototype I stopped at a point, where two major tas= k > arose. Since these tasks live at the very core of [5:lib], I will brief= ly > mention them. > > Firstly: > [5:lib] should support visualisation in different levels-of-detail. > A very detailed level may show everything down to the single > xml-elements, while a higher-level approach would summarize > information and provide something which resembles more an overview. > We talked about this before. > > I will call this process the "summarization". > > Summarization may leed to a model, where particular elements do not > necessarily correspond directly to TopicMapElements. In fact some > summarization-Elements will represent collections of topicMap > Elements while other may symbolise constructs which are not even > contained in the underlying map. > (Summarization will always be an interpretation, which may include > the wish to add helper constructs) > > So secondly, we need a model > - which is the result of the summarisation-process and > - which has a very loose binding to the TopicMap-Model > - which is flexible enough to represent different degrees of visualisat= ion > and - which is implementation independant. > I think, this will lead us to some abstract graph-model. So far so good= =2E > > But now it's getting diffcult. > There comes a time when we want the user to be able to interact with ou= r > app. Perhaps he wants to delete the relation "all operas" from "compose= r > verdi". > > This means we must traverse the Summarization model back to the > TopicMap-Model, in order to identify all TopicMap-Elements which are > affected by this operation. This is something like de-summarisation. > It would be easy for isolated tasks, like deleting. But we need a > more general approach, in order to enable developpers of using > [5:lib] in a way, that we haven't had in mind, when implementing > [5:lib]. > This sounds difficult to me. > I too can see the need for topic map summarization, but I think that the = topic=20 map structures can be used to do this. I am thinking that you could use t= he=20 summarization method to turn a big topic map (with all of its detail) int= o a=20 smaller topic map (where connections between topics are some sort of gene= ric=20 "is-related-to" association). The smaller topic map could use subject=20 indicators which point to the resourceLocator addresses of the topics in = the=20 detailed topic map. If a topic is a summary of a group of topics, then it= =20 could either use subject indicators or perhaps occurrences to point to al= l of=20 the topics that it summarizes. I saw a great presentation at XML 2001 on = a=20 method for statistical analysis of topic maps to do this sort of=20 summarization work - the method could even be applied repeatedly to creat= e a=20 summary of a summary and so on...this gave the ability to generate multip= le=20 "scales" of navigation which the user could zooom in and out of. Its a re= ally=20 cool idea - although a bit computationally expensive, so it might be the = kind=20 of thing that you preprocess (and then store all of the different levels = of=20 view as separate topic maps).=20 To me, keeping the summary in topic map form makes a lot of sense - that = way=20 we can use the same navigation code and present the same look-and-feel to= the=20 end user regardless of the level at which he/she is navigating the topic = map. And is anybody up for doing the 3D-fly-throught version ? ;-) > > Puh. Sorry, if this kind of discussion is a bit off topic on this list. > Not at all - topic map summarization is a great thing for us to discuss o= n=20 this list. If anyone has any ideas or pointers to other statistical metho= ds=20 that could be applied, please share them! > What I wanted to say is I would like to contribute to tmnav. > YAY! You will be most welcome to! Cheers, Kal |
|
From: Christoph <cf...@fo...> - 2002-07-18 09:16:18
|
Hi kal, thanks for your analysis, with wich I agree completely I was busy over the last weeks and this will last until end of july, but in august I will find some time to proceed developing tmnav. I would be glad to contribute to [5: lib] and since I am becoming an eclipse addict, I would like to work on [3: Eclipse plugin] When working on the prototype I stopped at a point, where two major task arose. Since these tasks live at the very core of [5:lib], I will briefly mention them. Firstly: [5:lib] should support visualisation in different levels-of-detail. A very detailed level may show everything down to the single xml-elements, while a higher-level approach would summarize information and provide something which resembles more an overview. We talked about this before. I will call this process the "summarization". Summarization may leed to a model, where particular elements do not necessarily correspond directly to TopicMapElements. In fact some summarization-Elements will represent collections of topicMap Elements while other may symbolise constructs which are not even contained in the underlying map. (Summarization will always be an interpretation, which may include the wish to add helper constructs) So secondly, we need a model - which is the result of the summarisation-process and - which has a very loose binding to the TopicMap-Model - which is flexible enough to represent different degrees of visualisation and - which is implementation independant. I think, this will lead us to some abstract graph-model. So far so good. But now it's getting diffcult. There comes a time when we want the user to be able to interact with our app. Perhaps he wants to delete the relation "all operas" from "composer verdi". This means we must traverse the Summarization model back to the TopicMap-Model, in order to identify all TopicMap-Elements which are affected by this operation. This is something like de-summarisation. It would be easy for isolated tasks, like deleting. But we need a more general approach, in order to enable developpers of using [5:lib] in a way, that we haven't had in mind, when implementing [5:lib]. This sounds difficult to me. Puh. Sorry, if this kind of discussion is a bit off topic on this list. What I wanted to say is I would like to contribute to tmnav. But now back to work regards christoph ps: you aked me before, under which license eclipe is published. It is the "CPL", the "Common Public License". Do yo know, what that license says? >Hi all, > >I've been playing with Cristoph's excellent prototype application and thinking >about the general approaches we could take to TMNav. In one conversation, >someone (Cristoph ?) mentioned Eclipse[1] as an example of the kind of IDE >framework within which TMNav could be built. I have taken a look at both >Eclipse and NetBeans[2] and I can see the attraction in making TMNav a >plug-in to one of these. Firstly there is alot of standard IDE stuff that >these frameworks give you "for free" enabling us to concentrate on building >cool, user-friendly visualisations and topic map editing capabilities. >Secondly, there is a userbase for these tools already and those users will >have less trouble getting started with a new plugin than having to learn a >new application (and its IDE paradigm) from scratch. Thirdly, some of these >frameworks might already have tools which we could hook in to (e.g. an XML >editing plugin for viewing topic map source). > >However, there are some downsides to building a plugin. Firstly, which ever >IDE you choose, you will neglect those who use the other one. Secondly, these >IDEs are quite "heavy" - both in terms of size (big downloads) and complexity >(take a fair bit of getting used to) - this makes them less than ideal for a >novice user only interested in topic maps. Thirdly, integrating with a single >IDE is limiting - a tight integration could prevent components of the TMNav >plugin being repurposed. > >In fact, I think that TMNav should be all of the following: > >1) A stand-alone java application >2) A servlet-based web app (possibly using java applets) >3) A plugin for Eclipse >4) A plugin for NetBeans >5) A software library of reusable components for displaying and editing topic >map data. > >It is (5) that I think enables (1) - (4). So what I am proposing is that we >start work on a TMNav framework. I have some rough ideas about how this might >be done which I am trying out with a simple example of doing (1) and (4) >using the same visualisation components. However, I would definitely be >interested to here the thoughts of others on this. > >Cheers, > >Kal > >[1] http://www.eclipse.org/ >[2] http://www.netbeans.org/ > >-- >Kal Ahmed, techquila.com >XML and Topic Map Consultancy > >e: ka...@te... >p: +44 7968 529531 >w: www.techquila.com > > > >------------------------------------------------------- >This sf.net email is sponsored by: Jabber - The world's fastest growing >real-time communications platform! Don't just IM. Build it in! >http://www.jabber.com/osdn/xim >_______________________________________________ >Tm4j-developers mailing list >Tm4...@li... >https://lists.sourceforge.net/lists/listinfo/tm4j-developers |
|
From: Kal A. <ka...@te...> - 2002-07-16 19:01:06
|
Hi all, I've been playing with Cristoph's excellent prototype application and thi= nking=20 about the general approaches we could take to TMNav. In one conversation,= =20 someone (Cristoph ?) mentioned Eclipse[1] as an example of the kind of ID= E=20 framework within which TMNav could be built. I have taken a look at both=20 Eclipse and NetBeans[2] and I can see the attraction in making TMNav a=20 plug-in to one of these. Firstly there is alot of standard IDE stuff that= =20 these frameworks give you "for free" enabling us to concentrate on buildi= ng=20 cool, user-friendly visualisations and topic map editing capabilities.=20 Secondly, there is a userbase for these tools already and those users wil= l=20 have less trouble getting started with a new plugin than having to learn = a=20 new application (and its IDE paradigm) from scratch. Thirdly, some of the= se=20 frameworks might already have tools which we could hook in to (e.g. an XM= L=20 editing plugin for viewing topic map source).=20 However, there are some downsides to building a plugin. Firstly, which ev= er=20 IDE you choose, you will neglect those who use the other one. Secondly, t= hese=20 IDEs are quite "heavy" - both in terms of size (big downloads) and comple= xity=20 (take a fair bit of getting used to) - this makes them less than ideal fo= r a=20 novice user only interested in topic maps. Thirdly, integrating with a si= ngle=20 IDE is limiting - a tight integration could prevent components of the TMN= av=20 plugin being repurposed. In fact, I think that TMNav should be all of the following: 1) A stand-alone java application 2) A servlet-based web app (possibly using java applets) 3) A plugin for Eclipse 4) A plugin for NetBeans 5) A software library of reusable components for displaying and editing t= opic=20 map data. It is (5) that I think enables (1) - (4). So what I am proposing is that = we=20 start work on a TMNav framework. I have some rough ideas about how this m= ight=20 be done which I am trying out with a simple example of doing (1) and (4)=20 using the same visualisation components. However, I would definitely be=20 interested to here the thoughts of others on this. Cheers, Kal [1] http://www.eclipse.org/ [2] http://www.netbeans.org/ --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-07-07 19:13:27
|
Hi all, Unless I hear any objection, I am going to cut the 0.7.0 final release=20 tomorrow evening (8th July, probably some time after 5pm UK time). So, if= you=20 have any changes that you want to get checked in before 0.7.0 final, plea= se=20 raise the alarm now! Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-06-17 08:56:36
|
On Tuesday 11 June 2002 14:11, Kal Ahmed wrote: > On Monday 10 June 2002 06:00, Florian G. Haas wrote: > > Hello, > > > > On Friday 07 June 2002 16:40, Kal Ahmed wrote: > > | This lack of source URL is a big hole in the InputStream interface > > | IMHO. But given that we can't change that (unless anyone knows a > > | developer in the Java team ;-), then I think that there needs to be > > | some default rules for assigning a URL to the stream. I propose tha= t : > > | > > | 1) each file can be assigned a base url with a parameter following = the > > | file name: > > | org.tm4j.topicmap.cmd.Merge -o output.xtm foo.xtm -baseurl > > | http://www.mysite.com/tms/foo.xtm bar.xtm -baseurl > > | http://www.mysite.com/tms/bar.xtm > > | This has the advantage that I can use local copies of the files for= the > > | merge process yet still have them treated as if they originated fro= m > > | the online sources. > > > > Good idea, but it can't be done using JArgs (as far as I know). So we > > would throw out much of the flexibility we've gained using JArgs by > > having to write our own parsing routine again. Or is there an alterna= tive > > to JArgs which does support the structure you propose? > > I'm not aware of any alternative to JArgs that might support this form = of > command-line. But can't we use JArgs to parse all the options before th= e > input file names and then parse the remaining ones (after all we are on= ly > looking for a (filename [-baseurl url])* pattern so it might not be to= o > hard to do... > The good news is that it doesn't seem to have been too hard to do ;-) I have checked in org.tm4j.topicmap.cmd.TopicMapList. If you pass this th= e=20 remainingArgs() method return after JArgs has parsed the command line, it= =20 will parse the remaining args as a list of topic map names with optional = base=20 URLs specified between them. The expected form is: (tmsource [ -b | --baseurl tmbase ] ) * where tmsource is a file name or URL that can be opened by the Java=20 URLConnection class and where tmbase is any valid URI string. The short c= ode=20 and long code for the option can be set when the TopicMapList class is=20 instantiated. > > | 2) if no base url is specified and the input source is specified on= the > > | command line generate the URL from the input file name, so "foo.xtm= " > > | would be resolved as a File then you can use File.toURL() to get a > > | locator for the input source. "http://someurl.com/foo.xtm" would fa= il > > | to resolve as a file, so you could convert that to a URL, get the > > | URLConnection for the source and use the URL itself as the base url > > | TopicMapList does this also. > > | 3) if no base url is specified and the input source comes from a pi= pe, > > | then use some default URL (could it be based on the current workin= g > > | directory ?) > > TopicMapList doesn't do this one yet. So if you use a pipe on the command= =20 line, you will have to provide a base URL. I've not actually tested this = yet=20 - and I imagine that TopicMapList may need some additional code to handle= =20 input from a pipe correctly. > > OK, but TopicMapProviderBase doesn't support any of that yet. It need= s an > > overloaded readTopicMap() method which accepts and InputStream and a > > String representing a system ID. > > I was thinking that the base url would be used to create a Locator obje= ct, > then we can use TopicMapProvider.addTopicMap(InputStream, Locator, > TopicMap). > TopicMapList returns a List of SourceAddressPair objects each of which=20 contains an InputStream and a Locator. So it should now be easy to match = up=20 the results of command line parsing with the TopicMapProvider interface. I haven't yet retrofitted this to the Merge or the Stats applications. Florian, would you like to add it in to the Merge app ? I think that the = Stats=20 app probably needs a complete rewrite along the same lines as Merge and m= aybe=20 I'll be able to get around to that today. Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-06-11 13:12:15
|
On Monday 10 June 2002 06:00, Florian G. Haas wrote: > Hello, > > On Friday 07 June 2002 16:40, Kal Ahmed wrote: > | This lack of source URL is a big hole in the InputStream interface IM= HO. > | But given that we can't change that (unless anyone knows a developer = in > | the Java team ;-), then I think that there needs to be some default r= ules > | for assigning a URL to the stream. I propose that : > | > | 1) each file can be assigned a base url with a parameter following th= e > | file name: > | org.tm4j.topicmap.cmd.Merge -o output.xtm foo.xtm -baseurl > | http://www.mysite.com/tms/foo.xtm bar.xtm -baseurl > | http://www.mysite.com/tms/bar.xtm > | This has the advantage that I can use local copies of the files for t= he > | merge process yet still have them treated as if they originated from = the > | online sources. > > Good idea, but it can't be done using JArgs (as far as I know). So we w= ould > throw out much of the flexibility we've gained using JArgs by having to > write our own parsing routine again. Or is there an alternative to JArg= s > which does support the structure you propose? > I'm not aware of any alternative to JArgs that might support this form of= =20 command-line. But can't we use JArgs to parse all the options before the=20 input file names and then parse the remaining ones (after all we are only= =20 looking for a (filename [-baseurl url])* pattern so it might not be too = hard=20 to do... > | 2) if no base url is specified and the input source is specified on t= he > | command line generate the URL from the input file name, so "foo.xtm" > | would be resolved as a File then you can use File.toURL() to get a > | locator for the input source. "http://someurl.com/foo.xtm" would fail= to > | resolve as a file, so you could convert that to a URL, get the > | URLConnection for the source and use the URL itself as the base url > | > | 3) if no base url is specified and the input source comes from a pipe= , > | then use some default URL (could it be based on the current working > | directory ?) > > OK, but TopicMapProviderBase doesn't support any of that yet. It needs = an > overloaded readTopicMap() method which accepts and InputStream and a St= ring > representing a system ID. > I was thinking that the base url would be used to create a Locator object= ,=20 then we can use TopicMapProvider.addTopicMap(InputStream, Locator, TopicM= ap). > Still, even if it's useless, I suggest that we at least drop Sun a note > that something like a URLConnectionInputStream is more than needed. We'= re > probably just a few out of thousands, but at least it's worth telling t= hem. > I guess that it wouldn't hurt to do that. Perhaps we all should ;-) Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Smith, T. <Tim...@ds...> - 2002-06-10 22:47:35
|
Thanks Kal :) (b) I shall - my bad, and I already have a test, just wanted to check I hadn't found a problem. Tim &-----Original Message----- &From: Kal Ahmed [mailto:ka...@te...] &Sent: Saturday, 8 June 2002 12:33 AM &To: Smith, Tim &Cc: tm4...@li... &Subject: Re: [Tm4j-developers] inScope & & &Hi Tim, & &The scope comparison is just on a set membership basis. i.e. &you will only &get a positive if there is an overlap between the topics in &the scope you &are testing against and the topics in the scope you are &testing with. The &comparison does not take account of class-instance or &subclass-superclass &relationships. While this is in line with the XTM &specification (and the &way that scope is used there), I think I can see why you might &want to use &a class-instance relationship (to say something like "if name &is scoped by &a language then...") - but to do that I think you will either have to &a) Create a myScope that contains all the instances of TopicB &b) Write your own test & &My guess is that in the general case, (b) is preferable to (a). & &Cheers, & &Kal & &At 16:55 07/06/2002 +1000, you wrote: &>Hi all, &>I think I am missing something, &>I used a &>Topic.getNames(), converted to get a group of BaseNames &>I then used baseNameArray[element].inScope(myScope) &>and did NOT get a true when myScope SHOULD (I think) have given one &>if the name is scoped by Topic B &>and TopicA is-a TopicB (class-instance) &>then if myScope is TopicA (remember name is scoped by TopicB) &>Shouldn't I get a positive? &>Sorry if this is overly confusing &>Tim Smith &> &> &> &>_______________________________________________________________ &> &>Don't miss the 2002 Sprint PCS Application Developer's Conference &>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm &> &>_______________________________________________ &>Tm4j-developers mailing list &>Tm4...@li... &>https://lists.sourceforge.net/lists/listinfo/tm4j-developers & & &_______________________________________________________________ & &Don't miss the 2002 Sprint PCS Application Developer's Conference &August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm & &_______________________________________________ &Tm4j-developers mailing list &Tm4...@li... &https://lists.sourceforge.net/lists/listinfo/tm4j-developers & |
|
From: Florian G. H. <fg...@bk...> - 2002-06-10 06:00:23
|
Hello, On Friday 07 June 2002 16:40, Kal Ahmed wrote: | This lack of source URL is a big hole in the InputStream interface IMHO= =2E | But given that we can't change that (unless anyone knows a developer in= the | Java team ;-), then I think that there needs to be some default rules f= or | assigning a URL to the stream. I propose that : | | 1) each file can be assigned a base url with a parameter following the = file | name: | org.tm4j.topicmap.cmd.Merge -o output.xtm foo.xtm -baseurl | http://www.mysite.com/tms/foo.xtm bar.xtm -baseurl | http://www.mysite.com/tms/bar.xtm | This has the advantage that I can use local copies of the files for the | merge process yet still have them treated as if they originated from th= e | online sources. Good idea, but it can't be done using JArgs (as far as I know). So we wou= ld=20 throw out much of the flexibility we've gained using JArgs by having to w= rite=20 our own parsing routine again. Or is there an alternative to JArgs which = does=20 support the structure you propose?=20 | 2) if no base url is specified and the input source is specified on the | command line generate the URL from the input file name, so "foo.xtm" wo= uld | be resolved as a File then you can use File.toURL() to get a locator fo= r | the input source. "http://someurl.com/foo.xtm" would fail to resolve as= a | file, so you could convert that to a URL, get the URLConnection for the | source and use the URL itself as the base url | | 3) if no base url is specified and the input source comes from a pipe, = then | use some default URL (could it be based on the current working directo= ry | ?) OK, but TopicMapProviderBase doesn't support any of that yet. It needs an= =20 overloaded readTopicMap() method which accepts and InputStream and a Stri= ng=20 representing a system ID. Still, even if it's useless, I suggest that we at least drop Sun a note t= hat=20 something like a URLConnectionInputStream is more than needed. We're prob= ably=20 just a few out of thousands, but at least it's worth telling them. Later, -- Florian --=20 Florian G. Haas <fg...@bk...> GnuPG public key: http://www.fgh.bkf.at/gpgkey.asc Key fingerprint: 3C24 E021 33B1 9E98 B94B 2F21 860A B693 1B33 BB3C |
|
From: Kal A. <ka...@te...> - 2002-06-07 14:49:56
|
Hi Tim, The scope comparison is just on a set membership basis. i.e. you will only get a positive if there is an overlap between the topics in the scope you are testing against and the topics in the scope you are testing with. The comparison does not take account of class-instance or subclass-superclass relationships. While this is in line with the XTM specification (and the way that scope is used there), I think I can see why you might want to use a class-instance relationship (to say something like "if name is scoped by a language then...") - but to do that I think you will either have to a) Create a myScope that contains all the instances of TopicB b) Write your own test My guess is that in the general case, (b) is preferable to (a). Cheers, Kal At 16:55 07/06/2002 +1000, you wrote: >Hi all, >I think I am missing something, >I used a >Topic.getNames(), converted to get a group of BaseNames >I then used baseNameArray[element].inScope(myScope) >and did NOT get a true when myScope SHOULD (I think) have given one >if the name is scoped by Topic B >and TopicA is-a TopicB (class-instance) >then if myScope is TopicA (remember name is scoped by TopicB) >Shouldn't I get a positive? >Sorry if this is overly confusing >Tim Smith > > > >_______________________________________________________________ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >_______________________________________________ >Tm4j-developers mailing list >Tm4...@li... >https://lists.sourceforge.net/lists/listinfo/tm4j-developers |
153 messages has been excluded from this view by a project administrator.
