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

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

Hi Christoph

What you are describing would certainly be a good
thing to have.

For my purposes (and I imagine the purposes of
some other TMNav potential users as well), I'd also
like to be able to create a top-level hypergraph

The difference between the top-level hypergraph
and what you are proposing is that:

In your proposal, all associations (& their
members) of a certain type in which (at least) ONE
of the topics on the input list is a member
is displayed.

For my top-level hypergraph, I ONLY want
to display associations for which
BOTH member topics are topics on the input
list provided by to the Abstractor

For lower-level hypergraphs, I could use
what you propose, or I could use something
more like the way TMNav currently operates:
select a topic & then represent all of the association
(& their members )of which that topic is a member.
(The only difference being that the topic would
be selected from the high-level hypergraph, rather
than from the Index list of topics)

Bret

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

> 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
> 
=== message truncated ===



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail