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

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.

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

-- 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 03:39:07 UTC