[topicmapmail] Expressive capabilities of Topic Maps

[jalgermissen@topicmapping.com]

Lars Marius Garshol <larsga@garshol.priv.no> schrieb am 08.08.2003,
21:29:23:
> 
> * jalgermissen@topicmapping.com
> | 
> | I have a question regarding the expressive capability of topic
> | maps. I am very curious what others think about or how they solved
> | something similar to the follwoing.
> 
> I've done this a couple of times, so I thought I'd have a stab at
> this, even though it's getting a little late to answer your question.

Duh...a little late for me to answer *you* ;-)

> | Suppose a company indends to migrate the following relational data to
> | topic maps:
> | 
> | 
> | CREATE TABLE PERSON (
> |     ID        CHAR(10),
> |     SURNAME   CHAR(60),
> |     FIRSTNAME CHAR(60),
> |     BIRTHDATE DATE,
> |     CITY      CHAR(30),
> |     ZIPCODE   CHAR(6),
> |     STREET    CHAR(40),
> |     COUNTRY   CHAR(3),
> |     PRIMARY KEY(ID),
> |     UNIQUE (SURNAME,FIRSTNAME)
> | );
> | 
> | INSERT INTO PERSON VALUES
> | ('6657A54','Hansen','Hans','02-02-1970','Hamburg','22607','Im Gehoelz
> | 33','FRG');
> | 
> | 
> | How would the entity Hans Hansen be represented in a topic map
> | (propably in XTM syntax), assuming that all the attributes are to
> | remain attributes (meaning that they are not be regarded as subjects
> | in their own right and thus not to be represented as topics). 
> 
> I would do something like the following (using $COL for column
> references):
> 
>   [person$ID : person = "$FIRSTNAME $SURNAME"; "$SURNAME $FIRSTNAME"
>                       = "$FIRSTNAME" / given-name
>                       = "$SURNAME" / surname]
>   {person$ID, birthdate, [[$BIRTHDATE]]}
>   
> City and country I would be strongly tempted to do with associations,
> but if we are to go your route then the rest of the table follows the
> pattern set by the birthdate.

Forgive me, I don't speak LTM....[[ ... ]] denotes an occurrence with
resource data..yes?

The problem I have with this is that this will recognize the birthdate
as a subject or (using the SAM draft) at least the relationship between
the person in question and the birthdate. Since within the RDBMS the
birthdate is a simple property of the person this does not satisfy me.
It creates overhead that is not in the original data. Furthermore, I'd
have to tell my (imaginary) client that all simple properties of her
millions of person entities will create this overhead....

Any other ideas?
 
> 
> | - How to preserve the expressive capability of the original data,
> | such as the data types of the various properties and the uniqueness
> | constraints
> 
> There's no standard way to do that yet, but my approach would at least
> preserve the identity requirement on the ID. As for the datatyping I
> would expect TMCL to do that.

I must admit that I am not up to date on TMCL, is this already
early-drafted somewhere?

> 
> | - how to document/communicate the decisions so that others can
> | understand them (like the way we can all understand the SQL
> | statements)
> 
> TMCL, once standardized, solves that problem.

Understood.

> 
> Was this the kind of answer you wanted?

Well, I am curios to see what people think about using topic maps as
a competitor for the relational model. Suppose you go into a company
that wants to create a large database (e.g. customer data, geographic
data, ...) when would you suggest using the relational model and when
topic maps? (assumed that TM tools have the same maturity as RDBMS)

Thoughts?

Jan
> 
> -- 
> Lars Marius Garshol, Ontopian         
> GSM: +47 98 21 55 50                  
> 
> _______________________________________________
> 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