[TM4J-users] Re: Tolog Abstractor modifications

[Bret C. <bre...@ya...>]

I'm attaching two text messages.

messageToChristophAug10.txt is a response
to Christoph's last message to me
about ideas for extending the Tolog Abstractor

Hypergraph Requirements.txt describes
by own project, which I'm doing as the
final project for a Java course sequence I've
been taking - and how I want to use a hypergraph
for display purposes.

Bret
--- Christoph Froehlich <cf...@fo...> wrote:

> Hi Bret
> 
> Am Mo, den 09.08.2004 schrieb Bret Cohen um 23:17:
> > Hi Christoph
> > 
> > Thanks for your taking the time to think this
> through.
> > 
> > Some points:
> > 
> > 1. What's the procedure for filing a Bug Report
> with
> > Kal about the issue I raise?
> > 
> Ohhh. You got me. I've never filed one. 
> But I guess you should point your browser to
>
http://sourceforge.net/tracker/?group_id=27895&atid=391879
> and follow the link "Submit new"
> 
> > 2.My reasoning about the possibility of writing a
> > Tolog Abstractor for a Hypergraph is as follows:
> > 
> > True Tolog returns results as rows & columns, but
> that
> > doesn't mean they can't be used for other
> purposes. 
> > 
> agree
> 
> > We know that the following two sequences are
> possible:
> > 
> > Tolog query => Topic Map Fragment (really just
> another
> > topic map - right?)
> > 
> > Topic Map => Compact Abstractor => Hypergraph
> Renderer
> > 
> > So, if worse comes to worse, I could simply write
> an
> > abstractor that takes as input the Topic Map
> Fragment,
> > rather than the raw Tolog results - Or is there
> some
> > intermediate state from which to draw?
> > 
> In the last time I came to the conclusion that all
> abstractors
> essentially work in two steps.
> 1. They get the data, typically by using Extractors
> or in our particular
> case by executing a tolog query.
> 2. They build the Model from that data. I started to
> call this step the
> 'molding'. I've found that word in german-english
> dicitionary and I
> liked it, but meanwhile it sounds a bit strange to
> me. Is it a common
> word?
> 
> Nevertheless. What we need to do is to make the
> 'molding' step of the
> TologAbstractor customizable. Then we can create
> models of any shape we
> can think of.
> 
> > Anyway, isn't a row just a way of referring to a
> set 
> > of values for the attributes of an object, with
> each
> > column containing the values for a particular type
> of
> > attribute?
> I agree totally that there are plenty of ways to
> present a particular
> resultset in a meaningful way. My concern was about
> finding another
> _generic_ form of presentation. For generic purposes
> a table is pretty
> good I think.
> 
> 
> But maybe we can start with a simple use case. For
> example with
> resultsets that have only one column and that store
> TopicMapObjects and
> not Integers in that column.
> 
> We could then say, that we use the CompactAbstractor
> to transform the
> TopicMapObject of each row into a model and that we
> add all the
> centernodes of all the models to a sort of
> supermodel that will be
> returned. The centernode of that supermodel will be
> of a new Gestalt,
> GESTALT_INVISIBLE and the abstractors could be
> updated to recognize that
> Gestalt and to not to draw it.
> 
> Does this sound like what you was thinking of?
> 
> bye
> c
> 
> 
> > Well, I have to go, but I'll continue to think,
> and
> > I'll be sending a better specification for what I
> need
> > shortly.
> > 
> > Bret
> > --- Christoph Froehlich <cf...@fo...> wrote:
> > 
> > > Hi Bret
> > > 
> > > thanks a lot for the input and sorry for
> responding
> > > late. It took me
> > > some time to sort out my mind.
> > > 
> > > 
> > > Am Mi, den 04.08.2004 schrieb Bret Cohen um
> 0:48:
> > > > Christoph,
> > > > 
> > > > I did some testing of tologx in TM4J 0.9.6 &
> TMNav
> > > > 0.2.8. I've attached the results
> > > > (TologTestResults.txt).
> > > > 
> > > > For TMNav, I tested variations of a Tolog
> query
> > > passed
> > > > to the Tolog Abstractor and then represented
> by
> > > > various renderers.
> > > > 
> > > > One problem for both applications is that
> queries
> > > > don't seem to work when they are forced to
> iterate
> > > > over more than one type of association.
> > > > 
> > > I think it would be good to file a bug report.
> This
> > > is something Kal
> > > should have a look onto.
> > > 
> > > > Another problem, specific to TMNav, is that
> the
> > > > Hypergraph & Touchgraph Renders don't seem to
> bind
> > > the
> > > > variables (such as $ASSOCIATION & $ROLE) to
> their
> > > > values - Each are displayed separately. And
> the
> > > Table
> > > > Renderer even fails to show the values.
> > > > 
> > > > Even if you succeed in fixing these problems,
> I
> > > think
> > > > I will have to write my own abstractor,
> because I
> > > need
> > > > to display results in a Hypergraph or
> Touchgraph,
> > > > and I don't find the way the Tolog
> Abstractor's
> > > > table-oriented model are displayed by those
> > > renderers
> > > > to be intuitive. FYI, I've enclosed a
> discussion
> > > of
> > > > this issue, together with some ideas of mine
> about
> > > > what to do about it (AbstractorReqs.txt). If
> you
> > > can
> > > > either make use of these ideas for your own
> work
> > > or
> > > > comment on them for me, they will have served
> > > their
> > > > purpose -- though, of course, don't feel
> obligated
> > > to
> > > > do either.
> > > > 
> > > 
> > > I agree totally with you, that the model that
> the
> > > TologAbstractor
> > > currently generates is not suitable to be
> presented
> > > by any of the
> > > generic renderers (Touchgraph-, Hypergraph or
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com