[TM4J-users] Resend: My Tolog Abstractor Reqs. + Remarks on Tolog Abstractor

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

I tried a couple of times (today & yesterday)
to send Christoph & tm4j-users a couple of
documents about what I'm trying to do & what
I think about his ideas.

Each time I went over list's space limit, so I'm
resending with both messages attached  as text (rather
than Word) docs, so as to stay within the limit.

messageToChistophAug10.txt is my reply to his
last message to me about his ideas for
extending the TologAbstractor to meet my
& other user's needs.

Hypergraph Requirements.txt is a specification
describing the needs of my own project - my final
project for a Java sequence of study I've been
taking.

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!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail