Re: on constraints (ISSUE-65)

I had removed the top-level concept of Global constraints from my 
earlier drafts because I just couldn't find enough use cases to justify 
their existence. I think we should evaluate how many scenarios in fact 
require them, and whether this is worth the complications for the users, 
specifications, metamodel and the additional algorithms/operations.

For example the aforementioned case of "there must be at least 2 
instances of X" could easily be attached to class X as focus node. And, 
now that we have expressions as scopes, I believe many global 
constraints can in fact be rewritten to scoped local constraints. A good 
example of those are global property constraints such as "all 
skos:prefLabels must have unique language per subject".

If someone has convincing real-world scenarios that absolutely require 
global constraints then I'd be happy to see them brought back, but 
meanwhile I suggest we assume simplicity and go for a consistent model.

Holger


On 6/6/15 12:13 AM, Arnaud Le Hors wrote:
> 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-----
> >