Re: [topicmaps-comment] TAO vs. ERA

["Thomas B. Passin" <tpassin@home.com>]

\rho said:

> On Wed, Jan 09, 2002 at 08:35:38PM -0500, Thomas B. Passin wrote:
> > I came to this view by wondering how to represent relational tables in a
> > topic map.  A row is a set of data elements.  If you create an
association
> > and label it as a "set" type, the resulting set could represent the row.
> > Each role type is analogous to a column type.   In further support of
this
> > view, remember that C.J. Date, for example, emphasizes that a row is a
> > "relation".
> >
> > Note that in the relation database, the type of the column is specified
in
> > the schema (or the DDL), whereas in the topic map it is specified by the
> > topic reference of the role.
>
> I try to interpret the role in an association NOT as a type.
>
> In the association
>
> (kills)
> murderer: moriarty
> victim: ?
>
> Moriarty PLAYS the role of a murderer. Maybe he is also one (via
instanceOf)
> but this has to be stated explicitely in the topic.
>

Well, yes, but I'm not claiming that roles translate identically to column
types, only that you can do that if you want to, for the purpose of drawing
an analogy between a relational and a topic map model.  After all, the term
"role" has not been precisely defined in any topic map spec, has it?  I'm
not sure that it can or should be, for that matter.  No doubt most people
use their common-language understanding of the term.  It seems likely to me
that such understanding may vary across cultures and languages, too.  So
what is the precise meaning of  "role" in topic maps?

There are at least three ways to model properties (I can give a reference
about this to John Sowa's work if anyone wants).  One way matches
associations pretty well and one way matches occurrences pretty well.  Steve
Pepper also posted about this last year.  Each way has some advantages, but
(according to Sowa as liberally interpreted by me - he, of course,
illustrates with conceptual graphs) the association-style is well suited to
databases because you can get more semantics and type definition - that is,
you can say more about the nature of the properties you are working with.

> In my interpretation a role only locally inside the association is
relevant.
> Only because moriarty plays the murderer this does not mean he IS a
murderer.
>
I don't understand the distinction as you use it here (I do understand it in
general) in an association's role.  Of course I tend to think of the role
(at least, its name) as a label for an arc in a graph, and so I think of the
relationship as making assertions.  You don't have to interpret an
association that way, I suppose, but I think it's good to have ***some***
standard interpretation and that way seems to me to be potentially most
useful and in line with (other) KR systems.

> > The topic map contains this information redundantly, since it is
repeated
> > for each similar association while it is not included in the table data
of
> > the relation database.
>
> Where is then the redundancy? Since every association is somehow 'a table
> per se', it is relevant and cannot be dropped without loosing information.
>
Every row in a relational table does not carry information about the types
of its columns, but every assocation instance does.  That's what I meant by
"redundancy".  Row data in CSV does not carry field labels for every row,
row data in xml normally does.  That's partly why I suggested the analogy
relational:topic maps::CSV:XML.

> > The real difference between a topic map and a relational database, from
this
> > point of view, is that in the topic map, the data elements (i.e.,
topics)
> > are structured.  In fact, everything that is simple in the relational
> > database is structured in the topic map.  That's one of several reasons
it's
> > such a pain to fully represent a topic map in a relational database.  In
> > this regard, the analogy might be
> >
> > relational:topic_maps::CSV:XML
>
> Speculating here wildly , maybe it can be described by the entropy of the
schema
> describing your data:
>
>   - In the one extreme, you have a constant. Simple to describe in a
schema,
>     but little information content.
>
>   - Somewhat further down the range there are relational databases. Every
row
>     (lets assume one table) has the same structure. The schema definition
>     is short and in length independent of the database size.
>
>   - If you relax your structure, you need some XMLish structure. Still you
>     can define your structure via a schema, but it is getting longer,
needs
>     more information, has higher entropy.
>
> ...

I don't think this is about entropy really, but more about information
density.

>
>   - The other extreme is data which is sooo variable, that you need the
>     same amount of meta-information to describe it. Or - the other way
>     round - it is better to have description and data mixed.
>     Maybe topic maps fit in here. Maybe not.
>

Cheers,

Tom P