[topicmapmail] Expressive capabilities of Topic Maps
Thomas B. Passin
tpassin@comcast.net
Sat, 13 Sep 2003 00:18:40 -0400
[ <jalgermissen@topicmapping.com>]
> [jan]
> > >
> > > What if my primary key is latitute/longitude data? Represented as a
> > > two-column primry key?
> > >
> > >
> [thomas]
> > 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",
>
> But the lat/long *is* the subject, how can that be a point or a city
> at the same time?
>
I don't know - it depends on the particular database and what it is trying
to model. And anyway, for some purposes you might be happy to model a city
as a point. Go look in an atlas for the lat/long of, say, London, and I bet
you will find only a single pair, not a range. I just threw point and city
in to point out that how you would decide to handle the compound key would
depend on what it was intended to represent.
> > for example.
> >
> > Generally speaking, a field that is a foreign key pointing to another
table
> > would be represented by an association
>
> Which would require that the association be 'able to' cause merges based
> on the lat/long player.
>
Maybe yes, maybe no - it depends on what you take to be identifying vs
non-identifying, which is different for every case. You do not want to force
two topics to merge because they each have a similar non-identifying
relationship.
> I meant it is impossible to achive 'the power of topic maps'
> with ER modeling.
>
It probably depends a lot on exactly what you construe "ER modeling" to
include. I am very flexible about it, but if you mean, for example, IDEF1X,
that is so. But the main thing here, I think, is that topic maps are more
flexible. For example, a relational table where one field is a foreign key
into a particular table cannot also have that field point into another
table, but you can have the equivalent with topic maps. On the other hand,
if you happened to know that such would not arise with your data, then topic
maps might not hold an advantage __for that particular case__.
Cheers,
Tom P