- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 23 Sep 2016 14:36:41 +1000
- To: public-data-shapes-wg@w3.org
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