OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [topicmaps-comment] TAO vs. ERA


[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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC