[topicmapmail] Re: Emancipating Instances from the Tyranny of Class

[kent fitch]

Sam Hunting wrote:

>A paper with a title that is the same as the subject line of this
>mail can be found at:
>
>    http://citeseer.nj.nec.com/parsons00emancipating.html
...

>Hope this is at least inspirational! ...

Thanks, indeed it is inspirational.  A few years ago I was
infected by some RDF and Topic Map ideas, mostly from the Goldfarb/Prescod 
XML Handbook, which led to the design of
the Australian Literature gateway
(http://www.austlit.edu.au) with basically 2 tables -
topics (2 columns - unique id, type, name) and
relationships (3 columns - topic1, relationship type, topic2).
Later, relationships became topics too, and the need for the
type column in the topic table seemed to wither away because
it was implied by the relationships the topic was involved in.

For example, if you want to find "people" born in Sydney
in 1936,  you may as well just find all topics which have a
"birthEvent" relationship with a topic which has
a "hasPlace" relationship with the topic which has
a name relationship with the topic "Sydney" and
a "hasDate" relationship with the topic which has
a name relationship with the topic "1936":

TopicA  "birthEvent" TopicB  (with no name)
TopicB "hasPlace" TopicC (with the name: "Sydney")
TopicB "hasDate" TopicD (with the name: "1936")
TopicA "hasName(subtype 'human')" TopicE (fancy human name
	 topic: "Feroka, Harry, Sir, OBE")

Such topics (the topicA's) can only be "people", because
only people (in this domain) have a birth event.  If the
domain included animals, then it might be worth having a
"isPerson" relationship, which creeps towards explicitly
classifying things.  Or its participation in a "hasName(subtype 'human')" 
relationship might be sufficient (or
its participation in a "hasName" relationship with a
"human name" topic), in which case we've achieved what we
wanted by forcing the name to be subjected to the "Tyranny
of class" rather than the "Human" (is this a step forward?).

Another practical outcome hinted at above was that the "topic"
table became just a placeholder, not even storing "name",
because "name" is just too complicated to be simply
represented as a string.

Instead, topics have a "name" relationship with various "name"
topic "subclasses": one which stores date names, allowing the
possibility of year, month, date and "era name" attributes;
another with stores people names, coping with surnames,
forenames, titles, name presentation, and so on.

Again, this creeps towards explicit classification - only
a date would have a "name" relationship with another "name
of date" topic.

Until reading this article, I'd been a bit uncomfortable about
this approach but now I think I've just joined the revolution!


As the article comments, the performance implications of
dynamically inferring class membership is an issue, but the
payoff in terms of simplicity is pretty large. And it does
allow searches over classes - things related to Sydney,
whether they be birth events (of people), places of
publications (of manifestations of expressions of works)
or subjects.  This is very useful in some application domains.

Kent Fitch
AustLit project
http://www.austlit.edu.au/

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com