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

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?


> 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 Monday, 2 May 2016 03:12:52 UTC