Re: shapes-ISSUE-155 (property pair constraints): problems in the description of property pair constraints [SHACL Spec]

PROPOSAL: Close ISSUE-155 as handled by the current draft.

(We did quite a number of changes to the terminology over time, so I 
believe the original points have been addressed).


On 2/05/2016 13:12, Holger Knublauch wrote:
> On 29/04/2016 17:43, Peter F. Patel-Schneider wrote:
>> One problem here is that the description of property constraints 
>> defines them
>> as working independently on the objects of triples.
>> "sh:PropertyConstraint is the class of all property constraints. 
>> Given the
>> current focus node s and a provided property p, property constraints 
>> apply to
>> the object of triples with s as the subject and p as the predicate. 
>> Every
>> property constraint must provide exactly one value of p using the 
>> property
>> sh:predicate."
>> Property path constraint components do not match this description.  
>> Other
>> constraint components do not match as well, but this issue is about 
>> property
>> pair constraint components.
> (I assume you meant "property pair", not "property path").
> I don't see a problem here. Even in cases like sh:equals the 
> constraints talk about the values of property p at the focus node - by 
> comparing them to values of another property at the focus node.
>> A definition of property values would be something like
>> The values of a property p for a node n in a graph are the objects of 
>> the
>> triples in the graph that have n as subject and p as predicate.
> I have added that definition to where we also define similar terms. We 
> probably need a general "terminology" section right in the beginning 
> of the document, pulling forward what is currently in the Appendix. 
> Thoughts anyone?
> Thanks
> Holger
>> peter
>> On 04/28/2016 05:44 PM, Holger Knublauch wrote:
>>> On 28/04/2016 17:00, RDF Data Shapes Working Group Issue Tracker wrote:
>>>> shapes-ISSUE-155 (property pair constraints): problems in the 
>>>> description of
>>>> property pair constraints [SHACL Spec]
>>>> Raised by: Peter Patel-Schneider
>>>> On product: SHACL Spec
>>>> The descriptions of the property pair constraints have multiple 
>>>> problems.
>>>> They do not match the definition of property constraints because 
>>>> they are
>>>> not about the singular object of triples.
>>> I don't understand this. There are other property constraint 
>>> components that
>>> are not about singular objects, e.g. sh:maxCount. All property 
>>> constraints
>>> operate on (sets of) value nodes.
>>>> The are not allowed for inverse property constraints although they 
>>>> work just
>>>> as well for inverse property constraints as they do for property 
>>>> constraints.
>>> There would be four combinations (P=IP, IP=P,P=P,IP=IP), and I doubt 
>>> that many
>>> users will understand all this, even though it may seem tempting to 
>>> add such a
>>> generalization "because we can" from a theoretical POV. It would 
>>> also have
>>> negative impact on the structure of the SHACL data model, because it 
>>> would
>>> require allowing paths in many places. But this makes SHACL models 
>>> very hard
>>> to predict and analyze. I am against such a generalization. The 
>>> trade-offs
>>> don't make sense to me.
>>>> They refer to property values, which are not defined in the spec.
>>> So you want to define "property values"? Could you suggest a change 
>>> of the
>>> prose (I assume such a basic thing would have to go into the very 
>>> beginning of
>>> the document as this is already used in many places).
>>>> They talk about an (ordered) pair of properties but do not take an 
>>>> (ordered)
>>>> pair of properties as arguments.
>>> I don't see the term "ordered" anywhere in that context. But an 
>>> ordering is
>>> present: one is sh:predicate, and the other is, for example, 
>>> sh:lessThan. If
>>> you see specific issues, please suggest specific paragraphs.
>>> Holger

Received on Friday, 23 September 2016 04:37:19 UTC