[ba-ohs-talk] Thinking about graph structures: Fwd: [topicmapmail] Re: Emancipating Instances from the Tyranny of Class
The referenced paper gives some interesting perspective to notions of
taxonomy and so forth. While looking for a (canonical?) graph structure
that can persist objects that can then be mapped to any of a variety of
external structures (e.g. DAML, XTM, RDF, etc), I wonder if the
"emancipating" paper referenced here offers food for thought. (01)
Cheers
Jack (02)
>From: "kent fitch" <kentfitch@hotmail.com>
>To: topicmapmail@infoloom.com
>
>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/
>
>topicmapmail mailing list
>topicmapmail@infoloom.com
>http://www.infoloom.com/mailman/listinfo/topicmapmail (03)