Re: on constraints (ISSUE-65)

I used to have a similar separation in my earlier drafts, calling them 
local and global constraints. As time passed by I noticed that this was 
significantly complicating the metaclasses (e.g. cross-product of 
local/global vs native/template constraints) and the 
operations/algorithms. And then there was the extra cognitive load of 
trying to explain this. You also state yourself that the use cases of 
these global constraints are very rare - most of them can actually be 
expressed with a flexible scoping mechanism (see separate email).

I believe we can drop option 2 and state that all constraints take a 
focus node as argument, but some constraint may ignore that node. As I 
said in the call, and in the current draft [1], global constraints can 
be regarded as constraints attached to the graph itself. In almost all 
scenarios that I can think of, there will be a natural URI for the graph 
itself (e.g. the URL of the GET request). In many cases, such graphs 
even have a type, such as owl:Ontology, and people can attach 
constraints to that class, or other graph classes.

If a graph has no natural URI, then we could define a default URI such 
as sh:DefaultGraph. Then the shapes graph could contain statements such as

sh:DefaultGraph
     sh:nodeShape [
         sh:constraint ...
     ] .

Another pattern for those (rare) cases could be something like

ex:MyShape
     sh:scope sh:global .

where sh:global is an instance of

sh:GlobalScope
     a sh:ScopeTemplate ;
     sh:sparql "SELECT (sh:DefaultGraph AS ?this) WHERE { }"

which will ensure that ex:MyShape will be evaluated exactly once. Quite 
a pretty syntax too.

So my summary is that global/unscoped constraints are not worth the 
complications, and that we can work with the already provided 
mechanisms, reducing cognitive and implementation overhead.

Holger

[1] http://w3c.github.io/data-shapes/shacl/#graph-constraints


On 6/5/2015 6:42, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> This is a follow-up to the discussion on the teleconference today.
>
>
> In my view there are two different (but related) things:
>
> 1/ The sort of constraints (scoped constraints?) that occur in shapes that
> have a scope (either an explicit scope as in the SPIN-related proposals or
> an implicit universal scope as in the various versions of ShEx).  These
> constraints work off a focus node, which is a node in the graph being
> validated.  A shape that requires all people to have a single string name
> has a constraint of this kind, perhaps written as
>    [ sh:predicate foaf:name ; sh:valueType xsd:string ]
> It is not possible to evaluate this constraint without a focus node.
>
> 2/ The sort of constraints (unscoped constraints) that occur in shapes that
> enforce properties of the graph as a whole.  (If scope expressions are
> allowed then this sort of constraint is likely to be quite unusual and
> natural examples are hard to come up with.)  These constraints do not use a
> focus node, and there may be no focus node to provide for them.  A shape
> that requires the graph to have exactly two triples in it would have a
> constraint of this kind, perhaps written as
>    SELECT ?no WHERE {
>      { SELECT (COUNT(*) as ?no) WHERE {?a ?b ?c .} }
>      FILTER ( ?no != 2 )
>    }
> This constraint has no use for a filter node.
>
> The two kinds of constraints look and act quite differently so I think that
> they need to be different kinds of things in SHACL, whether or not they are
> both called different kinds of constraints.
>
>
> peter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVcLg9AAoJECjN6+QThfjzAsoIAMubqcvbFqoWzMdgs4qWqYoN
> +AXo83iOPZHYYeGzyfRvnePp1mBdxGVZ1pgUEs5C32Riy9z4dse1ldNhKz+FbAsa
> 7nAUxsohKS7dQhNX6JnXpiBESQrsT0rzsuRig5EGcg4EcenwO9Ti9ZYFHDvRo78O
> oar6+owSnAgIZZd2rB5k805keCwFQYKQzU7QgOt5Z+ltG9ZMmYBoO6H/Bz0KEdCd
> 6eFMAmrm68baF4qfeqnortP/sZ0KUonc2Z1GMcDvBRDT2vqI4p1bXrh+qVEGaNBS
> HH6cmyGSsIYvRTyEwgAY64HC+Ol44ud/RhF7yY9Lm5GvOxQAwIXv4hpHzbBmQlg=
> =Mp1k
> -----END PGP SIGNATURE-----
>

Received on Thursday, 4 June 2015 23:12:02 UTC