- From: David Price <david.price@eurostep.com>
- Date: Mon, 23 Apr 2007 10:12:56 +0100
- To: semantic-web@w3.org
Seems like the singular property is closer to the semantics - the relationship is between a Person who is a parent and a Person who is a child, not a Person who is a parent of a SetOfPerson who are children. Contracts that with a Person who is the coach of a SetOfPerson who are a football team. I'd also suggest that letting how OO programming systems work influence accurate semantics may lead to mistakes. OO programming languages are largely about shared behaviour, not shared semantics (e.g. the "is circle kind of ellipse" debate). Cheers, David On Monday 23 April 2007 01:47, Sandro Hawke wrote: > I keep running into a problem with modeling in RDFS/OWL where I don't > know whether to use a multi-valued singular property or a single-valued > plural (collection) property. For example: > > Style 1 - Singular Property > > Turtle: p:Charles f:child p:William, p:Harry. > > N-Triples: > p:Charles f:child p:William . > p:Charles f:child p:Harry . > > Style 2 - Plural (Collection) Property > > Turtle: p:Charles f:children ( p:William p:Harry ). > > N-Triples: > p:Charles f:children _:genid2 . > _:genid2 rdf:first p:William . > _:genid2 rdf:rest _:genid1 . > _:genid1 rdf:first p:Harry . > _:genid1 rdf:rest rdf:nil . > > I believe the dominant opinion is that one should use Style 1 unless one > needs one of the key features of Style 2, which are roughly: > a. the values are ordered > b. the values are exhaustive > > I've never liked having to make that tradeoff, and I think I now see a > way to get out of it. > > My current perspective comes from my current focus, which is on > exploring how OWL lines up (and fails to line up) with object-oriented > programming systems. As far as I know, OO systems always use Style 2, > since they don't (directly) support multi-valued properties. In a > conventional programming language, we'd always have something like > person.children or person.childList, never person.child. This, to me, > increases to need to merge the two styles. > > The solution I propose is to add another triple: > > f:child p:plural f:children > > which would allow the two styles to intermingle. > > That triple means that every value for any subject's f:child property is > present in that subject's f:children list. (And visa versa: every > element of the f:children list is a value for the f:child property.) > > Formally (in Otter's FOL syntax, as I used in Surnia): > > % define p_plural > all SingularProperty PluralProperty ( > rdf(SingularProperty, p_plural, PluralProperty) > <-> > all Subject Value ( > rdf(Subject, SingularProperty, Value) > <-> > exists List ( > rdf(Subject, PluralProperty, List) & > inList(Value, List) > ) > ) > ). > > % define inList(X,L) -- true iff X is in rdf list L > all Element List ( > inList(Value, List) > <-> > ( rdf(List, rdf_first, Value) > > | exists Rest ( > > rdf(List, rdf_rest, Rest) & > inList(Value, Rest) > ) > ) > ) > all Element (-inList(Element, rdf_nil)). > > I believe these semantics would have some interesting and useful > consequences: > > * You can constrain the type of members of a list by > linking it to a property and constraining the type of > that property. For example: > > f:child p:plural f:children. > f:child rdfs:range foaf:Person. > eg:foo f:children eg:bar. > > constrains eg:bar to be an RDF list which contains only > foaf:Person instances. > > * You can constrain the cardinality of the set of elements in a > list in the same manner (using OWL cardinality axioms). This > does not constrain the number of elements in the list, unless > they are otherwise constrained to be distinct. (Hmmm. Should > p:plural do that, too? I'm not sure I know how to safely > specify that. It could be nice, though.) > > * Content providers can use either or both properties. Content > consumers can use either or both properties, if inference is > provided to implement the above semantics. > > * Content providers should avoid the plural property unless they want > to be exhaustive. (There is some wiggle room here for using > open-ended lists, but I think that's best avoided.) > > Thoughts? Reasons why this is great? Reasons why this wont work? > > -- Sandro -- Mobile +44 7788 561308 UK +44 2072217307 Skype +1 336 283 0606 http://www.eurostep.com
Received on Monday, 23 April 2007 09:13:05 UTC