- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 19 Mar 2015 20:34:42 -0700
- To: Michel Dumontier <michel.dumontier@stanford.edu>, Holger Knublauch <holger@topquadrant.com>
- CC: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I guess I'm a bit skeptical that many users will go to the trouble of writing a template (which requires writing SPARQL (or maybe some other execution language)) instead of using the high-level language (which doesn't require writing any SPARQL), as long as the high-level language provides a useful set of constructs. peter On 03/19/2015 05:37 PM, Michel Dumontier wrote: > Hi Holger, I want a language that sits on its own, with a clearly defined > syntax and semantics, and for which there can be a number of > implementations. Since SPARQL is an obvious choice, it makes sense to > have a document that specifies how SHACL expressions can be evaluated > using SPARQL. > > What I worry about is that some users will simply resort to the > templating mechanism instead of articulating the constraint using the > language, thereby neatly causing a crisis in interoperability. You seem > to dismiss this possibility, but I'd rather be proactive on the point, > and emphasize that the templating mechanism should be used where SHACL > standardization fails to support a use case. With your vast experience, > it would also be useful to include use cases so that users can see how > the templating can get them further. > > I also worry that those who wish to implement SHACL will be forced to > parse and interpret the arbitrary SPARQL expressions in templates. > Therefore, it's important to recognize that the templates, just as much > as functions, is a "if you need to do this, here's the vocabulary for > it", but there's no mandate by us that you have to interpret this. Some > will, and others won't. Thus, I'm ok with having clearly delineated > profiles to handle these cases. > > hope that clears up what i meant, > > m. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVC5VSAAoJECjN6+QThfjzIxQH/0ihZXD/JIjp43dwHuXtHsyi tsa9qVnULS3jneJEFx9ZuQNpSW1yoD12LxUYW7y6ueN+/Xi422hI2Iy2tqSuNDWN zoH8A2+ou9mNc7gsTAuCoamnmqyrel4XQGAKWcCOkuDhFZD/kSPrnZiswOzFu1bR TDJr98XgLiaqHkf/smQIpyFW0LtLc0AJXXGV925EcUUWXvPNYe4cDYYikvIgttcp 6lu+NLelkThb5pddTKyqllSWci4iJO1noze6jW0W+WRS9TzZXTBoQOK8+hnNHLxF qHA3W2mBPOTarfNCtUtH1ijTbIVR3ntoBhUfPVofQfFi132FL0d1ADgYLLO6oEQ= =EYnm -----END PGP SIGNATURE-----
Received on Friday, 20 March 2015 03:35:12 UTC