- From: Russell Duhon <fugu13@mac.com>
- Date: Wed, 21 Dec 2005 12:24:21 -0500
- To: Joshua Allen <joshuaa@microsoft.com>
- Cc: tim.glover@bt.com, fmanola@acm.org, semantic-web@w3.org
- Message-Id: <185E765E-AA57-4043-8227-7C2737475286@mac.com>
I think the second in particular is clearly counter to RDF's construction. Properties are as flexible as they are for good reason, and it will often be silly to exhaustively list the types that apply (or even their most specific subclass) to a given node, instead just using the properties for various additional types as appropriate. As for the first, my general preference would be to avoid making it so schema/contracts cannot match in many cases. In that line, one approach I'm taking right now is something I'm calling Event-Actor. I declare there are event nodes that certain fairly generic actors can participate in in various ways, and then I declare subclasses of the fairly generic actor class(es) to be equivalent classes to the appropriate actor class intersection participation in one or more particular events. Instances are only declared as being a fairly generic actor class, and inference is used to determine subclasses that are appropriate. For instance, I might talk about a Person as a fairly generic actor class, and have an Adoption event, with maybe an isAdopted/adoptedIn property/inverse pair. Then an AdoptedChild would be any Person with an adoptedIn cardinality 1 or greater. All I need to do is declare instances as people, and make them participants in the appropriate events as I go. Then when I want all the AdoptedChild instances, I can just retrieve those from my inferencing store, and find out who (for instance) their AdoptiveParent(s) are by following some properties off of the attached Adoption events. This particularly makes sense with systems involving time progression, where events are evident, such as where I am currently applying it, in an ontology for a webcomic. Particularly as this webcomic can involve many wonky things (such as humans turning into rabbits due to crossing alternate reality barriers), I avoid stating disjointness, and since I never declare anything as one of the subclasses designed for inference, I can't ever find an instance of a subclass that doesn't obey the appropriate "contract" -- that's why it was determined to be that subclass in the first place, because it fulfilled the contract. Heh, I managed to ramble a bit there. Russell On Dec 21, 2005, at 12:00 PM, Joshua Allen wrote: >> type systems in computer languages. That may have been the original >> intention but the ability to enforce types is in conflict with the >> requirement that all RDF statements are valid, and the RDF semantics > > Right; the part I am concerned about is the consumption patterns, > though. There is an inherent bias in many development communities > to do > the following sorts of things: > > 1) Look at some RDF; if the rdf:type is present, and the schema/ > contract > does not match, ignore it or fail fatally. This is the "postel was > wrong" philosophy that underlies XML (and is appropriate for XML). > > 2) Look for rdf:type first, and use it as a switch to determine > whether > to look for particular predicates. In other words, type is the first > filter, and things that do not match type fall through the bottom. > > > I believe both sorts of patterns are appropriate in enterprise > development, certain interop scenarios, and for example XSD, WSDL, > etc. > But for semantic web they would be fatal (IMO).
Received on Wednesday, 21 December 2005 17:24:40 UTC