[topicmapmail] Expressive capabilities of Topic Maps

[jalgermissen@topicmapping.com]

"Thomas B. Passin" <tpassin@comcast.net> wrote

> > > I try not to think of TM and RDBMS as competitors.
 
Aha! I see Topic Maps as a data model that overcomes certain limitations
of the relational model (limitations that become more and more evident
as
database modelers and users become more and more interconnected and
think
about interchangeability and integratability of databases). To me,
entity-relationship modeling is closed-world data modeling while Topic
Maps data modeling is open-world data modeling (planning for federation
of information).
 
Comments inline.
 
 
  First of all, if you
> > > have regular data
> >
> > What do you mean by *regular data*?
> >
>
> I meant that most or all cells in each table would contain data (with a some
> NULLs, no doubt),
 
I agree that the relational model is well suited for that sort of data
because
it goes well with the reuirement to classify all modeled entities.
 
 and that there would be only a relatively small number of
> association types - n other words, you would not be making up new
> association types all over the place to accomodate peculularities of the
> data set.
 
But creating an association type is not really different from creating a
table....
 
>
> > that is well-modeled by a table structure, you should use
> > > a relational database, since they are highly evolved and efficient at
> > > handling that kind of data.
 
 
Yeah, but what if I WANT merging and, duuh, multiple classification of
entities?  Can't get that with ER....
 
> > So, what data is 'well modeled by a table structure'?
>
> As above, and also something equivalent to a primary key, preferably atomic
> (but that is not essential); a limited number of foreign keys; a consistent
> (and known) set of integrity constraints
 
Hmm....you can get all that with topic maps too.
 
[...]
 
> > >
> > > Second, it can happen that a relational database is designed (more or
> less)
> > > according to a topic map design, even if it does not implement
> everything in
> > > the TM standard(s).
> >
> > Yes, can this happen? Can you give an example? Can we store data in
> > an RDBMS and support the merging capabilities of topic maps?
> >
>
> Aha!  I think that merging would be somewhat problematical for relational
> databases, unless one adopted some strong conventions whereby identity
> between different primary keys could be assured.
 
Merging is critical for ER databases - all entities are classified! You
can't mix buyers and sellers, even if one of them is both.
 
> Of course, RDBMSs do not
> natively support TM-style merging so you would have to write code to do a
> merge.  But you might have to do that with a TM, too, depending on your
> software and the kind of merging you would want to do.
 
Uh...I thought TM software essentially suports merging?
>
> > In that case, the database __is__ a topic map, to all
> > > intents and purposes.  You may want to put a topic map wrapper over it
> for
> > > data interchange purposes.
> >
> > Do you mean storing TMs with an RDBMS backend? Of course this works, but
> > that is not my point.
>
> No, I did not mean that.  I suggest the following way of mapping a
> relational database to a topic map.  I am referring to a well-normalized
> relational design - say at least 3rd normal form.  A "join" table - what
> Mike Gorman calls an "Intertwinkle" table - is essentially isomorphic to a
> TM association.  Column labels are equivalent to role types.  The foreign
> keys point to the role-playing topics.  A row is equivalent to a specific
> association.  The association type is equivalent to the table type.
 
Yes. But how to merge entities that have different classes?
 
 
 There
> are no scopes per se, but to some extent they could be fudged in using WHERE
> conditions, I suppose.
>
> An "ordinary" table - not a join table - could be modeled either as an
> association or as a topic with occurrences.  In my opinion, it is most like
> a topic with a set of occurrences.
 
You know my opinion on this ;-)
 
> Each occurrence type corresponds to a
> column label.  Each row corresponds to a topic.  Each primary key - I am
> assuming atomic primary keys - corresponds to the topic id.
 
 
What if my primary key is latitute/longitude data? Represented as a
two-column primry key?
 
 
A basename has
> no real equivalent, but could become simply another column (or more) in the
> table.
 
Topics can have more than one basename.....
 
>
> This plan has the advantage that it is simple, has low overhead, and that
> the data values are literals (or references to some other resource), which
> is the case with the table cell values.  That is why I say this is an
> appropriate mapping.
 
IMHO, it is not possible but open to be proven wrong.
 
> It has the disadvantage that, if you wanted to
> represent two or more separate tables, they would all coalesce into the one
> topic and not be easily distinguishable afterward (although with the proper
> schema you could take care of that).
>
> Murray Altheim wants to have each data value be its own topic so he can
> associate to it to his heart's content - think lots of meta data - and
> that's fine, I am just looking at the near-isomorpism between TMs and
> relational database design,which is a little different problem.
>
> Now suppose  you have a data model that does not fit this plan well - then I
> assert that it is not a good candidate for modeling with a relational
> design - and conversly.  A lot of special cases, different topics of the
> same type type having quite different occurrences or associations - cases
> like these would be good fodder for topic maps as opposed to relational
> designs.
 
Will think about the above.
 
> > >
> > > Third, if your data is more like a set of sparse tables, or is irregular
> in
> > > its structure, topic maps are likely to work much better than an
> ordinary
> > > relational database
> >
> > Yes? Why?
> Because you would have to keep making up new tables that were used only for
> a few of the subjects, and similarly for columns on a table.  This is awful
> to work with in a relational database.
>
> > So, the data I need to store being "like a set of sparse tables" or
> > "irregular in its structure" would be the criterion to choose topic maps
> > instead of an RDBMS?
> >
>
> A need to merge could be another criterion suggesting using a TM, as could
> the use of scopes.  Also, if you need the full range of options available in
> XTM (three kinds of subject indicators, for example), it gets pretty tedious
> to implement and query in a relational database.
 
Yes ;-)
 
 
Jan
 
 
>
> Another point is that topic maps can be seen as an abstract pattern for
> modeling - the pattern constrains you, but it is also freeing because you
> can follow the pattern isntead of inventing everything anew each time.  It
> is especially good for indexes and suchlike, and for many-to-many
> relationships, so situations that need to be modeled like them then to work
> well as topic maps.  Now if you happen to use a relational database to
> implement it, well, you are still following the topic map pattern.
>
> Another strength of topic maps is that it is easy to remodel and change or
> add to the design.  It is much harder with a relational database.  On the
> other hand, because of this a relational database can bring more stability
> to the data, which is generally a good thing.
>
> > Could you give examples for such data?
> >
> >
> Not tonight ...
>
> Cheers,
>
> Tom P
>
>
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail
--
Jan Algermissen                <algermissen@acm.org>
Consultant & Programmer
 
http://www.topicmapping.com
http://www.gooseworks.org