[topicmapmail] Expressive capabilities of Topic Maps

[jalgermissen@topicmapping.com]

"Thomas B. Passin" <tpassin@comcast.net> schrieb am 12.09.2003,
03:58:01:
> []
> 
> > But creating an association type is not really different from creating a
> > table....
> >
> 
> Right, and my point here is that it is much easier to start using a new type
> of association than to create a new table in a relational database.  So a
> situation that would call for creating a lot of new tables to handle
> "special cases" would favor using topic maps rather than a relational
> database.  I think we are thinking alike here.

No, I disagree that creating a table is more costly than creating
a new association type. A relational table and an association type
are essentially the same thing and a topic map system 'of any use'
(all implementors forgive me,please ;-) would IMHO have to do
all the kind of indexeing on associations (by type, by roles, by
players) that an RDBMS does on tables. You definitely cannot get
away with connecting some objects by mere references.

> >
> > Yeah, but what if I WANT merging and, duuh, multiple classification of
> > entities?  Can't get that with ER....
> >
> 
> Sure you can get multiple classification.  

Sure, you can create a single huge table (TABLE TOPIC) and
represent class-instance-ness in another table, connecting
entities of type topic....but if that's good ER design.....;-)


> However you set up your table
> structures to do the one classification, do the same again for another.  You
> might even be able to hold several classification taxonomies in a single
> table, depending on how you do it.
> 
> > > > 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.
> >
> 
> Right, and when your data is regular and dense (i.e., not sparse), and suits
> a relational model well, you can get all the many advantages of a relational
> database.  

Quick: what are the advantages of the ER model compared to the
topic maps model?


> One of those is not to have the overhead of repeating metadata -
> like the data type or topic type - for each instance.  

Ah, you answered already, sorry. Yes, that is an advantage, but
at the cost of the requirement to classify AND ONLY BY ONE CLASS!
(=>no different world views possible).

Another is relational
> algebra.  

Why can an algebra not be developed for TMs?

> Another is closure - a query operates only on sets of tuples (a
> table or view) and returns only sets of tuples.  In a topic map query
> language, as I see it, you would need to be able to return not only another
> topic map (that would be the closure), but also other structures such as
> lists of topics or associations.

Well, that depends. I see lots of other ways. One would be to return
lists of topics with peoperties.

> 
> This makes the picture more complex.  So if your data fit a relational model
> well, use a relational database and, perhaps, put a topic map overlay on it.
> Otherwise, don't.
> 
> > > 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?
> > > >
> 
> Why not?  As long as you know what to merge on.  You might even be able to
> do it with the right update query (though I doubt it except maybe for simple
> cases)
> 
> > >
> > > 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.
> >
> 
> This is a matter of how the design is normalized.  Even when you have
> separate tables for buyer and seller, if you use the same person id for
> both, you essentially have a topic (the id) and two associations.  This in
> itself I do not see as a discriminator between topic maps and relational
> databases.

I mean: how do you merge a buyer and a seller (how do you merge the
tables, this is).


> 
> > > 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?
> > >
> 
> But there are different ways to merge - not just on names -  

Ah. I don't mean the cause for a merge, I mean that every TM system
must support that after a merge of two topics there must be only
one afterwards (at least visible).

and any given
> app may not support every way.
> 
> > Yes. But how to merge entities that have different classes?
> >
> 
> If they have different classes, presumably they would be different topics

scientology is a sect
scientology is a church

-> two different (valid) world views, two classes.

> and so you would not be merging them anyway.  But given some merge criteria,
> you could write code to merge data from two relational databases.  Perhaps
> you would have to add tables or modify the tables to accomodate the results,

Which will make all apps that are based on queries on the original
tables useless, because the SQL won't work anymore.

The fact that queries remain 'stable' beyond merges of databases is
one of the primary advantages of topic maps (IMHO).


Jan



> or perhaps you could just make do with temporary tables.  Of course, how to
> do it would depend on the particular case under consideration.
> 
> > > 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?
> >
> >
> 
> I have not worked this one out yet.  That is why I limited what I said to
> atomic keys.  One way to handle it would be to create a topic whose subject
> is the lat/long combination (since it would be a primary subject of
> discourse).  With a lat/long, perhaps it would be a "point", or a "city",
> for example.
> 
> Generally speaking, a field that is a foreign key pointing to another table
> would be represented by an association (and the column label would represent
> the role), and a literal or scalar value would be represented by an
> occurrence (and the column label would represent the occurrence type).
> 
> > A basename has
> > > no real equivalent, but could become simply another column (or more) in
> the
> > > table.
> >
> > Topics can have more than one basename.....
> >
> 
> That is why I said "or more", though really you would want to put the names
> into a separate table - that's just the mechanics of doing one-to-many
> relationships in a relational database.  In practice, though, many topics
> will only ever have one name.  If you know that about your data in advance,
> you can simplify the design.  For example, the topic name might be the title
> of a web page.  A web page can only have one value (ignoring possible
> changes over time, which could be handled in a simple or complicated way,
> depending on your needs).
> 
> > >
> > > 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.
> >
> 
> I don't understand the meaning of this sentence, but anything open to be
> proven wrong sounds good to me.  When it is not open to be proven wrong,
> that's when I worry.
> 
> 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