Re: ISSUE-95: Template Simplifications

Here is my proposal for a better simplification, based on changes to Part 2 of
http://w3c.github.io/data-shapes/shacl/index-ISSUE-95.html.   The basic idea
is to
1/ get rid of template injection, instead using supertemplates, which I think
can do everything needed;
2/ get rid of abstract classes;
3/ get rid of validation functions, as they are not needed; and
4/ get rid of functions, as there is no way to call them.



Part 2 of the SHCAL spec is very hard to read.  It has quite a few undefined
terms, and depends on several very difficult-to-do operations.  It is
insufficiently specific in many places.

I here propose several changes the normative bits of the version of Part 2
that was prepared for ISSUE-95,
http://w3c.github.io/data-shapes/shacl/index-ISSUE-95.html, that fix many of
the problems there.  I have not proposed changes for any of the bits marked
non-normative or any of the examples.


6.2

The SPARQL queries linked to a constraint via sh:sparql must be string
literals that can be parsed into legal SPARQL 1.1 queries of the query form
SELECT.
->
The values for sh:sparql must be either the empty string literal ("") or
string literals that are can be parsed into legal SPARQL 1.1 queries of the
query form SELECT.  The empty string literal indicates a vacuous constraint,
i.e., one that never produces any violations.

7.

All of the constraint and scope types built into the SHACL Core are also
represented as templates in the SHACL RDF vocabulary. Such templates form a
high-level vocabulary that may also be directly interpreted ("hard-coded")
without reliance on the fact that they are templates.
->
(All of the constraint and scope constructs built into the SHACL Core can be
implemented as templates.)

SHACL also includes a more general superclass sh:Template that may be used
for other kinds of templates (rules, stored queries etc). Well-defined,
non-abstract templates must provide at least one body using a property such
as sh:sparql.
->
Well-defined templates must provide at least one body using a property such
as sh:sparql.

7.4

[All of 7.4]
->
It is sometimes desirable to mix multiple templates so that
they can be used within the same constraint.  This is done by making a
template class that is a subclass of multiple other template classes.  An
instance of the child template class then combines the effects of all these
templates, because it is an instance of them all.

7.6

If a sh:PropertyValueConstraintTemplate has a value for
sh:validationFunction, ... [to end of section]
->
[empty]


8

All this is analogous to how constraints work, but with
the additional restrictions:
* All subjects of sh:scope triples must be IRIs
* The arguments of a scope template must not be blank nodes
->
All this is analogous to how constraints work.

8.1

The SPARQL queries linked to a scope via sh:sparql must be of the query form
SELECT, or a fragment that produces a valid SELECT query if wrapped by
SELECT ?this WHERE { ... }. The SELECT queries must project to the result
variable ?this.
The SELECT queries must also be executable when converted to an ASK query
and with a pre-bound value for ?this. The set of bindings for ?this that
return true for such ASK queries must be identical to the set produced by
the SELECT query. This constraint makes sure that engines can validate
whether a given shape applies to a given focus node as part of the
validateNode operation.
->
The SPARQL queries linked to a scope via sh:sparql must be of the query form
SELECT ?this WHERE { ... }.


9

[Remove entirely, as there is no defined way to call functions.]

Well-defined, non-abstract functions must provide at least one
body property such as sh:sparql.
->
Well-defined functions must provide at least one
body property such as sh:sparql.

9.4

[Remove, if implementations want to analyze functions to see if they are
chachable they are free to do so.]

9.5

[Remove, as implementing this will require parsing and modifying SPARQL
bodies.]

Received on Thursday, 29 October 2015 04:14:32 UTC