Menu
▾
▴
RE: [TM4J-users] Some ideas for *cross* TM navigation with TM Nav
|
From: bernard <ei...@fr...> - 2004-09-02 12:08:56
|
Hi Harald,=20 Sounds great ! I hope such things are possible Unfortunately I'm not a programmer and I can't help you to implement = such features. If you need more precision about those ideas ... ... Stay in touch Regards, Bernard | -----Message d'origine----- | De : harald kuhn [mailto:sc...@ma...]=20 | Envoy=E9 : jeudi 2 septembre 2004 13:44 | =C0 : Christoph Froehlich | Cc : vt...@ne...; tm4...@li... | Objet : Re: [TM4J-users] Some ideas for *cross* TM=20 | navigation with TM Nav |=20 | Hi Christoph, |=20 | just one comment. |=20 | >Hi Bernard | > | >that sounds pretty interesting and I think it's closely=20 | related to the=20 | >task that Bret is facing currently: How could the=20 | visualisation of a=20 | >given TopicMapObject or a bunch of topicmap objects be=20 | more easily=20 | >customized. | > | >I think this alludes to several topics: | > | >1. Panckouckes abstraction process should be conceptually=20 | divided into=20 | >at least two chunks: | >The first (S1) is to "extract" the relevant=20 | TopicMapObjects from the=20 | >Topicmap. | >=20 | >The second (S2) is to transform the extracted Objects=20 | into a Model that=20 | >is suitable to be displayed by renderers. | >=20 | >Both stages should be customizable. A TologAbstractor for=20 | example may=20 | >always perform a TologQuery to extract objects (S1), but=20 | how they are=20 | >transformed into a model could be up to a ModelBuilder=20 | that is passed=20 | >into the abstraction process. | > | > | > | >2. The renderers must be openend for customisation as=20 | well. Some simple=20 | >solution would assign icons to Gestalten via a HashMap=20 | and pass this=20 | >map into the Graph-Renderers. Just for the beginning | > =20 | > | We already have something like that, the Representations=20 | and RepresentationRegistry which were part of the=20 | TopicMapViewer (the web based panckoucke application) ,=20 | the only thing we need to do is implement it in the other=20 | Renderers. I will have a Look at this as soon as i find=20 | some time (expect somebody else volunteers ? :) ). |=20 | > | >3. TMNav needs elements (both conceptual and gui) to=20 | assemble a bunch of | >settings that influence the abstraction and the rendering.=20 | > | >3a. Theese 'assemblies' should either be applied=20 | automatically to an | >abstraction demand or they should be chooseable by the user. | > | >3b. In order to apply them automatically we need some general | >rule-mechanics that enable us to express directives like=20 | 'a topic of | >type X' or 'all topics that has an occurrence of type Y'.=20 | Maybe we could | >use a tolog query here... | > | > | >Sounds really interesting and it would be certainly great=20 | to have it.=20 | >But we have to concretise it a bit more... | > | >Anayway, thanks for the suggestion. If you already=20 | thought further, I | >would be glad to hear it | > | > | >Bye | >c | > | > | > | > | > | > | > | > | >Am Mo, den 30.08.2004 schrieb vt...@ne... um 11:04: | > =20 | > | >>Hello, | >> | >>Fist of all, I've just download the latest version of TM Nav : | >>Whaooooo !=20 | >>Real improvement against the 0.2.5 one : I'm really=20 | impress by the new | >>"abstracting" and "rendering" features, which are really=20 | very useful. | >> | >>I mail you to know if you plan to include some *cross*=20 | TM navigation | >>features in complement to the *direct* TM navigation=20 | feature you've | >>implemented in the latest release ... | >> | >>I mean :=20 | >> by *direct* TM navigation : navigation allowing you to know | >>*everything* about *a unique topic* (id, all name(s),=20 | all PSI(s), all | >>occurrence(s) and all r=F4le(s) player, ...) | >> by *cross* TM navigation : navigation allowing you to=20 | know *only few | >>things*, but about *all the topics of one given topic type* (some | >>name, some occurrence(s) and some r=F4le(s) player), ...) | >> | >> | >>Imagine something which allow you to define sorts of extraction | >>"patterns" : | >> | >>One "pattern" define : | >> - 1 : a given topic type to begin the "cross TM navigation" | >> - 2 : the occurrence you want to see via the definition=20 | of "given | >>occurrence types [of the given topic type]) | >> - 3 : the topics you want to see via the=20 | definition of "given role | >>types involved in a given association type where the=20 | given topic play | >>a given role type" | >> - and for each topic define again point 2 and point 3 | >> - and so on ... | >> | >>For example : I want to "extract" :=20 | >> - all topics of the *people* topic type=20 | >> - with *e-mail* "occurrence type"=20 | >> - with *telephon* "occurrence type"=20 | >> - ... And perhaps other kind of "occurrence type"=20 | >> - and all the topic of "company type" playing the role=20 | of "employer" | >>in a *employ* "association type" where the given people play a | >>*employe* "role type" | >> - with *home page* occurrence type"=20 | >> - ... And perhaps other kind of "occurrence type"=20 | >> - and for each *company* : all the=20 | topic of "company type" playing | >>the role of "partner" ... | >> - and for each *company* : all the=20 | topic of "company type" playing | >>the role of "subsidiary" ... | >> - ... | >> | >> The idea is to be able to use patterns to navigate TMs=20 | (with sort | >>pr=E9-define differents perspectives) ... For one given=20 | topic type you | >>have one or more pattern defined, if there is only one=20 | pattern you | >>take this pattern otherwise you give the choice to the user (by | >>contextual menu for exemple) ... And when the "view" is=20 | extract you | >>can apply to the extracted "output" topics the available=20 | pattern(s) | >>according to them type by the same processus I describe for the | >>"input" topic type ... | >> | >>A pattern should be valid for a set of TMs conform to a given | >>ontology. | >>I think if the topic map is driven by a ontology it is=20 | more powerful, | >>because topic type are declare "by intention" in the=20 | ontology and not | >>"by extention" in the KB ... And in this case you can=20 | associate a set | >>of "pattern" to a given ontology and use it for each map=20 | conform to | >>this ontology ... But it's not mandatory to have the feature I | >>describe above | >> | >>Hope I was clear in my explanations | >> | >>Regards and thank a lot for such wonderful tool | >> | >>Bernard | >> | >>------------------------------------------------------------- | >>NetCourrier, votre bureau virtuel sur Internet : Mail,=20 | Agenda, Clubs, | >>Toolbar... | >>Web/Wap : www.netcourrier.com | >>T=E9l=E9phone/Fax : 08 92 69 00 21 (0,34 TTC/min) | >>Minitel: 3615 NETCOURRIER (0,16 TTC/min) | >> | >> | >> | >>------------------------------------------------------- | >>This SF.Net email is sponsored by BEA Weblogic Workshop | >>FREE Java Enterprise J2EE developer tools! | >>Get your free copy of BEA WebLogic Workshop 8.1 today. | >>http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dclick | >>_______________________________________________ | >>Tm4j-users mailing list | >>Tm4...@li... | >>https://lists.sourceforge.net/lists/listinfo/tm4j-users | >> =20 | >> |=20 |=20 |=20 |
