Re: on constraints (ISSUE-65)

It seems quite clear to me that what you are talking about is two types of 
constraints: one that applies to a node, the other that applies to a 
graph. Why not calling them just that? Node constraint and Graph 
constraint?

I understand the added complexity but I agree with Peter that merging the 
two into a single construct seems like a hack that is wrong. Unless we 
decide that we don't need graph constraints we ought to recognize and 
surface the fact that these are two different things.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


"Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote on 06/05/2015 
04:22:15 AM:

> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> To: Holger Knublauch <holger@topquadrant.com>, 
public-data-shapes-wg@w3.org
> Date: 06/05/2015 04:23 AM
> Subject: 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-----
>