Re: [Tm4j-developers] TMNav

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

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