[topicmapmail] Expressive capabilities of Topic Maps

[jalgermissen@topicmapping.com]

Lars Marius Garshol <larsga@garshol.priv.no> schrieb am 09.09.2003,
17:24:14:
> 
> * jalgermissen@topicmapping.com
> | 
> | Duh...a little late for me to answer *you* ;-)
> 
> No problem. :)
>  
> * Lars Marius Garshol
> |
> | 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.
>  
> * jalgermissen@topicmapping.com
> |
> | Forgive me, I don't speak LTM....[[ ... ]] denotes an occurrence
> | with resource data..yes?
> 
> It does.
>  
> | 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. 
> 
> Correct.
> 
> | 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....
> 
>  a) Topic maps never had a notion of "simple properties", so what did
>     you expect?

Well, if they did not have simple properties, we'd better hurry to put
them in ;-)  Seriously, I think it would be an enourmous limitation if
Topic Maps could not store, say something simple as the age of persons
in a simple way (as simple as with the entity relationship model).

Also, just because XTM has no facility for properties does not mean that
Topic Maps are unable to provide one. The Reference Model support simple
properties, so why not use them?

> 
>  b) The data model draft says what the structure of a topic map is,
>     but *not* how to store it, so what the overhead of an occurrence
>     is depends on the implementation.

I disagree. The current SAM draft recognises the is-ness of the
relationship between a topic and the information 'that is relevant to
the topic'. For simple properties I don't need that.


Jan
> | Any other ideas?
> 
> No.
>   
> | I must admit that I am not up to date on TMCL, is this already
> | early-drafted somewhere?
> 
> No, there is currently no TMCL draft, only a requirements document:
>   
>  
> Comments on this are very much wanted by both the authors and the
> committee, either here, on sc34wg3, or on tmcl-wg.
> 
> | 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)
> 
> I think Tom answered this pretty well. 
> 
> -- 
> 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