Re: plural vs singular properties (a proposal)

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