- From: Sandro Hawke <sandro@w3.org>
- Date: Sun, 22 Apr 2007 20:47:55 -0400
- To: semantic-web@w3.org
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
Received on Monday, 23 April 2007 00:48:38 UTC