ISSUE-95 PROPOSAL: Define the extension mechanism with minimal dependency on an underlying and undocumented class hierarchy. RDFS is not UML.

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