- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 26 Sep 2016 09:41:09 -0700
- To: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
There changes make a few tiny wording changes to fix some of the wording that I point out. Some of the changes do not even rise to this level. How do "constraint parameters [...] operate" on anything. As far as I can guess from the document, constraint parameters only serve as the arguments to constraint components. There is still the fundamental problem of just what makes something a shape, a constraint, or a constraint component. It is incorrect to state things like "<code>sh:ConstraintComponent</code> is the <a>SHACL class</a> of all constraint components" given the way that SHACL instance works. Aside from the philosophical concerns about the universe of discourse, the SHACL instances of a class in an RDF graph has a particular definition. It is not the case that, for example, sh:ClassConstraintComponent is an instance of sh:ConstraintComponent in any particular shapes graph. There does not appear to have been any attempt to address this underlying problem. Peter F. Patel-Schneider Nuance Communications On 09/26/2016 12:42 AM, Holger Knublauch wrote: > I have tried to address these issues here: > > https://github.com/w3c/data-shapes/commit/d73a0f2d6b134263be63a0942edcdb0d97b882b6 > > > Thanks, > Holger > > > On 26/09/2016 16:40, Peter F. Patel-Schneider wrote: >> Section 1.1: "A shape is represented by a node in a shapes graph that is >> typically a SHACL instance of sh:Shape." >> >> A shape *is* a node in a shapes graph, not *is represented by*, at >> least according to quite a bit of wording later in the document, e.g., >> "A filter is a shape in a shapes graph". >> >> Similarly for "A valid SHACL property path p is represented by an IRI or a >> blank node". >> >> >> Section 1.1: "A shape is represented by a node in a shapes graph that is >> typically a SHACL instance of sh:Shape." >> >> Section 2: "Shapes are SHACL instances of sh:Shape" >> >> These contradict each other. >> >> Various places: "The rdf:type of [...] shapes can be omitted." >> >> Not without making them not be SHACL instances of sh:Shape. >> >> >> "Additional types of constraints can be added using SHACL Full as >> SPARQL-based constraints or SPARQL-based constraint components. " >> >> So SHACL Full can be used to add a new type of constraint disjoint from >> property and focus node constraints? >> >> Are constraint components constraints? >> >> >> "sh:PropertyConstraint is the class of property constraints. A SHACL >> processor treats all values of sh:property as property constraints. Thus, >> the values of sh:property do not require the rdf:type sh:PropertyConstraint >> triple." >> >> "sh:SPARQLConstraint is an rdfs:subClassOf sh:Constraint and is the class of >> all SPARQL-based constraints." >> >> "sh:ConstraintComponent is the class of all constraint components." >> >> "The class of" is not defined. >> >> >> "Property constraints are linked from a shape with the property >> sh:property." >> >> Here the object of a sh:property triple is a property constraint. >> >> "constraints that operate on value sets, such as sh:hasValue and sh:equals" >> >> Here the constraint appears to be the predicate of a triple. >> >> >> Peter F. Patel-Schneider >> Nuance Communications >> > >
Received on Monday, 26 September 2016 16:41:43 UTC