W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > September 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, 23 Sep 2016 14:36:41 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <ed892476-e2cf-94cb-8b1b-22854dff66bc@topquadrant.com>
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).

Holger


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?
>
> 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 Friday, 23 September 2016 04:37:19 UTC

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