[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