Re: [Tm4j-developers] TMNav

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

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