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

ShEx extensions (was: Re: Implementation feasibility)

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 23 Mar 2015 13:31:58 +0000
Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Message-Id: <DE1EAAC5-8E7C-4D52-9EF4-FF7682F6D999@cyganiak.de>
To: Jose Emilio Labra Gayo <jelabra@gmail.com>
Hi Jose,

> On 21 Mar 2015, at 05:16, Jose Emilio Labra Gayo <jelabra@gmail.com> 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 found the correct link: http://labra.github.io/ShExcala/papers/semantics2014.pdf )

Is there a more detailed account of the extension mechanism? The Javascript example seems to rely on the execution order of the semantic actions. It wouldn’t work if the second part of the example is evaluated first. Does ShEx guarantee that rules at the same level of nesting are evaluated in document order?

The Javascript example relies on a shared context between the semantic actions. Is the assumption that there’s a single global shared context?

I take it there’s no way to access data that is “outside” of the shape in the Javascript extension?

I take it that the following is a valid shape definition; what are s, p and o in this case?

  <IssueShape> { %sparql{ … %} }

> 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. 

Well, I agree that starting with the most basic constructs is a good idea. But there is a certain view of the world where the extension construct is the most basic one.

Best,
Richard
Received on Monday, 23 March 2015 13:32:26 UTC

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