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

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.


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.


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 Friday, 29 April 2016 07:43:35 UTC