W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

Re: Implementation feasibility

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Sat, 21 Mar 2015 18:32:48 -0700
Message-ID: <550E1BC0.5090007@gmail.com>
To: Jose Emilio Labra Gayo <jelabra@gmail.com>
CC: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As far as I can tell the new paper has only one example of a SPARQL extension.

The examples of transformation use something called GenX, which appears to
not be a standardized formalism.

peter


On 03/21/2015 12:00 PM, Jose Emilio Labra Gayo wrote:
> 
> I can't find any examples of an extension mechanism in the referenced
> paper.
> 
> 
> Indeed, I cited a different paper. Sorry for that.
> 
> The right one is [1] and the extension mechanism is called Semantic
> Actions. The paper also shows some interesting possibilities that can be
> accomplished with semantic actions like transforming RDF data.
> 
> Best regards, Jose Labra
> 
> [1] Shape Expressions: An RDF validation and transformation language,
> Eric Prud'hommeaux, Jose Emilio Labra Gayo, Harold Solbrig, 10th
> International Conference on Semantic Systems, Sept. 2014, Leipzig,
> Germany PDF: http://labra.github.io/ShExcala/papers/semantics2014.pdf 
> Slides: http://www.slideshare.net/jelabra/semantics-2014
> 
> 
> peter
> 
> 
> On 03/20/2015 10:16 PM, Jose Emilio Labra Gayo wrote:
> 
> [...]
> 
>> 
>> From my point an extension mechanism similar to ShEx semantic actions
>> can be included in the SHACL high-level language.
>> 
>> The mechanism allows the inclusion of an action that has a language 
>> identifier and some code. The language identifier can be SPARQL, 
>> javascript, or whatever and if the SHACL validator has support for
>> that external language processor it calls it passing the code. You can
>> see some examples here [1]
>> 
>> I think Eric didn't add it to his latest proposal because he was just 
>> trying to be conservative and include only the most basic language 
>> constructs. We have found that such a mechanism offers enough
>> flexibility to handle complex constraints without imposing a
>> particular implementation.
>> 
>> From my perspective Eric's proposal can be used as a first step
>> towards identifying the main high-level language constructs, but it
>> doesn't mean that those constructs should be the only ones. That's why
>> I think your table in the wiki was also a good step forward to
>> identifying those language constructs.
>> 
>> Best regards, Jose Labra
>> 
>> [1] Validating and Describing Linked Data Portals using RDF Shape 
>> Expressions, Jose Emilio Labra Gayo, Eric Prud'hommeaux, Harold
>> Solbrig, , 1st Workshop on Linked Data Quality, Sept. 2014, Leipzig,
>> Germany PDF: http://labra.github.io/ShExcala/papers/ldq2014.pdf
>> Slides: http://www.slideshare.net/jelabra/linked-dataquality-2014
>> 
> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVDZGaAAoJECjN6+QThfjzWWwIAMlRb/ebuSQeMbG2VABc+XPq 
> kPR/uj8nmY06ieG1KcAQ3AMaqMShZO6VQBfihz0zK3ybP/Tkf0zvJ2paD57gqrz1 
> 7xWQN56OwYKlElbBzOM3Nm/HxRtHhjhlc2E7lfWnjhfHCRop+ne8wnXV1ffg2hXp 
> s4n3T3jcDo0OYxP+RhNz8xU5cpDeRpNlTo10gc2QkKYsyrP3zl7QISfFtgDUY93I 
> aSan2j/AJU65k/pf2TU+IXJHejn/wJ/XbYWcAcFrHSJi17oSa0np1lvCvcFYz2S0 
> LQVxHAVNX4BMz4WgAsK7Cx23aCt5I5Rfhlkl3CcqIvJQ3THKRMV8KajA08fdQ6M= =FDW1 
> -----END PGP SIGNATURE-----
> 
> 
> 
> 
> -- -- Jose Labra
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVDhvAAAoJECjN6+QThfjz+goIAJtzor+DOXE0ppAIQGnHt1qj
cS0zxzB+kqLZm+MiEysZD4CqUKqhifrHGvdu8cJRuzNbxfRtdH46Fjhr0MebbMTx
30YDNasNaOxj+tRqCVpwGs5RrLxPaDY6iYiefqUZ6nn02xjJrcHQfGyn57mIGBAF
SA/uCd9hj1mxBpopd3RdUHn4dLLt1394tBrEzMu//1AiYiqhSCe5AI1QWGiS9EhY
WwFjtYGIRsNqyXc5zLwqlLrFLGkMChNOvxzlIX3MPmxpHM1ixAr+MIfpMc/xwa7k
WtGtBfZDOkzdJzQhxtfz2vq4I/u1TYuPai2sJHH3ckLT6NiNzgVGujFHVTerKnw=
=2pKP
-----END PGP SIGNATURE-----
Received on Sunday, 22 March 2015 01:33:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:18 UTC