[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

[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)

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
>topicmapmail mailing list
>http://www.infoloom.com/mailman/listinfo/topicmapmail    (03)