[TM4J-users] Re: Bug Report + Possibility of Writing a new "Tolog Abstractor"

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Bret 

short answer:
What do you think of an abstractor that takes as input 
- a list of topics and 
 -a list of association-types. 

This abstractor should create a node 
- (1): for every topic in the given list 
- (2): and for every association where one of the 
  given topics plays a role in and which is of
  one of the given types.

At last (3): it should create a Node for all of the members 
of all the associations processed in (2)

Of course the nodes resulting from (1), (2) and (3) will be connected
via arcs and the arcs could be labeled with the role the topics play.

The list of input topics may origin from different extractors: For
example all topics of a given type or perhaps the result of a tolog
query or something else.

Would that help you?

bye
c

Am Di, den 10.08.2004 schrieb Bret Cohen um 23:03:
> Hi Christoph
> 
> First, I want to let you know that I've attached a
> Word document describing the REQUIREMENTS, FROM AN
> END-USER'S POINT OF VIEW, OF THE APPLICATION I'M
> TRYING TO WRITE.
> 
> As for your responses:
> 
> BUG REPORT
> maybe I'll hold back until Kal gets back
> 
> ABSTRACTOR TERMINOLOGY: "MOLDING"
> 
> There are really two concerns here:
> 1. understanding "molding" within itself
> 2. understanding what distinguishes it from rendering
> 
> As for the word "molding", it is used, though not that
> commonly, in English. It is usually used (as either a
> noun "the molding" or a verb "I am molding...") when
> speaking of giving shape to some previously
> "amorphous" semi-liquid, semi-solid substance such as
> clay, cookie batter, or plaster. (The noun form means
> the frame in which the substance sits until it takes
> on the shame of the frame.)
> 
> A more generic term would be the noun "organization"
> (or the verb "organizing"). Unlike molding,
> "organization" is more commonly used with respect to
> formation by grouping of atomic particles ("countable"
> objects - as opposed to the "uncountable" amorphous
> substances shaped by molding). And topic map objects
> are atomic elements
> 
> One could also speak about "arranging" elements -
> which means pretty much the same as "organizing", a
> commonly used word, though not within the world of
> data-processing.
> 
> So you are really speaking about dividing the
> Abstractor into two stages:
> 1. data (topic map object) abstraction
> 2. data (topic map object) organization
> (logical organization, that is)
> 
> The Renderer then takes the logical organization and
> creates a physical representation of each of the
> elements within that organization
> 
> (The idea of a logical and physical representation is
> understood among programmers, but not among ordinary
> users. -- so things could get tricky when you try to
> explain that the same hypergraph can be represented
> logically by the Abstractor and physically by the
> Hypergraph Renderer)
> 
> THE TABLE AS A GENERIC TOLOG ABSTRACTOR REPRESENTATION
> > 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.
> Well, I don't think a table is so "generic" if, as you
> yourself say, it can only be rendered by a table
> renderer.
> 
> On the other hand, I'm having a hard time thinking
> abstractly about what would constitute such a
> "generic" representation.
> 
> Maybe it's best to forget about a generic represention
> for now and, as you say, start with a simple use
> case...
> 
> "A SIMPLE USE CASE"
> > 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.
> 
> The point is that - just as with the current Tolog
> Abstractor the "center node" should be something other
> than a TopicMapObject (such as the TABLE NODE in the
> case of the current Tolog Abstractor, and the
> GESTALT_INVISIBLE in your proposal). The reason is
> that you want to represent a set of TopicMapObjects
> that may or may not be directly related to one
> TopicMapObject. So no one object can serve as the
> center node.
> 
> Your idea of creating a supermodel out of a set of
> Compact Abstractor generated models (each of which do
> in fact have a TopicMapObject as their "center node")
> sounds like it could be potentially promising.
> 
> On the other hand, your "simple use case" is a bit too
> simple for my use, because it (if I understand
> correctly) is a case in which each compact abstractor
> only returns one TopicMapObject, so we can't represent
> a topic and its associations.
> 
> If you take a look at the attached spec,
> you'll see that what I need is to represent a set of
> topics and the associations between them. So you have
> to do the following:
> 
> in the extraction stage:
> - filter the topics from the topic map
> - filter the associations from the topic map, so
> as to keep only those which link topics within the
> filtered topic set
> 
> in the "molding"/"organization" stage:
> - combine the topics and associations into one
> model
> 
> It seems to me that a series of compact abstractors,
> each working without knowledge of what the other is
> doing, would have a hard time generating the
> appropriate set of filtered associations.
> 
> And if each topic is the responsibility of a different
> compact abstractor, then which of the associations
> that link the topics are the responsibility of which
> of the compact abstractors?
> 
> Some problems to consider...
> 
> Thanks for all your help.
> 
> 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
-- 
Christoph Froehlich <cf...@fo...>