From: Christoph F. <cf...@fo...> - 2004-09-02 10:22:15
|
Hi Bernard that sounds pretty interesting and I think it's closely related to the task that Bret is facing currently: How could the visualisation of a given TopicMapObject or a bunch of topicmap objects be more easily customized. I think this alludes to several topics: 1. Panckouckes abstraction process should be conceptually divided into at least two chunks:=20 The first (S1) is to "extract" the relevant TopicMapObjects from the Topicmap.=20 =20 The second (S2) is to transform the extracted Objects into a Model that is suitable to be displayed by renderers. =20 Both stages should be customizable. A TologAbstractor for example may always perform a TologQuery to extract objects (S1), but how they are transformed into a model could be up to a ModelBuilder that is passed into the abstraction process.=20 2. The renderers must be openend for customisation as well. Some simple solution would assign icons to Gestalten via a HashMap and pass this map into the Graph-Renderers. Just for the beginning 3. TMNav needs elements (both conceptual and gui) to assemble a bunch of settings that influence the abstraction and the rendering.=20 3a. Theese 'assemblies' should either be applied 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 'a topic of type X' or 'all topics that has an occurrence of type Y'. Maybe we could use a tolog query here... Sounds really interesting and it would be certainly great to have it.=20 But we have to concretise it a bit more... Anayway, thanks for the suggestion. If you already thought further, I would be glad to hear it Bye c Am Mo, den 30.08.2004 schrieb vt...@ne... um 11:04: > Hello, >=20 > 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 impress by the new > "abstracting" and "rendering" features, which are really very useful. >=20 > I mail you to know if you plan to include some *cross* TM navigation > features in complement to the *direct* TM navigation feature you've > implemented in the latest release ... >=20 > I mean :=20 > by *direct* TM navigation : navigation allowing you to know > *everything* about *a unique topic* (id, all name(s), all PSI(s), all > occurrence(s) and all r=F4le(s) player, ...) > by *cross* TM navigation : navigation allowing you to 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), ...) >=20 >=20 > Imagine something which allow you to define sorts of extraction > "patterns" : >=20 > One "pattern" define : > - 1 : a given topic type to begin the "cross TM navigation" > - 2 : the occurrence you want to see via the definition of "given > occurrence types [of the given topic type]) > - 3 : the topics you want to see via the definition of "given role > types involved in a given association type where the given topic play > a given role type" > - and for each topic define again point 2 and point 3 > - and so on ... >=20 > 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 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 topic of "company type" playing > the role of "partner" ... > - and for each *company* : all the topic of "company type" playing > the role of "subsidiary" ... > - ... >=20 > The idea is to be able to use patterns to navigate TMs (with sort > pr=E9-define differents perspectives) ... For one given topic type you > have one or more pattern defined, if there is only one pattern you > take this pattern otherwise you give the choice to the user (by > contextual menu for exemple) ... And when the "view" is extract you > can apply to the extracted "output" topics the available pattern(s) > according to them type by the same processus I describe for the > "input" topic type ... >=20 > 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 more powerful, > because topic type are declare "by intention" in the ontology and not > "by extention" in the KB ... And in this case you can associate a set > of "pattern" to a given ontology and use it for each map conform to > this ontology ... But it's not mandatory to have the feature I > describe above >=20 > Hope I was clear in my explanations >=20 > Regards and thank a lot for such wonderful tool >=20 > Bernard >=20 > ------------------------------------------------------------- > NetCourrier, votre bureau virtuel sur Internet : Mail, 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) >=20 >=20 >=20 > ------------------------------------------------------- > 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 Christoph Froehlich <cf...@fo...> |