RE: [topicmaps-comment] TAO vs. ERA

[Marc de Graauw <marc@marcdegraauw.com>]

I think the main difference between the relational model and Topic Maps is the 
basic idea behind it. With a relational database this idea is to structure data 
and store them on a computer (in a database), with Topic Maps it is to describe 
data that can reside anywhere - in a computer, on paper et cetera. So an 
occurrence is certainly not the same thing as an attribute. An attribute is 
information that is stored in the relational database, whereas an occurrence is 
a piece of information which may or may not be in the Topic Map.

Another important distinction (which Thomas makes) is between entities as in 
ERA and relations as Codd and Date define them. In the original relational 
model of Codd there are only tables (which are called relations) which consist 
of rows (which are called tuples, but that term is rarely used) and fields 
(which are called attributes). There is no such thing as an association or 
relationship between two or more tables in the relational model. Instead, 
foreign keys are used, which can be used to achieve what associations can 
achieve. But in a relational database there are _no_ such things as 
associations (granted, in contemporary relational database there are things as 
constraints and triggers which make things murkier, but at least in the 
original relational model there are no associations). With foreign keys it is 
easy to implement 1-to-1 and 1-to-many associations, but one cannot implement a 
many-to-many and ternary associations directly, this has to be done through an 
intermediate table.

Entity-Relationship-Attribute (ERA) is a datamodelling technique, I think Chen 
developed it first but I'm not sure. In ERA you have entities (which are called 
relations in the relational model) which contain attributes and relationships, 
which are 'associations' between two or more entities (and which may or may not 
contain attributes, depending on the flavor ERA you are using). So in ERA there 
are things like associations (TM terminology) or relationships between 
entities, and in ERA it is possible have many-to-many relationships directly, 
as well as ternary (and other n-ary) relationships.

In general I think the comparison topic=entity, association=relationship and 
occurrence=attribute is misleading. I think occurrences are definitely _not_ 
the same thing as occurrences, because occurrences may be outside the Topic Map 
and may even be offline resources. As for the topic-entity identity, I think 
that may or may not be the case. When a topic is 'person' this could very well 
be an entity in an ERA model (table in a database), but when a topic is 'Marc 
de Graauw', this would normally be a row in a relational database, not a table. 
Also a topic could be 'sex' which normally would be an attribute in an ERA 
model. So whether a topic corresponds to an entity or an attribute depends very 
much on what you're modelling and how you've modelled it. As for the 
association-relationship identity, I think it is fair to say that relationships 
in ERA fulfill very much the same role that associations fulfill in Topic Maps, 
though I do not think they are strictly the same.

As for the differences and strengths of the relational model and Topic Maps I 
would think that the relational model is the better approach when one wants to 
store structured data in a computer. That is what the relational model and 
relational databases were developed for, and what they're good at. I think a 
relational database would outperform a Topic Map for such an application, 
though this is based on gut feeling. I do have a lot of experience implementing 
all kinds of large and small relational databases, but I've never implemented a 
Topic Map-based application. So if anyone disagrees on this point, please 
respond.

Topic Maps can do a lot of things that relational databases are not very good 
at. With Topic Maps it is easier to store knowledge (as opposed to just data). 
For instance, in a Topic Map one can have a topic type which is a topic itself, 
so in a Topic Map it is easy and natural to store information both of things 
inside and outside the Topic Map. This could be done in a relational model, but 
it is not a natural thing to do.

So my opinion would be that Topic Maps and the relational model have different 
application areas. Topic Maps are a more general and more expressive technique, 
and it is easy to do things in Topic Maps that are hard in the relational 
model. The relational model is more specific for storing structured data in a 
database, and though it would be possible to do the same thing with Topic Maps 
it is a more natural choice to choose the relational model and a relational 
database to store, say, payroll information.

Cheers, Marc

On Thursday, January 10, 2002 2:36 AM, Thomas B. Passin [SMTP:tpassin@home.com] 
wrote:
> [Scott Tsao]
>
> > In a recent presentation of TopicMaps, the audience
> > was able to relate the TopicMaps paradigm
> > (topic-association-occurrence) to a more traditional
> > data modeling paradigm, namely, ERA
> > (entity-relationship-attribute), where topic
> > corresponds to entity, association corresponds to
> > relationship, and occurrence corresponds to attribute.
> >  While this mental mapping helped their understanding
> > (and hopefully acceptance) of the TopicMaps paradigm,
> > I was trying to come up with something that could
> > prove that TopicMaps is significantly different (and
> > better) than ERA.  Do you have any suggestion?  Is
> > TopicMaps merely a newer version of ERA for the Web?
> >
>
> I don't think a topic properly corresponds to an entity in general, although
> it could.  To my mind, an association with its associated topics corresponds
> most closely to a ***row***.  So a topic is like a field or cell, not really
> an entity.
>
> 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.
>
> 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.
>
> 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
>
> Topic maps also let your relationships be structured and carry data (if you
> reify them by topics), which a pure relational model does not allow
> (although with a many-to-many intertwinkle table you can add some data
> specific to a relationship instance, if you think of a row in that table as
> a relationship instance).
>
> Now it is true that you can also regard a topic with its occurrences as
> similar to a row (or entity), which was your starting point.  In this case,
> the type of an occurrence would correspond to a column type.  But it's less
> clear what an association would represent, because an association can link
> any number of topics, each with a role, whereas a relationship in the
> relational model can't link any number of topics.
>
> An RDF statement is essential a row of three elements, so would fit a
> relational model well.  And we know you can go back and forth between topic
> maps and RDF, so again we can get a correspondence between topic maps and a
> relational model.  Still, when I put it all toether, I still get
>
> relational:topic_maps::CSV:XML
>
> I think it gives a more consistent picture. Anyone else?
>
> Cheers,
>
> Tom P
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>