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

Summary:  ShEx doesn't provide qualified cardinality restrictions

On 12/06/2014 01:28 AM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-12-05 15:57-0800]
>> Even if shape constraints on the same property are supposed to be
>> unioned, I don't think that this provides qualified cardinality
>> constraints.
>>
>> A qualified cardinality constraint is something like
>>
>> HappyParent <= [2-4] child Professional |
>>                 [2-3] child (exists spouse)
>
> I wrote up this example below.
>
>> meaning that a happy parent either has between two and four children
>> who belong to the class Professional or has between two and three
>> children who have a spouse.
>>
>> This is different from having between two and four children and all
>> of their children belonging to Professional OR having between two
>> and three children and all of their children having a spouse.
>
> There are certainly multiple ways to interpret it;

Umm.  What I provided *is* the way that qualified cardinality restrictions are 
defined.

> we just need to
> find one which optimizes for some weighting of utility, generality
> and intuitiveness.

It is certainly possible to define other things, and they may perhaps be of 
more utility or intuitiveness, but they wouldn't necessarily cover qualified 
cardinality restrictions.


> Let's start by assuming we want general algebraics
> like ((N | (G & F)) & M)
>
> [[
>    <UserShape> {                          # A User has
>      (foaf:name xsd:string                #  either a foaf:name
>       | foaf:givenName xsd:string+,       #   or 1+ givenNames
>         foaf:familyName xsd:string),      #   and a family name
>      foaf:mbox IRI                        # and an mbox.
>    }
> ]]
>
> [[
>    PREFIX rs:<http://open-services.net/ns/core#>
>    PREFIX se:<http://www.w3.org/2013/ShEx/Definition#>
>
>    <UserShape> a rs:ResourceShape ;       # A User has
>      se:choice [
>        rs:property [                      #  either a foaf:name
>          rs:name "name" ;
>          rs:propertyDefinition foaf:name ;
>          rs:valueType xsd:string ;
>          rs:occurs rs:Exactly-one ;
>        ] ;
>        se:ruleGroup [
>          rs:property [                    #   or 1+ givenNames
>            rs:name "givenName" ;
>            rs:propertyDefinition foaf:givenName ;
>            rs:valueType xsd:string ;
>            rs:occurs rs:One-or-many ;
>          ] ;
>          rs:property [                    #   and a family name
>            rs:name "familyName" ;
>            rs:propertyDefinition foaf:familyName ;
>            rs:valueType xsd:string ;
>            rs:occurs rs:Exactly-one ;
>          ] ;
>        ] ;
>      ] ;
>      rs:property [                        # and an mbox.
>        rs:name "mbox" ;
>        rs:propertyDefinition foaf:mbox ;
>        rs:valueType rs:Resource ;
>        rs:occurs rs:Exactly-one ;
>      ] .
> ]]
>
> If we have that, then also interpreting
>
>    ex:child @<IsProfessional>{2,4},
>    ex:child @<HasSpouse>{2,3}
>
> as a disjunction is redundant against
>
>    ex:child @<IsProfessional>{2,4} |
>    ex:child @<HasSpouse>{2,3}

Well, sure, if there are general algebraics, then uniformly interpreting 
top-level sequences as conjunction is the way to go.

> . So what do we do with two rules with overlapping predicates? If we
> want simplicity, we can say "don't do that".

I don't think that that would gain simplicity at all.  If you allow the use of 
named shapes, then forbidding overlapping predicates would become intuitive.

> If we want to meet more
> use cases, we can say that they are QCRs.
>
>
> <http://w3.org/brief/NDIz> models your happy parent example:
>
>    <HappyParent> {
>        ex:child { a (ex:Professional) }{2,4}
>      | ex:child { ex:spouse .+ }{2,3}
>    }

Does it?  My understanding is that the meaning this would be either between 2 
and 4 children and all children are professionals OR between two and 3 
children and all children have a spouse.  This is not qualified cardinality 
restrictions.

>
> In the validation messages (green-blue box), we see that <Bif> isn't a
> happy parent 'cause he has too many kids.

Sure, <Bob> ex:child [ a ex:Professional ], [ a ex:Professional ], [ a 
ex:Student ].
also satisfies the qualified cardinality restriction, but not the ShEx shape.


>
> Note also that the '|' in ShExC (se:choice in the RDF represention) is
> *exclusive* like in XML Schema (or DTDs). That's another design choice
> or another email.
>
>
>> peter
>>
>>

peter

>> On 12/05/2014 01:53 PM, Eric Prud'hommeaux wrote:
>>> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-12-05 10:18-0800]
>>>> 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.
>>>
>>> When drafting the Submission, the intent was to respect only
>>> unqualified cardinalities (though arbitrary cardinalities, not just 0
>>> or 1): <http://www.w3.org/Submission/shex-defn/#x1-9002x1>. It wasn't
>>> until the F2F that I got the idea that intent for Resource Shapes was
>>> that multiple rules about a particular predicate to be unioned.
>>>
>>>
>>>> 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 Monday, 8 December 2014 00:31:08 UTC