Marijane White pointed out the following comment from Michael Sperberg-McQueen asking how topic maps differ from SQL:
The biggest set of open questions remains: how does modeling a collection of information with Topic Maps differ from modeling it using some other approach? Are there things we can do with Topic Maps that we can’t do, or cannot do as easily, with a SQL database? With a fact base in Prolog? With colloquial XML? It might be enlightening to see what the Italian Opera topic map might look like, if we designed a bespoke XML vocabulary for it, or if we poured it into SQL. (I have friends who tell me that SQL is really not suited for the kinds of things you can do with Topic Maps, but so far I haven’t understood what they mean; perhaps a concrete example will make it easier to compare the two.)
From http://cmsmcq.com/mib/?p=810
An SQL example:
firstName | lastName |
Patrick | Durusau |
And elsewhere:
givenName | surName |
Patrick | Durusau |
An interface could issue separate queries and returns a consolidated result.
Does that equal a topic map? My answer is NO!.
The questions that SQL doesn’t answer (topic maps do):
- On what basis to map? There are no explicit properties of those subjects on which to make a mapping.
- What rules should we follow? Because there are no explicit rules even assuming there were properties for these subjects.
Contrast that with (topics in CTM syntax):
http://en.wikipedia.org/wiki/First_name
- "firstName" .
http://en.wikipedia.org/wiki/First_name
- "givenName" .
The Topic Maps Data Model (TMDM) defines the subject identifier property (the URL string you see) and that when subject identifier properties are equal the topics merge.
Different situation from the SQL example.
First, we have a defined property that anyone can look at to judge both the merging (are these really the same two subjects?) as well as to decide if they want to merge their subject representatives with these.
Second, we have a rule by which the mapping/merging occurs. We are no long relying on a blind mapping between the two subject representatives.
Topic maps are a three fold trick: 1) No second class subjects, 2) Explicit properties for identification, 3) Explicit rules for when subject representatives are considered to represent the same subject.
Apologies for the length of this post! But, Michael wanted an example.
Questions?
(I will answer Michael’s questions about XML and Prolog separately.)