ISSUE-79: Cleaner separation between value checking and property iteration

Validation functions

Cleaner separation between value checking and property iteration

State:
CLOSED
Product:
SHACL Spec
Raised by:
Holger Knublauch
Opened on:
2015-08-13
Description:
I was never quite happy with one aspect of how SHACL templates (including the Core templates) were internally defined. To illustrate the problem, this is how sh:datatype is currently defined:


sh:AbstractDatatypePropertyConstraint
a sh:ConstraintTemplate ;
rdfs:subClassOf sh:AbstractPropertyConstraint ;
...
sh:message "Values must have datatype {?datatype}" ;
sh:sparql """
SELECT ?this (?this AS ?subject) ?predicate ?object ?datatype
WHERE {
?this ?predicate ?object .
FILTER (!sh:hasDatatype(?object, ?datatype)) .
}
""" ;
.

The SPARQL query above does two things:
a) It iterates over all property values
b) It FILTERs each of these values.

This is a recurring pattern for many property constraints. I would like us to make this design pattern more explicit so that it becomes the following:

sh:AbstractDatatypePropertyConstraint
a sh:PropertyValueConstraintTemplate ;
rdfs:subClassOf sh:AbstractPropertyConstraint ;
...
sh:message "Values must have datatype {?datatype}" ;
sh:validationFunction sh:hasDatatype ;
.

Instead of pointing at a SPARQL query that does everything, such constraints only point at a Function, which must take a value as input and return a boolean. The engine can produce the surrounding SPARQL automatically, and can even directly inject the body of the sh:hasDatatype function.

This design has the following advantages:
- It makes the contract more explicit, modular and arguably cleaner
- It allows to focus on what really matters, reducing clutter
- It makes it easier to reuse the logic, especially for inverse property constraints (and sh:Arguments)
- It makes it easier to optimize execution - if only a boolean result is needed, then a code generator can more easily combine them into a single FILTER such as sh:hasDatatype(...) && sh:hasNodeKind(...)
- It lowers the implementation costs for other languages like JavaScript - these can focus on implementing the functions
- It raises the abstraction, e.g. in JavaScript these checks can be simple variable comparisons, regardless of how the surrounding iteration happened
- The key snippets are also reusable inside of SPARQL expressions, because they are also SPARQL functions.

The only disadvantage that I can think of is that there is a little bit more work for the engine implementers, because this requires a couple of new classes and properties to work correctly. However, I'd rather push the complexity to the engine developers and have a cleaner overall design for the end users. And, nobody is forced to use this new pattern - anyone can still use the current mechanism using sh:sparql.

I have implemented this on a test branch, and a new Turtle file can be found here:

https://github.com/w3c/data-shapes/blob/ISSUE-79/shacl/shacl.shacl.ttl

I have not yet updated the textual documents - I'd love to hear from others on the general direction before I spend more time on this.
Related Actions Items:
No related actions
Related emails:
  1. Re: review of SHACL document (First pass of responses) (from holger@topquadrant.com on 2015-09-02)
  2. Re: shapes-ISSUE-81 (Property pair constraints): Shall SHACL Core include support for disjoint properties and other property pair constraints? [SHACL Spec] (from holger@topquadrant.com on 2015-08-21)
  3. Re: RDF Data Shapes Agenda for 20 August 2015 (from lehors@us.ibm.com on 2015-08-20)
  4. Re: RDF Data Shapes Agenda for 20 August 2015 (from pfpschneider@gmail.com on 2015-08-19)
  5. Re: shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec] (from lehors@us.ibm.com on 2015-08-18)
  6. Re: shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec] (from holger@topquadrant.com on 2015-08-14)
  7. Re: shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec] (from simon.steyskal@wu.ac.at on 2015-08-13)
  8. Re: shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec] (from holger@topquadrant.com on 2015-08-13)
  9. Re: shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec] (from simon.steyskal@wu.ac.at on 2015-08-13)
  10. Re: shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec] (from holger@topquadrant.com on 2015-08-13)
  11. Re: shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec] (from simon.steyskal@wu.ac.at on 2015-08-13)
  12. shapes-ISSUE-79 (Validation functions): Cleaner separation between value checking and property iteration [SHACL Spec] (from sysbot+tracker@w3.org on 2015-08-13)

Related notes:

Resolution: Close ISSUE-79, per Holger's proposal
See http://www.w3.org/2015/08/20-shapes-minutes.html#resolution03

Arnaud Le Hors, 21 Aug 2015, 21:19:01

Display change log ATOM feed


Irene Polikoff <irene@topquadrant.com>, Ted Thibodeau <tthibodeau@openlinksw.com>, Chairs, Sandro Hawke <sandro@w3.org>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: index.php,v 1.325 2014-09-10 21:42:02 ted Exp $