Re: plural vs singular properties (a proposal)

> >>> 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
> >>
> >> Since it ensures neither, I think style 2 is a huge anti-pattern. I
> >> recommend it against it always.
> >
> > Can you explain this?
> 
> I have that power.

Indeed.  And I thank you for exercising it.

> > In what sense are the elements in the list not ordered?
> 
> They are ordered but that order is neither really "semantic" nor is  
> it intention revealing. For example, the canonical use of rdf:List is  
> in OWL syntax where it  represents an unordered collection (at some  
> level).
> 
> For example, I can add, without difficulty, the following statement  
> to your turtle:
> 	p:Charles f:children ( p:Harry p:William  ).

Not if f:children was an owl:FunctionalProperty.  I didn't get into
that, but I would expect one would usually want it to be.

> But more to the point, even  if they *are* ordered, and you exploit  
> that order, it's not a good way to achieve the *modeling* of the  
> ordering in question. Usually there are many orderings (age, grades,  
> number of hair follicles, height).  The *significance* of the  
> ordering above is pretty clearly age, but then why not model that? In  
> both cases, *recognizing* the order comes from outside.
> 
> This is an old point from relational database design.

In general, I agree with this principle, but what about

  (1) When the ordering is only significant in the context of the
      relationship, such as with the words of a sentence, or the slides
      in a particular slideshow (which are arranged to make a rhetorical
      point)....?

  (2) When users want quick results -- they don't want to think through
      the semantics behind the ordering -- they just know what order the
      items belong in.

?

> > By "exhaustive", just to be clear, I mean that using Style 2 one can
> > define "children" such that when we list Charles' children we are also
> > saying these are his *only* children.
> 
> But you aren't saying that.

That's what users seem to me to be saying when they (including the OWL
RDF syntax) are using rdf:List.   I understand it's not always formally
or even informally stated.

> Add:
> 
> 	p:Charles f:children ( p:Janice ).
> 
> Who are p:Charles' children?

I believe my semantics, in both English and FOL, would render that
merged graph inconsistent.  

> rdf:Lists are misleading thus, even aside from their lack of decent  
> formal semantics: they are not very intention revealing either.  
> Eschew, eschew!

Thanks, it is, in fact, lunch time.  :-]

> >   Is your point that such a
> > constraint on p:children can't be specified in OWL?
> 
> No.
> 
> > Alan points out that one can do that with OWL maxCardinality.  To do
> > that, you'd need to introduce classes like ParentWithTwoKids,
> > ParentWithThreeKids,
> 
> Not even a little bit.
> 
> > etc, and then say:
> >
> >      p:Charles a f:ParentWithTwoKids;
> >                f:child p:William, p:Harry.
> > right?
> 
> Nope.
> 
> 	p:Charles a [a Restriction; onProperty f:child; cardinality "2"];
> 		f:child p:William, p:Harry.

Perhaps I wasn't clear.  I was assuming

       f:ParentWithTwoKids rdfs:subClassOf [a owl:Restriction; 
                                            owl:onProperty f:child; 
                                            owl:cardinality "2"].

so that we wouldn't have to repeat the Restriction triples for each such
parent.  But I get your point that you don't have to name them, since
naming implies a kind of advance planning that isn't actually needed
here.  So it's easy enough to state that one is providing exhaustive
information.

     - Sandro

Received on Monday, 23 April 2007 15:59:26 UTC