- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 04 Jun 2015 13:42:37 -0700
- To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
-----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 20:43:08 UTC