W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > April 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: Fri, 29 Apr 2016 10:44:32 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <36b78b3e-f130-b127-ce30-1da9b1e97fc3@topquadrant.com>
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.

Received on Friday, 29 April 2016 00:45:08 UTC

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