- From: Arthur Ryman <arthur.ryman@gmail.com>
- Date: Thu, 29 Oct 2015 07:46:56 -0400
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Recall that sh:scopeClass relates a sh:Shape to an rdfs:Class so that the shape applies to all nodes of that class. Holger's rationale for his design is that sh:Arguments are constraints and sh:PropertyConstraints are shapes. I find this statement to be a case of overgeneralization and a potential source of confusion because it mixes meta-levels. Consider the circularity is the following train of thought: * Q: What is a shape? * A: A shape defines a set of constraints and possibly a scope that they apply to. * Q: What is a constraint? * A: A constraint is a validation rule that is either built-in to SHACL or is defined by an extension language, natively or via a template. * Q: What is a template? * A: A template has a set of arguments and a body written in SPARQL or another extension language. * Q: What is an argument. * A: An argument is a named input value and a description of its type. BTW, we model an argument as a constraint and a template as a shape. We need SHACL definitions to be well-founded. We should be able to define some simple SHACL things and compose them into complex SHACL things. I see no compelling reason to define sh:Argument as a kind of sh:Constraint when we have the option of separating them. sh:Argument should be simple. We can define a separate sh:ArgumentShape to validate it. That would still qualify as using SHACL to validate SHACL, but it has the benefit of not crossing meta-levels. Here is Holger's example: <code> 1) sh:Arguments are constraints. For example, if you define ex:MyTemplate a sh:ConstraintTemplate ; sh:argument [ sh:predicate ex:myProperty . sh:datatype xsd:integer . ] . and then you instantiate ex:MyShape sh:constraint [ a ex:MyTemplate ; ex:myProperty 4.2 ; ] . this would be flagged as a violation, because ex:myProperty must have xsd:integers, not psd:decimals. </code> Yes, this is certainly true, but wouldn't this logic apply to every class in SHACL, i.e. that we can define shapes to validate it? Holger is a strong proponent of combining shapes and classes but this is a debated topic. Therefore we should not enshrine this approach in the spec. We can easily define a separate shape file to validate SHACL files. Templates are not the only place where sh:scopeClass is used at a higher meta-level. It is also used in sh:NodeValidationFunction. The spec uses many RDF terms in the Advanced section but doesn't define them. These include sh:Template, sh:Constraint, etc. The spec still mentions one abstract class, sh:AbstractPropertyConstraint. If the spec uses a term then it must define it completely. The spec must be self-contained or refer to other normative references for definitions. PROPOSAL: Define the extension mechanism with minimal dependency on an underlying and undocumented class hierarchy. RDFS is not UML.
Received on Thursday, 29 October 2015 11:47:23 UTC