W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

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

From: Holger Knublauch <holger@topquadrant.com>
Date: Mon, 2 May 2016 13:12:20 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <7fcc1bcf-0726-d6f9-1946-f97420c272c4@topquadrant.com>
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?

https://github.com/w3c/data-shapes/commit/5c8a904db90be669cf50c2901e491e3fa84bfa3d

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]
>>>
>>> http://www.w3.org/2014/data-shapes/track/issues/155
>>>
>>> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC