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

Holger,

You wrote about the alternate names:
>>Doesn't work well for me, because even sh:property and sh:inverseProperty are about the focus node.
Well, they do involve the focus node in the definition of the set of
nodes they apply to, but they are not evaluated on the focus node.

Let's entertain proposals for better names.

-- Arthur

On Wed, Nov 11, 2015 at 11:16 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> 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:46:20 UTC