RE: [topicmaps-comment] TAO vs. ERA

[Chris Angus <chris.angus@btinternet.com>]

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

When you define a column in a relational table you are inherently defining
two classes (types).  The first defines the domain of the column from which
values may be drawn - one can think of it as the type of the column.  The
second is a subtype of the first and is the set of things that play the role
that is implicit in the column in one or more tuples in the relation.  The
relational model itself does not provide a specific mechanism for saying
much more about the role, beyond using a suitable name for the column, but
nevertheless the class is there.

One of the characteristics of such 'role-based' classes is that in the
general case a member of the supertype class can be a member of any number
of the 'role-based' subtype classes.  They therefore do not make good
candidiate entity types (entity sets in Chen's E-R model) in an E-R-A model
as they are not sortal types.

'Composer' seems to me to be a good example of a notion that has multiple
overlapping classes associated with it.  Certainly one can say that someone
who has composed a piece of music is a 'composer'.  But one may also wish to
designate someone as a 'composer' without providing specific evidence of
their role in any compositions.  One may also wish to define a person as a
'composer' on some basis which considers the quality or significance of what
they have composed.  There again, a person might only wish to designate
themselves as a 'composer' if it is their principal occupation.  These are
clearly all different classes that are subtypes of some 'composer' powerset,
and one can also define generalisations of sets of them.

I think that one has to be careful about drawing too much of an analogy
between E-R and topics and associations, partly because of restrictions in
the E-R model.  Among the things that I would cite are the following:

(1) A relationship cannot be treated as an entity whereas an association can
be reified as a topic.

(2) A topic can equate to either an entity set (using Chen's terminology) or
an entity (i.e. an entity type or an instance of an entity type) - something
that the E-R model does not support.

(3) An association can exist between a topic that equates to an entity set
and a topic that equates to an instance of an entity set.

Regards
Chris Angus