syntax.text

= A modest proposal for a refactored SHACL =

== Introduction ==

=== Major Changes ===

==== Collapsing Shapes and Constraints ====

The central change in this proposal is to collapse constraints and shapes into one
construct.  Instead of, for example, having sh:or and similar component properties
take shapes as arguments and produce constraint components they take shapes and
produce shapes.  This results in smaller shapes and a more uniform syntax, replacing

  ex:s1 a sh:Shape ;
    sh:constraint [
      a sh:NodeConstraint ;
      sh:or
        ( [ a sh:Shape ;
            sh:constraint [
              a sh:NodeConstraint ;
              sh:class ex:Person
              ]
            ]
          [ a sh:Shape ;
            sh:constraint [
              a sh:NodeConstraint ;
              sh:in ( ex:elvis )
              ]
            ] )
      ] .
           
with

  ex:s1 a sh:Shape ;
    sh:or
      ( [ a sh:Shape ;
          sh:class ex:Person
          ]
        [ a sh:Shape ;
          sh:in ( ex:elvis )
        ] ) .
        
==== No Property or Inverse Property Constraints ====

There is also no longer any division between node constraints/shapes, property
constraints/shapes, and inverse property constraints/shapes.  The difference in
behaviour between node, property, and inverse property constraints/shapes is instead
controlled by the link to the constraint/shape from its enclosing shape.  When
processing a shape the objects of sh:property links in the shape are treated as
shapes on the values of the sh:predicate argument and the objects of
sh:inverseProperty links are treated as shapes on the values of the inverse of the
sh:predicate arguments.  This change replaces

  ex:s1 a sh:Shape ;
    sh:constraint [
      a sh:PropertyConstraint ;
      sh:predicate ex:parent ;
      sh:shape [
        a sh:Shape ;
        sh:constraint [
          a sh:PropertyConstraint ;
          sh:predicate ex:parent ;
          sh:shape [
            a sh:Shape ;
            sh:constraint [
              a sh:PropertyConstraint ;
              sh:predicate ex:age ;
              sh:minExclusive 50
              ]
            ]
          ]
        ]
      ] .

with 

  ex:s1 a sh:Shape ;
    sh:property [
      a sh:Shape ;
      sh:predicate ex:parent ;
      sh:property [
        a sh:Shape ;
        sh:predicate ex:parent ;
        sh:property [
          a sh:Shape ;
          sh:predicate ex:age ;
          sh:minExclusive 50
          ]
        ]
      ] .

A previous version of this proposal pulled the sh:predicate constructs out of the
shapes and had sh:property take a two-element list, resulting in

  ex:s1 a sh:Shape ;
    sh:property ( ex:parent [
      a sh:Shape ;
      sh:property ( ex:parent [
        a sh:Shape ;
        sh:property ( ex:age [
          a sh:Shape ;
          sh:minExclusive 50
          ] )
        ] )
      ] ) .

The result of these two changes is that there is only one major combining construct
in the syntax - shapes.  There are no longer any constraints, or any of the various
subcategories of constraints.

=== Other Changes ===

There are several other changes made in this proposal that are somewhat
orthogonal to the central changes.

==== Single-Argument Components ====

Each component of a shape consists of a single triple attached to the shape.  If a
component needs more than a single parameter then its parameters are bundled into a
single node.  So a pattern component would not have an optional flag parameter but
would use a single composite parameter when a flag is present, either a list as in

  ex:s2 a sh:Shape ;
    sh:pattern ( "^John" "i" ) .

or a node with its own properties as in

  ex:s2 a sh:Shape ;
    sh:pattern [ sh:regex "^John" ; sh:flags "i" ] .

instead of

  ex:s2 a sh:Shape ;
    sh:constraint [
      a sh:NodeConstraint ;
      sh:pattern "^John" ;
      sh:flags "i"
      ] .

==== Repeated Components ====

Constraint components can be repeated, replacing 

  ex:s3 a sh:Shape ;
    sh:constraint [
      sh:and
        ( [ a sh:Shape ;
            sh:constraint [
              a sh:NodeConstraint ;
              sh:class ex:Person
              ] ]
          [ a sh:Shape ;
            sh:constraint [
              a sh:NodeConstraint ;
              sh:class ex:Alien
              ] ] ) .

with

  ex:s3 a sh:Shape ;
    sh:class ex:Person ;
    sh:class ex:Alien .

==== Property Paths ====

Paths of properties and their inverses are allowed instead of just single properties.
A new construct, with property sh:propValues, is used for this, replacing sh:property
and sh:inverseProperty. '''The name is not great and probably should be changed.'''

Property paths permit the shape at the beginning of this document to be written as

  ex:s1 a sh:Shape ;
    sh:propValues [
      a sh:Shape ;
      sh:path ( ex:parent ex:parent ex:age ) ;
      sh:minExclusive 50
      ] .

or using the older list syntax as 

  ex:s1 a sh:Shape ;
    sh:propValues ( ( ex:parent ex:parent ex:age ) [
      a sh:Shape ;
      sh:minExclusive 50
      ] .

==== RDFS Typing in Shape Graphs ====

This proposal removes the need for most shapes include an explicit rdf:type link to
sh:Shape.  It does this by using rdfs:domain and rdfs:range for various properties,
which are given in the metamodel for SHACL, and then using RDFS typing for the shapes
graph.  If all shapes have explicit typing then there is no need for this mechanism.

==== Readable Strings are rdfs:langString ====

All strings that contain language to be presented to users are of type
rdf:langString.

=== What Follows ===

The details of the proposal follow.  To set the context of the proposal there are
preamble and conformance sections.  Then there are sections on the core syntax, an
informal semantics, and an extension mechanism.  Each of these three sections builds
on the previous, but the syntax changes are independent of the semantics which is
independent of the extension mechanism.



== Preamble ==

SHACL is designed to determine whether some information satisfies a set of
conditions.  This process is called validation in SHACL.  The main functionality
provided by a SHACL engine is to determine whether one RDF graph, called the
''data graph'' and containing the information to be validated, validates against another RDF
graph, containing the conditions and called the ''shapes graph'' because the main
syntactic construct in SHACL is the shape.  Data graphs and nodes in the data graph
are said to validate against shapes and shapes graphs.

SHACL is divided into a core portion and an extension portion.  The extension portion
of SHACL uses SPARQL 1.1 Query Language queries from the shapes graph in validation.

This document uses Turtle syntax for graphs and nodes, with the following prefix
bindings:

  rdf:  http://www.w3.org/1999/02/22-rdf-syntax-ns#
  rdfs: http://www.w3.org/2000/01/rdf-schema#
  xsd:  http://www.w3.org/2001/XMLSchema#
  sh:   http://www.w3.org/ns/shacl#

SHACL depends on a notion of instance that uses vocabulary from RDF (rdf:type) and
RDFS (rdfs:subClassOf) but in a way different from both.  A node is a ''SHACL instance''
in the data graph of another node precisely when there is a triple in the data graph
with the instance node as subject, rdf:type as predicate, and object that is either
the other node itself or is linked to that node via a chain of triples in the data
graph each with rdfs:subClassOf as predicate.

All SHACL constructs described here are composed only of triples in the shapes graph.

SHACL uses lists in the shapes graph in its syntax.  The ''list nodes'' of a node in the
shapes graph are defined as the nodes in transitive-reflexive closure of rdf:rest
triples in the shapes graph considered as a directed relationship between nodes.  A
node in the shapes graph is a SHACL ''list'' precisely when
#rdf:nil is one of its list nodes,
#all its list nodes have a single rdf:rest, except that rdf:nil has none, and 
#all its list nodes have a single rdf:first, except that rdf:nil has none.
The rdf:first values for the list nodes are the ''elements'' of the list, in order.
A list where all the elements have some characteristic is called a
''list of that characterstic'', e.g., a list where all the elements are IRIs
is called a list of IRIs.

The objects of triples with a given subject and predicate are ''values'' of the predicate
for the subject.  That subject is said to have these objects for the predicate.

== Conformance ==

A SHACL validation engine MUST provide an interface that validates a data graph
against a shapes graph containing core SHACL constructs, as described herein, and
returns all the validation results for each scoped shape in the shapes graph.  A SHACL
validation engine MAY provide other interfaces that return only some of the
validation results.  These other interfaces MUST also return a boolean result that is
true only if this set is the entire set of validation results.  A SHACL validation
engine MAY provide an interface that returns true if there is at least one validation
result with severity sh:Violation, false otherwise.

If the shapes graph provided to it is syntactically illegal a SHACL
validation engine MUST so signal.  The engine MAY try to use the illegal shapes
graph for validation or MAY terminate processing without performing validation.

A SHACL validation engine MAY provide interfaces that construct the shapes graph and
data graph from other inputs and perform validation on these constructed graphs.  If
so, the engine must provide an interface that takes an RDF dataset and optionally the
IRI of a graph in that dataset.  The engine constructs the data graph starting with
the graph with that name, or the default graph of the dataset if not provided with a
graph name, and incorporating other graphs from the datatset using owl:imports.  The
engine constructs the shapes graph by starting with all graphs in the dataset with
names taken from objects of sh:shapesGraph triples in the data graph and then using
owl:imports.  '''Does this need to be more precise?'''

A SHACL validation engine MUST implement all the constructs of core SHACL.  If a
SHACL validation engine implements any of the extended constructs of SHACL then it
MUST implement them all.

A SHACL validation engine MAY produce warnings if nodes that are expected to be in
the data graph are not present there (e.g., for sh:scopeNode) or are not a SHACL
instance there of an expected type (e.g., sc:scopeClass values and rdfs:Class).

A SHACL validation engine MUST provide an interface that signals an error if the
shapes graph contains SHACL instances of sh:Shape that do not conform to the syntax
herein or that have themselves as a shape in the transitive closure of their
components and filters.  '''Does this need to be more precise?'''  If the SHACL
validation engine implements any of the extended constructs of SHACL then this MUST
also consider the syntax of template components and template scopes.


== Core SHACL Syntax ==

The main SHACL construct is a shape.  A ''shape'' is a node in the shapes graph that is
an RDFS instance of sh:Shape in the shapes graph.  (See below for a
different definition of shapes in a shape graph.)

Shapes in core SHACL have
#zero or more ''scopes'' (triples with the shape as subject and sh:scopeNode, sh:scopeClass, sh:scopePropertyObject, sh:scopePropertySubject, sh:scopeAllObjects, or sh:scopeAllSubjects as the predicate),
#zero or more ''filters'' (triples with sh:filter as the predicate), whose objects are themselves shapes, and
#zero or more ''components'' (triples with the shape as subject and one of the component properties below as property).

The scopes of a shape select nodes for validation.  Filters further cut down
on the nodes for validation.  Components state conditions that nodes need to
satisfy to validate against the shape.

The syntax of the various core SHACL components are:  
  PROPERTY        VALUE
  sh:in           list of IRIs and literals
  sh:class        IRI (which is used as a class)
  sh:classIn      list of IRIs (which are used as classes)
  sh:datatype     IRI (which is used as a datatype)
  sh:datatypeIn   list of IRIs (which are used as datatypes)
  sh:directType   IRI (which is used as a class)
  sh:minLength    non-negative integer
  sh:maxLength    non-negative integer
  sh:minExclusive literal
  sh:minInclusive literal
  sh:maxExclusive literal
  sh:maxInclusive literal
  sh:nodeKind     sh:BlankNode or sh:IRI or sh:Literal or
                  BlankNodeOrIRI or BlankNodeOrLiteral or IRIOrLiteral
  sh:pattern      string used as a regular expression pattern  or
  		  node with sh:regex value as pattern and sh:flags value as flags
  sh:equals       two paths
  sh:disjoint     two paths
  sh:lessThan     two paths
  sh:lessThanOrEqual two paths
  sh:propValues   shape with single sh:path value which is a path
  sh:list         shape
  sh:shape        shape
  sh:and          list of shapes
  sh:or           list of shapes
  sh:not          shape
  sh:hasValue     IRI or literal
  sh:minCount     non-negative integer
  sh:maxCount     non-negative integer
  sh:uniqueLang   boolean
  sh:partition    list of shapes
  sh:closed       list of path parts (which are used as (inverse) properties)
  
  sh:constraint      shape                   (for compatability)
  sh:property        shape with sh:predicate (for compatability)
  sh:inverseProperty shape with sh:predicate (for compatability)

A SHACL ''path'' is a path part or a blank node that is a list of SHACL path
parts.  A core SHACL ''path part'' is either an IRI or a non-list blank node with a
single value for sh:inverse.

Several other properties and IRIs are used in SHACL
  PROPERTY	  Value
  sh:severity     sh:Info or sh:Warning or sh:Violation
  sh:message      language tagged-string
  sh:name         language-tagged string
  sh:description  language-tagged string
  sh:order        decimal literal
  sh:group	  property group
  sh:defaultValue IRI or literal

Note: Qualified cardinalities are replaced by an embedded shape where the embedded
shape's filter has the same role as the value for sh:qualifiedValueShape.

=== Examples ===

  exs:personShape a sh:Shape;
   sh:scopeNode ex:John ;
   sh:scopePropertyObject ex:parent ;
   sh:propValues [ sh:path ex:child ; sh:class ex:Person ] ;
   sh:propValues [ sh:path ex:age ;
                   sh:datatype xs:integer;
                   sh:minCount 1 ; sh:maxCount 1 ] .

A graph validates against exs:personShape if all SHACL instances of
ex:Person in that graph have all their stated names be strings, all their
stated children belonging to ex:Person, and have exactly one stated age,
which is an integer.

  exs:SJG a sh:Shape;
   sh:scopeClass ex:Person ;
   sh:filter [ sh:propValues [ sh:path ex:gender ; sh:hasValue ex:female ] ] ;
   sh:filter [ sh:propValues [ sh:path ( ex:child ex:child ) ; sh:minCount 5 ] ] ;
   sh:propValues ( ex:child 
     [ sh:filter [ sh:propValues [ sh:path ex:gender ; sh:hasValue ex:male ] ] ;
       sh:class ex:Professional ] ) .

A graph validates against exs:SJG if all SHACL instances of ex:Person (the scope)
that have ex:female as gender (the first filter) and have at least five grandchildren
(the second filter) have all their male children be SHACL instances of
ex:Professional.

  ex:IssueShape a sh:Shape ;
    sh:scopeClass ex:Issue;
    sh:propValues [ sh:path ex:state ;
                    sh:in (ex:unassigned ex:assigned) ;
                    sh:minCount 1 ; sh:maxCount 1 ] ;
    sh:propValues [ sh:path ex:reportedBy
                    ; sh:shape ex:UserShape ;
                    sh:minCount 1 ; sh:maxCount 1 ] .
  ex:UserShape a sh:Shape ;
    sh:propValues [ sh:path foaf:name ;
                    sh:datatype xsd:string ;
                    sh:minCount 1 ; sh:maxCount 1 ] ;
    sh:propValues [ sh:path foaf:mbox ;
                    sh:nodeKind sh:IRI ;
                    sh:minCount 1 ] .

Example 1 from SHACL document

  exs:sample a sh:Shape ;
   sh:scopeNode ex:John ;
   sh:scopePropertyObject ex:parent ;
   sh:propValues [ sh:path ex:dependent ;
                   sh:class ex:Person ; sh:class ex:Child ;
                   sh:shape ex:sample2 ] ;
   sh:propValues [ sh:path ex:age ;
                   sh:datatype xs:integer ;
                   sh:minCount 1 ; sh:maxCount 1 ;
                   sh:minInclusive 12 ] ;
  exs:sample2 a sh:Shape ;
   sh:propValues [ sh:path ex:age ;
                   sh:datatype xs:integer ;
                   sh:minCount 1 ; sh:maxCount 1 ;
                    sh:minInclusive 25 ] .

Just showing some other syntax.


== Validation results ==

Validation results are essentially the same as in the current design.

sh:subject, sh:predicate, and sh:object are set as appropriate to each component
here.  sh:sourceConstraint is not used as there are no longer any constraints.
sh:sourceTemplate is the renamed as sh:Component and is the component property.


== Semantics for Core SHACL ==

A data graph ''validates'' against a shapes graph if the data graph
validates against every node in the shapes graph that is the subject of at
least one triple whose predicate is one of the scope properties.  These
nodes are called the ''scoped shapes'' of the shapes graph.  Any node in the
shapes graph that is used as a shape during validation is then a shape
whether it has SHACL type sh:shape or not.  (This is a different definition
of shapes but it does not require any use of typing to determine what is a
shape.)

A data graph ''validates'' against a scoped shape if the set of nodes of the graph
selected by any scope of the scoped shape validates against the scoped shape.

Scopes ''select'' certain RDF terms (or nodes, but RDF only uses node with
respect to the nodes of an RDF graph).
A sh:scopeNode value selects that term.
A sh:scopeClass value selects each term that is a SHACL instance of the
class in the data graph. 
A sh:scopePropertyObject value selects each term that is the object of some 
triple in the data graph with that property as predicate.
A sh:scopePropertySubject value selects each term that is the subject of a
triple in the data graph with that property as predicate. 
A sh:scopeAllObjects selects all terms that are the object of some triple in
the data graph.
A sh:scopeAllSubjects selects all terms that are the subject of some triple in
the data graph.

A set of RDF terms (the ''focus nodes'') validates against a shape as
follows.  The ''in-filter nodes'' are those focus nodes which validate
against each of the filters of the shape.  Focus nodes that are not
in-filter nodes are called ''out-of-filter nodes''.

To uniformly handle all components the semantics for components is defined in terms
of a set of of nodes (the in-filter nodes) and not in terms of a single node.
Some components (sh:shape, sh:and, sh:or, sh:not, sh:hasValue, sh:minCount,
sh:maxCount, sh:uniqueLang, and sh:partition) work on this set as a whole.  There is
one or more elements in the ''validation result'' precisely when one or more in-filter
node fails to validate against the component.  The component separately determines
which in-filter nodes validate or fail to validate against the component.
The other components (sh:in, ..., sh:pattern, sh:propValues) work on each
in-filter node independently.  The ''validation results'' for the component
contains an element for each in-filter node that failed to validate against
that component.  in-filter nodes for which there is no validation result are
considered to ''validate'' against the component.

A set of focus nodes ''validates'' against a shape if the set of in-filter
nodes from this set of focus nodes validates against each of the shape's
components.

The core components work as follows, where all typing determinations are made in the
data graph, all triples come from the data graph, and paths are processed as in the
SPARQL 1.1 Query Language.  For components that are defined using SPARQL operators,
an error result is treated as if the operator had returned false.

* sh:in list of node
:: Each in-filter node is a member of the list.
* sh:class class
:: Each in-filter node has class as one of its SHACL types.
* sh:classIn ( class ... )
:: Each in-filter node has one of the classes as one of its SHACL types.
* sh:datatype datatype
:: Each in-filter node has datatype as its datatype.
* sh:datatypeIn ( datatypes ... )
:: Each in-filter node has one of the datatypes as its datatype.
* sh:directType class
:: Each in-filter node has an rdf:type link to the class.
* sh:minLength non-negative integer
:: The SPARQL STR representation of each in-filter node is at least this long.
* sh:maxLength non-negative integer
:: The SPARQL STR representation of each in-filter node is at most this long.
* sh:minExclusive literal
:: Each in-filter node is greater than this literal, using SPARQL > test.
* sh:minInclusive literal
:: Each in-filter node is greater than or equal to this literal, using SPARQL >= test.
* sh:maxExclusive literal
:: Each in-filter node is less than this literal, using SPARQL < test.
* sh:maxInclusive literal
:: Each in-filter node is less than or equal to this literal, using SPARQL <= test.
* sh:nodeKind sh:BlankNode or sh:IRI or sh:Literal or BlankNodeOrIRI or BlankNodeOrLiteral or IRIOrLiteral
:: Each in-filter node is a blank node, an IRI, a literal, a blank node or IRI, a blank node or literal, or an IRI or literal, respectively
* sh:pattern regex  or  [ sh:regex regex; sh:flags flags ]
:: The SPARQL STR representation each in-filter node matches regex using SPARQL REGEX, with flags if present.
* sh:equals ( path1 path2 )
:: Each in-filter node has the same values for the paths starting at the node.
* sh:disjoint ( path1 path2 )
:: Each in-filter node has disjoint sets of values for the paths starting at the node.
* sh:lessThan ( path1 path2 )
:: For each in-filter node every value for the first path is SPARQL < every value for the second path.
* sh:lessThanOrEqual ( path1 path2 )
:: For each in-filter node each value for the first path is SPARQL <= every value for the second path.
* sh:propValues shape with sh:path
:: For each in-filter node the values of path validate against shape.
* sh:list shape
:: Each in-filter node is a SHACL list and its list elements validate against shape.
* sh:closed ( property ... )
:: Each in-filter node has no values for any property not in the list or that is not the property of a sh:propValues component of the shape.

* sh:shape shape
:: The nodes that validate are those that validate against the shape.
* sh:and ( shape ... shape )
:: The nodes that validate are those that validate against each shape.
* sh:or ( shape ... shape )
:: The nodes that validate are those that validate against some shape.
* sh:not shape
:: The nodes that validate are those that do not validate against the shape.
* sh:hasValue node
:: Some in-filter node is the same as the node.
* sh:minCount non-negative integer
:: There are at least integer in-filter nodes.
* sh:maxCount non-negative integer
:: There are at most integer in-filter nodes.
* sh:uniqueLang true
:: An in-filter node fails to validate if it has the same language tag as another in-filter node.
* sh:partition ( shape_1, ..., shape_n )
:: Let input_1 be the set of in-filter nodes.
:: Let input_i+1 be the out-of-filter nodes of shape_i for input_i.
:: Nodes that fail to validate for shape_i on input_i fail for the component, for 1<=i<=n.
:: Nodes in input_n+1 fail to validate for the component.

* sh:constraint shape
:: Same as sh:shape shape.
* sh:property shape with single value for sh:predicate.
:: Same as sh:propValues shape with sh:predicate property replaced by sh:path property.
* sh:inverseProperty shape with single value for sh:predicate.
:: Same as sh:propValues shape with sh:predicate property replaced by sh:path [sh:inverse property].

== SHACL Extension ==

This is a description of a SPARQL extension for SHACL based on substitution.  This
extension mechanism for SHACL does not depend on any extensions to SPARQL and thus
can be used with any SPARQL implementation or service, including SPARQL endpoints

=== Using SPARQL Queries in SHACL ===

The extension uses solutions in SPARQL result sets as validation results.  These
solutions have bindings for at least ?this and ?severity.  A set of nodes validates
against a component in the SPARQL extension if evaluating the SPARQL query for the
component over the data graph would produce no query results with ?severity bound to
sh:Violation when joined to a result set with solutions having ?this bound to
elements of the set.  Validation fails on nodes that have a solution in the joined
result set with ?this bound to the node and ?severity bound to sh:Violation.

The extension uses solutions in SPARQL result sets as scopes and as synthetic
properties.  For scopes, the set of nodes in a scope are the set of bindings for
?scope in the solutions of a result set.  For synthetic properties, the set of
subject, object pairs in a synthetic property are the set of pairs of bindings for
?subject and ?object in the solutions of a result set.

The SPARQL queries in this extension are always augmented with namespace prefix
bindings for rdf:, rdfs:, xsd:, and sh: as above.  '''A mechanism for augmenting these
bindings might be useful.'''

The SPARQL queries in this extension are always run over the data graph.
(The shapes in templates validate arguments to components and scopes of
shapes, so the data graph for them is the shapes graph.)

=== Component Templates ===

Component templates provide components based on parameterized SPARQL code.
A ''component template'' is an IRI that is an RDFS instance of
sh:ComponentTemplate in the shapes graph.  Each triple in the shapes graph
whose subject is a shape and whose predicate is a component template is a
''template component'' of the shape.

A component template is used as a shape to check the syntactic validity of
template components.  The object of a template component triple is validated
against the component template considered as a shape.  If the validation
fails the template component is syntactically illegal.

The sh:propValues components in component templates shapes can also have
sh:argumentName and sh:defaultValue triples that are used in the process of
constructing the query for template components.

Component templates provide SPARQL queries (actually strings that are used
to produce SPARQL code via the substitution process described below) to define
the query via their value for
  sh:templateQuery   parameterized SPARQL query
Alternatively the query can be constructed from the values of other properties
  sh:templateFilter  parameterized SPARQL expression
  sh:templatePattern parameterized SPARQL pattern
  sh:templateHaving  parameterized SPARQL expression
  sh:templateMessage parameterized language-tagged string
The sh:templateFilter evaluates to true for ?this bindings that would
validate against the component.  The sh:templatePattern eliminates bindings
for ?this that would validate against the component.  The sh:templateHaving
eliminates groups of solutions for ?this bindings that would validate
against the component.  The values for sh:templateMessage are used to
construct the message part of validation results.  These four property
values are all used to construct a parameterized query for the template
that looks like
  SELECT [projection] ?this ?message ?severity (?this AS ?object)
  WHERE { [outer] [inner] <pattern> FILTER ( ! <filter> ) }
  [group] HAVING <having>
  VALUES (?message ?severity) { ( <message> [severity] ) }
where the FILTER ( ! <filter> ) part is only present if there is a value for
sh:templateFilter and the [group] HAVING <having> part is only present if
there is a value forsh:templateHaving.

The actual query for the template component is produced by substitution into
the parameterized query. Values for all five of the above properties can
have substrings of the form 
  [expression]
that are treated as substitution expressions subject to replacement.
Substition expressions can be 
# a quoted string, where the string is substituted
# a simple name, where the name's mapping in the context is substituted
# p(name), where the name's mapping is processed as a path
# s(name), where the name's mapping is processed as a shape
# c(path name), where the name's mapping is processed as a shape to produce a shape for path values
# l(expression string), where the list values for the value of identifier in expression are processed instead of its values and the results joined with string
'''This syntax needs to be defined more precisely.'''  All processing
happens in the shapes graph. 

The values for names come from two sources.  Values for several standard
names are set up automatically: 
# argument is the object of the template component triple
# projection is a SPARQL variable that serves as a context, but can also be the empty string
# outer is a SPARQL pattern that produces bindings for the projection variable, but can also be the empty string
# inner is a SPARQL pattern that produces bindings for ?this
# group is a SPARQL GROUP BY fragment that groups by the projection variable, but can also be the empty string
# severity is the severity to be used in the component

Other values come from sh:propValues components in the component template that
have sh:argumentName triples in their shape argument.  Each such sh:propValues
component produces a value for the object of its sh:argumentName triple that
is either one of the values for its path starting from the its argument or
the value of its sh:defaultValue triple if there are no values for the path.

Note: Having multiple sh:propValues with the same sh:argumentName leads to
indeterminate results.  Having multiple values for an argument path leads to
indeterminate results. '''It might be better to instead collect all the values
somehow, but there would need to be some analysis to determine how to do this best.'''


=== Scope Templates ===

Scope templates provide scopes based on parameterized SPARQL queries.  A
''scope template'' is an IRI that is an RDFS instance of sh:ScopeTemplate in
the shapes graph.  Each triple in the shapes graph whose subject is a shape
and whose predicate is a scope template is a template scope of the shape.  A
scope template is also used as a shape in the same way that a component
template is.

Scope templates provide SPARQL queries to define the query via 
  sh:templateQuery parameterized SPARQL query
The query for a template scope is constructed in the same way as for a template
component except that the alternative query consruction method is not used.  As well,
the only standard name is argument.

The nodes ''selected'' by a template scope are the bindings for ?scope in
solutions in the result set of the SPARQL query run over the data graph.

=== Direct Use of SPARQL Queries ===

SPARQL queries are directly allowed in shape components via
  sh:query SPARQL query
The SPARQL query for a sh:sparql component is the provided query with no
substitutions. 

SPARQL queries are directly allowed in scopes via
  sh:scopeQuery SPARQL query
The SPARQL query for a sh:scopeQuery scope is the provided query with no substitution.

SPARQL queries are also allowed as path parts.  The bindings of ?subject and
?object in solutions of its result set are considered as subjects and
objects of a synthetic property.  '''This produces truly awful syntax, and
should be fixed somehow.'''  Note: The derived values equality constraint is
replaced by an sh:equals with one of the paths using SPARQL code.

=== Examples ===

  ex:example a sh:ComponentTemplate ;
    sh:propValues [ sh:path ex:predicate ;
                    sh:class rdf:Property;
                    sh:minCount 1 ; sh:maxCount 1 ] ;
    sh:propValues [ sh:path ex:lang ;
                    sh:datatype xs:string ;
                    sh:minCount 1 ; sh:maxCount 1 ] ;
    sh:sparqlTemplate """... ?this ...""" .

  ex:exampleShape a sh:Shape ;
    ex:example [ ex:predicate ex:p ; ex:lang "de" ] .

  sh:class a sh:ComponentTemplate ; rdfs:domain sh:Shape ; rdfs:range rdfs:Class ;
    sh:nodeKind sh:IRI ;
    sh:templateMessage "Does not have required class [argument]" ;
    sh:messsage "Classes need to be IRIs" ;
    sh:templateFilter "EXISTS { ?this rdf:type/rdfs:subClassOf* [argument] }" .

  ex:listexShape a sh:Shape ;
     ex:listex ( ex:person ex:p2 ) .