Re: shapes-ISSUE-103 (Syntax simplifications): Can we further simplify the syntax of some constraint types? [SHACL Spec]

On 11/12/15 1:38 PM, Arthur Ryman wrote:
> Holger,
>
> I propose the following for ISSUE-103:
>
> There are three distinct types of constraints. Each type applies to a
> set of nodes. They differ in how the set of nodes is determined.
>
> Each of these types of constraints may contain a set of properties
> that define restrictions on the set of nodes. A restriction is defined
> by a subset of one or more properties of the constraint, e.g.
> sh:nodeKind or sh:qualifiedValueShape+sh:qualifiedMinCount. The
> constraint is violated only if at least one of the restrictions is
> violated.
>
> 1. sh:property links a shape to a sh:PropertyConstraint. A Property
> Constraint applies the set of nodes that are objects of triples that
> have the focus node as the subject and a given predicate. The
> predicate is specified by the property sh:predicate.
>
> 2. sh:inverseProperty links a shape to a sh:InversePropertyConstraint.
> An Inverse Property Constraint applies to the set of nodes that are
> subjects of triples that have the focus node as the object and a given
> predicate. The predicate is specified by the property sh:predicate.
>
> 3. sh:constraint links a shape to a sh:NodeConstraint. A Node
> Constraint applies to the singleton set consisting of just the focus
> node.

Yes this is (roughly) how I would like to explain SHACL in the spec too. 
But I have stopped my editing efforts because I first need to see a 
resolution to the specific syntax proposals that I made, e.g. replacing 
sh:OrConstraint/sh:shapes with sh:or. Without this, I could not 
consistently explain sh:constraint in the same way that the other types 
are explained.

>
> Some alternate names to emphasize the focus node aspect:
> sh:constraint -> sh:atFocus
> sh:NodeConstraint -> sh:FocusConstraint

Doesn't work well for me, because even sh:property and 
sh:inverseProperty are about the focus node.

Holger


>
> -- Arthur
>
> On Thu, Nov 5, 2015 at 3:35 PM, Holger Knublauch <holger@topquadrant.com> wrote:
>> I have no strong opinion. We could theoretically make the use of
>> sh:PropertyConstraint illegal at sh:constraint. You should make a proposal
>> if you believe this is important. I can see arguments going both ways. Even
>> if we made these disjoint, it would still be possible to constrain
>> properties at sh:constraint, e.g. using sh:and/sh:AndConstraint.
>>
>> Holger
>>
>>
>> On 11/6/15 3:03 AM, Arthur Ryman wrote:
>>> Holger,
>>>
>>> Wouldn't it be more orthogonal if there was no relation between
>>> sh:constraint, sh:property, and sh:inverseProperty? Each of these
>>> properties has different semantics for what they apply their node
>>> constraints to.
>>>
>>> 1. sh:constraint applies node constraints directly to the singleton
>>> set that contains just the current focus node.
>>> 2. sh:property applies node constraints to the set of nodes that are
>>> objects of triples that have the current focus node as subject and the
>>> value of sh:predicate as the predicate.
>>> 3. sh:inverseProperty applies node constraints to the set of nodes
>>> that are subjects of triples that have the current focus node as
>>> object and the value of sh:predicate as the predicate.
>>>
>>> -- Arthur
>>>
>>> On Wed, Nov 4, 2015 at 6:32 PM, Holger Knublauch <holger@topquadrant.com>
>>> wrote:
>>>> On 11/5/2015 9:27, Peter F. Patel-Schneider wrote:
>>>>> On 11/04/2015 03:24 PM, Holger Knublauch wrote:
>>>>> [...]
>>>>>> This is correct, as long you add an rdf:type triple, which your example
>>>>>> didn't.
>>>>>>
>>>>>> The following would be legal:
>>>>>>
>>>>>> sh:constraint [
>>>>>>        a sh:PropertyConstraint ;
>>>>>>        sh:class ex:c ;
>>>>>>        sh:predicate ex:p
>>>>>> ]
>>>>>>
>>>>>> However, even then sh:PropertyConstraint cannot have sh:not, which is
>>>>>> limited
>>>>>> to sh:NodeConstraint.
>>>>>>
>>>>>> Holger
>>>>>>
>>>>> So
>>>>>
>>>>> sh:constraint [
>>>>>         a sh:PropertyConstraint ;
>>>>>         a sh:NodeConstraint ;
>>>>>         sh:class ex:c ;
>>>>>         sh:predicate ex:p;
>>>>>         sh:not [...]
>>>>>     ]
>>>>>
>>>>> is OK?
>>>>
>>>> Yes, although at evaluation time there is no relationship between the
>>>> sh:not
>>>> and the property constraints. So this is not a case we would want to
>>>> promote
>>>> or encourage.
>>>>
>>>> Holger
>>>>
>>>>
>>

Received on Thursday, 12 November 2015 04:17:00 UTC