Re: [topicmaps-comment] TAO vs. ERA

[Robert Barta <rho@bigpond.net.au>]

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.

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.

> 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.

> 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.

...

  - 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.

\rho