[topicmapmail] Expressive capabilities of Topic Maps

[Thomas B. Passin]

[<jalgermissen@topicmapping.com>]

> 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.

>
> 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.  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.  One of those is not to have the overhead of repeating metadata -
like the data type or topic type - for each instance.  Another is relational
algebra.  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.

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.

> > 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 -  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
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,
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