Re: Proposal for "Repeated Property" Requirement - sh:partition

Iovka,

sh:partition is a Property Contraint (or Inverse Property Constraint),
like sh:minCount, sh:maxCount, sh:nodeKind, etc.

sh:partition is evaluated on the set of all nodes that are values of
the property (or inverse property). It can be either open or closed,
depending on whether the last sh:QCC is a catchall constraint. The
empty QCC [ ] implies no constraints, so if that's the last one, then
the partition is in effect open.

For example,

sh:Partition ( [sh:minCount 2; sh:nodeKind sh:IRI]  [ ] )

is true if the focus node has 2 or more IRI values, and anything else.

-- Arthur

On Tue, Sep 29, 2015 at 1:14 AM, Iovka Boneva
<iovka.boneva@univ-lille1.fr> wrote:
> Arthur,
>
> I would like to be sure to understand how the Partition constraint would
> work. Here are few questions:
>
> - is Partition a constraint in the same way as the other constraints
> (sh:property, sh:NotConstraint, sh:AndConstraint, sh:OrConstraint, etc.)?
> Can it be combined with Or, And, Not ? How does it interact with these ?
>
> - is a Partition always evaluated on the whole neighbourhood ? If yes, does
> this mean that this is a "closed" costraint, in the sense that it does not
> allow any additional arcs than those specified in the QQCs of the Partition
> ?
>
> Thank you,
> Iovka
>
>
> Le 26/09/2015 01:13, Arthur Ryman a écrit :
>>
>> I've been following the discussion about repeated properties and
>> qualified cardinality constraints, and would like to propose a new
>> SHACL language element, sh:partition, that I believe will satisfy the
>> requirements.
>>
>> I the use cases suggest that SHACL needs a way to say that a set of
>> nodes must be partitioned into a certain number of disjoint subsets.
>> Each subset contains nodes that satisfy certain constraints. Each
>> subset must satisfy certain cardinality constraints.
>>
>> In the case of repeated properties, we are looking at the set of all
>> values for a given property (or inverse property) of a given focus
>> node. Sets of nodes occur in other contexts and be need to be
>> similarly constrained.
>>
>> It would be a very good thing if a SHACL processor could efficiently
>> determine if a given set of nodes could be partitioned according to a
>> given partition spec.
>>
>> SHACL already has sh:minCount and sh:maxCount properties which apply
>> to sets of nodes.
>>
>> SHACL also already has many other properties that define constraints
>> on a given node. These are tests or checks that apply to a node and
>> are either true or false. Holger listed many of them, e.g.
>> - sh:allowedValues
>> - sh:class
>> - sh:datatype
>> - sh:directType
>> - sh:minLength
>> - sh:maxLength
>> - sh:nodeKind
>> - sh:maxExclusive etc
>> - sh:pattern
>>
>> I propose to define a new RDF type, sh:QCC for things that specify
>> qualified cardinality constraints. However, sh:QCC will normally be
>> understood from the context and do not need to appear explicitly in
>> the shapes graph.
>>
>> A sh:QCC may have:
>> - zero or one sh:minCount
>> - zero or one sh:maxCount
>> - zero or more node constraints, for the following list (and possibly
>> others that make sense)
>> - sh:shape
>> - sh:allowedValues
>> - sh:class
>> - sh:datatype
>> - sh:directType
>> - sh:minLength
>> - sh:maxLength
>> - sh:nodeKind
>> - sh:maxExclusive etc
>> - sh:pattern
>>
>> A partition is specified by an rdf:List of sh:QCC nodes. Define
>> sh:Partition to be this subclass of rdf:List. Again, sh:Partition need
>> no appear explicitly.
>> A constraint may have zero or more sh:partition properties whose
>> values are sh:Partition nodes. All must be satisfied.
>>
>> The interpretation of a sh:Partition node as a constraint is as follows:
>>
>> Let the given set of nodes be X.
>> Let the sh:Partition node be the list P = (qcc1, qcc2, ..., qccn).
>>
>> For each qcc in P do the following:
>>     Let Y be the subset of X that satisfies the node constraints in qcc.
>>     If Y violates the cardinality constraints of qcc then report a
>> violation and break.
>>     Otherwise remove Y from X and continue.
>> End for.
>> If X is not empty then report a violation.
>> Otherwise report that P is satisfied.
>>
>> Note that this is a greedy algorithm. Each qcc in the list is matched
>> to the fullest extent. Nodes that match one qcc are removed from
>> further consideration. Also, the qcc's are checked in the order given
>> in the list so there is no combinatorial explosion.
>>
>> Eric proposed the following example [1]:
>>
>> <BFPersonInterface1> sh:property [
>>        sh:predicate bf:identifiedBy ; sh:pattern "^http://id.loc.gov/" ;
>>        sh:minCount 1 ; sh:maxCount 1
>>      ], [
>>        sh:predicate bf:identifiedBy ; sh:pattern "^http://viaf.org/" ;
>>        sh:minCount 1
>>      ] .
>>
>> In my proposal, this becomes:
>>
>> <BFPersonInterface1> sh:property [
>>        sh:predicate bf:identifiedBy ;
>>        sh:partition (
>>           [sh:pattern "^http://id.loc.gov/" ; sh:minCount 1 ; sh:maxCount
>> 1],
>>           [sh:pattern "^http://viaf.org/" ; sh:minCount 1 ]
>>        ) .
>>
>> [1]
>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Sep/0107.html
>>
>> -- Arthur
>>
>
>
> --
> Iovka Boneva
> Associate professor (MdC) Université de Lille
> http://www.cristal.univ-lille.fr/~boneva/
> +33 6 95 75 70 25
>
>

Received on Wednesday, 30 September 2015 00:04:43 UTC