Re: on constraints (ISSUE-65)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I think that it is not correct to hide such differences.  If there are
constraints that take a focus node in the graph as an argument and other
constraints that do not, then SHACL should expose this difference and not
hide it.  If that makes for more metaclasses then so be it - the metaclasses
should reflect what is going on in SHACL.

The telling point, I think, is that constraints that take a focus node in
the graph completely fail if they are given an argument that is not a node
in the graph.  Such constraints rightly have the expectation that they are
supposed to look at triples that have the focus node as a subject or object.
 If they are given an argument somehow representing the graph as a whole
then they will be completely non-functional.  Similarly constraints that do
not use the focus node will (generally) not be useful when used in place of
constraints that do take a focus node, as they will signal the same
violations for each focus node.  The situation is even worse for constraints
that utilize the something representing the graph.  When used instead of a
focus-node-expecting constraint these graph-utilizing constraints will try
to do something with the graph-representing node and, because the focus node
is (generally) not representing a graph, they will break.

So, regardless of whether a second argument is given to constraints that do
not work on focus nodes in the graph, the two kinds of constraints are
different.  Therefore they should be described differently.  The extra
metaclasses are only reflecting what is actually going on, which is a good
thing.  The complication comes not from the division into two metaclasses
but comes from the two different kinds of constraints, and the subsequent
two different kinds of shapes.  If there is a desire to reduce that
complication then a way forward would be to get rid of the second kind of
constraint, as using expressions for scopes reduces the need for such
constraints.

peter


On 06/04/2015 04:09 PM, Holger Knublauch wrote:
> 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: 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

iQEcBAEBCAAGBQJVcYZnAAoJECjN6+QThfjzSjkH/jP1Wc35CSK3V1dFXvpWqK1/
z5Hx+hLfXedU9eQkNBIc8rWhIddwujUb/+BvpRB2EHLr0yp87mO5w2lco/h764nB
nxCdb7WwbyazQWHR6jMhE/wpfUu6HzKm8T9lZ5zA60qFrH3igJTQq5Jo9bGRSX6J
KNSkgYE+4u/ziGSCu0Rkl7Qj4KRwSt/+YFqMwsMBwhI6qbnhnoLu92GnwDm3ljcb
ZVKxCulZc+aRX2MBwDGsXA7esaDzbOn4xwoVUdiqDm6HmmAELLYsbHrY4Ls2SnQs
PVv3LYuadmCrJds1GQJBEPoujfCI/So5EKaIpK7SjpjmIRGi9Z0z2RUqbEREWPo=
=y9KI
-----END PGP SIGNATURE-----

Received on Friday, 5 June 2015 11:22:53 UTC