[topicmapmail] Expressive capabilities of Topic Maps
jalgermissen@topicmapping.com
jalgermissen@topicmapping.com
Tue, 9 Sep 2003 00:18:01 +0200
Thomas--
excuse any provocative language below...I simply want to get
people thinking about this issue.
"Thomas B. Passin" <tpassin@comcast.net> schrieb am 09.09.2003,
00:00:28:
> []
>
> > 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 try not to think of TM and RDBMS as competitors. First of all, if you
> have regular data
What do you mean by *regular data*?
that is well-modeled by a table structure, you should use
> a relational database, since they are highly evolved and efficient at
> handling that kind of data.
So, what data is 'well modeled by a table structure'?
What is the nature of data where we profit from using topic maps?
In this case, a topic map overlay can be very
> useful, either for integrating several databases or for providing navigation
> for the database. No need for competition here.
I am not thinking about using topicmaps as an add-on! I am thinking
about reasons to store data as a topic map in the first place.
[Note: topicmap != topic map document!]
>
> Second, it can happen that a relational database is designed (more or 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?
In that case, the database __is__ a topic map, to all
> intents and purposes. You may want to put a topic map wrapper over it for
> data interchange purposes.
Do you mean storing TMs with an RDBMS backend? Of course this works, but
that is not my point.
>
> Third, if your data is more like a set of sparse tables, or is irregular in
> its structure, topic maps are likely to work much better than an ordinary
> relational database
Yes? Why?
So, the data I need to store being "like a set of sparse tables" or
"irregular in its structure" would be the criterion to choose topic maps
instead of an RDBMS?
Could you give examples for such data?
Jan
(given your assumptions about maturity, so that CRUD and
> transaction issues would be handled effectively).
>
> 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