W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

Re: On representation and typing

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
Message-ID: <525e1219-7826-fe20-85a0-98c39d3b7fad@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:44 UTC