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

Do ShEx or ShExC or Shape Expressions actually have qualified cardinalities?

http://www.w3.org/Submission/shex-defn/ appears to indicate that a shape 
expression of the form <p1> @<foo> ? only matches when there are zero or one 
p1's *and* all of the p1's belong to foo.

peter


On 12/05/2014 07:39 AM, Eric Prud'hommeaux wrote:
> * 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
>>
>>
>

Received on Friday, 5 December 2014 18:19:08 UTC