- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 13 Jan 2017 08:36:55 +1000
- To: public-data-shapes-wg@w3.org
On 13/01/2017 3:14, Eric Prud'hommeaux wrote:
> * Irene Polikoff <irene@topquadrant.com> [2017-01-12 12:05-0500]
>> Hi Eric,
>>
>> I hope your proposal could be restored.
I had moved some documents into a sub-folder on github, and forgot to
update the reference. I have now updated the reference to the Abstract
Syntax on the main page:
https://www.w3.org/2014/data-shapes/wiki/Main_Page#Deliverables
The deep link should then be
http://w3c.github.io/data-shapes/unmaintained/shacl-abstract-syntax/#satisfies-PartitionConstraint
>>
>> Since partitioning was not a goal, but a way to address these use cases and SHACL has QualifiedValueShape for the first use case and an OR for the second use case, do you think the use cases are addressed or is there still something missing?
> Partitioning was not a goal but was the only way we found of providing
> a satisfactory user experience. While qualified cardinality
> restrictions can capture top-level repeated properties, they become
> quite a burden to author and maintain. Likewise, exploding every OR
> with a negation of the DNF of the other disjuncts requires diligence
> and is tedious and error prone if the disjuncts have any complexity to
> them.
Let's assume we want to express that an old-fashioned Marriage consists
of one female and one male member, making sure no instance is counted
twice (i.e. male and female at once). With the current QCRs that would
be expressed using
ex:MarriageShape
a sh:NodeShape ;
sh:property [
sh:predicate ex:member ;
sh:qualifiedMinCount 1 ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedValueShape [
sh:shape ex:MaleShape ;
sh:not ex:FemaleShape ;
] ;
] ;
sh:property [
sh:predicate ex:member ;
sh:qualifiedMinCount 1 ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedValueShape [
sh:shape ex:FemaleShape ;
sh:not ex:MaleShape ;
] ;
] .
In cases of complex expressions and many combinations this could indeed
become a bit complex to write (unless it's produced by an algorithm
anyway such as the converter from Compact Syntax to RDF).
However, it seems easy to add a flag to the shape to indicate whether
it's supposed to interpret the value shapes as being disjoint, e.g.
ex:MarriageShape
a sh:NodeShape ;
sh:qualifiedValueShapesDisjoint true ;
sh:property [
sh:predicate ex:member ;
sh:qualifiedMinCount 1 ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedValueShape sh:shape ex:MaleShape ;
] ;
sh:property [
sh:predicate ex:member ;
sh:qualifiedMinCount 1 ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedValueShape ex:FemaleShape ;
] .
Would such a flag help? We could delete sh:partition and would "just"
need to update the definition of how qualified value shapes are
interpreted, basically adding sh:not statements for all sibling QCRs on
the same predicate. I must be missing something obvious?
Holger
>
>
>> Irene
>>
>>> On Jan 12, 2017, at 6:00 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
>>>
>>> Originally, ShEx (a surface syntax for ResourceShape plus OR) didn't have partitions. It was added to:
>>>
>>> 1 address the frequent (and encouraged) reuse of generic properties. These are extremely common in clinical data, for instance a BP observation has two components, one of which has a code for systolic and the other a code for diastolic.
>>>
>>> 2 provide an OR that was closer to user expectations and reduced the need for defensive programming, e.g a shape expecting either a name or a given and family name should reject a mixture like { <s> foaf:name "X"; foaf:givenName "Y" }.
>>>
>>> Partitioning was never a goal; it was a means of satisfying these needs.
Received on Thursday, 12 January 2017 22:37:34 UTC