plural vs singular properties (a proposal)

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