- 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