Re: Stand-alone Shapes and oslc:valueRange implemented in SPIN

Eric,

The Shapes submission attempted to clear up some of these questions. The 
description of the oslc:Property class [1] states there must be exactly 
one oslc:propertyDefinition (i.e. the URI of the property). However, it 
does not rule out the possibility that two different oslc:Property nodes 
might have the same oslc:propertyDefinition. The semantics is that ALL 
constraints  (i.e. the intersection) must be satisfied. IMHO, it would be 
simpler for humans reading the shape if only one oslc:Property node 
described a given property.

That being said, a oslc:Property node may have zero or more 
oslc:valueShape values. Again, all must be satified. However, 
oslc:valueShape points to shape resources, and shape resources have a 
oslc:describes property which lists the RDF types that they apply to. This 
acts like a guard or conditional check on the constraints defined by the 
check. Therefore you could specify that the property values were either 
:Male or :Female by specify both in oslc:range, and then provide different 
shapes for :Male and :Female by providing two values for oslc:valueShape. 
(It is an empirical fact that :Male and :Female have different shapes :-)

However, shapes do not let you specify the occurence of a property value 
based on its type. So a shape can say there must be 2 parents, but it 
cannot say there must be 1 :Male and 1 :Female. That is simply beyond the 
expressive power of shapes.

[1] http://www.w3.org/Submission/shapes/#Property

_________________________________________________________
Arthur Ryman
Chief Data Officer
SWG | Rational
905.413.3077 (phone) | 416.939.5063 (cell)
IBM InterConnect 2015




From:   "Eric Prud'hommeaux" <eric@w3.org>
To:     Holger Knublauch <holger@topquadrant.com>
Cc:     public-data-shapes-wg@w3.org
Date:   12/05/2014 10:40 AM
Subject:        Re: Stand-alone Shapes and oslc:valueRange implemented in 
SPIN



* Holger Knublauch <holger@topquadrant.com> [2014-12-05 08:29+1000]
> On 12/5/2014 5:08, Arthur Ryman wrote:
> >All values must satisfy the shape pointed to by oslc:valueShape.
> >OSLC has no way to specify that some values must satisfy the
> >shape.
> 
> Ok thanks Arthur for clarifying this. So Resource Shapes doesn't
> seem to have a notion of Qualified Cardinalities, while ShEx seems
> to have that (correct me if I am wrong, Eric).

Yes, hmm, I guess. The story is this: I wasn't sure what the Resource
Shapes semantics were so I documented my best guess in the ShEx
Submission. I conservatively assumed that for any given shape, only
one oslc:Property could have a given oscl:propertyDefinition. The
Lille folks called this "single occurance" (Iovka, correct me if I'm
wrong). The semantics for ShExC were intended to expand Resource
Shapes in a few ways, but I'd intended to respect "single occurance".

During the F2F, I asked what happens if more than one oslc:Property
has the same oslc:propertyDefinition and I recall Arthur saying that
all of the definitions would be permitted. I was kind of psyched
because it allowed me to meet a bunch of use cases around generic
containers. In OWL, these end up looking like QCRs which on their own
don't really help validation because nothing is invalid.

In a closed world, one says "if I haven't explicitly allowed it, it's
not allowed." This makes QCRs useful again because something like

ShExC:
  <X> { <p1> @<Foo>? , <p1> @<Bar>* }

Resource Shapes:
  <X> a rs:ResourceShape ;
      rs:property [
          rs:name "<p1>" ;
          rs:propertyDefinition <p1> ;
          rs:valueShape <Foo> ;
          rs:occurs rs:Zero-or-one ;
      ] ;
      rs:property [
          rs:name "<p1>" ;
          rs:propertyDefinition <p1> ; # <-- same property
          rs:valueShape <Bar> ;
          rs:occurs rs:Zero-or-many ;
      ] .

can mean "any <p1> that's neither a <Foo> nor a <Bar> is invalid."
I had assumed from what Arthur said during the F2F that this was his
intention, but we may have misunderstood each other.

This introduces complexity but it opens up a lot of use cases where
folks have used generic properties or generic containers. It might
be worth the work.


> To create a solution that covers all use cases I believe it would be
> helpful to (explicitly) distinguish between
> 
> a) structural declarations "which properties are relevant for a
> resource/class"
> b) arbitrary constraints "which additional conditions must be met"
> 
> The information from a) would be easy to interpret to drive user
> interfaces, e.g. it would contain the general cardinality and the
> valueType so that suitable input widgets can be selected.
> 
> The information from b) would be tested in the background, e.g. to
> validate an input form before it gets submitted.
> 
> With this categorization, oslc:valueType would be a single value in
> category a) while there can be any number of valueShapes in category
> b).
> 
> In my current prototyping, I have split spin:constraint into two
> different properties (:property and :constraint) to distinguish
> between those two categories. This also means that there would be
> something like

(Holger's later text from
 <http://www.w3.org/mid/54817076.2060803@topquadrant.com> is prefixed
 with '+'s inline)

> ex:Person
>     :property [
>         :predicate ex:parent ;
>         :valueType ex:Person ;
>         :minCount 2 ;
>         :maxCount 2 ;
>     ] ;
>     :constraint [
>         a :ShapeConstraint ;
+         :predicate ex:parent ;
>         :shape ex:MalePerson ;
>         :minCount 1 ;
>         :maxCount 1 ;
>     ] ;
>     :constraint [
>         a :ShapeConstraint ;
+         :predicate ex:parent ;
>         :shape ex:FemalePerson ;
>         :minCount 1 ;
>         :maxCount 1 ;
>     ] ;
> 
> which means that every Person must have two (biological) parents,
> one male and one female. This distinction between the "global"
> cardinality of 2 from the local qualified cardinalities would allow
> us to represent QCRs in a relatively clean way.
> 
> Eric, what do you think?

That's effectively what I've implemented, with the added constraint
that any ex:parent that's neither an ex:MalePerson nor ex:FemalePerson
is invalid. <http://w3.org/brief/NDIy> If you change one of the
genders, it'll whine. If you plan to do much editing, unclick ☑
colorized (if you don't want to play "where's my cursor?").


> Holger
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 11 December 2014 16:48:39 UTC