Re: ShEx extensions

Eric,

> On 26 Mar 2015, at 21:52, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
>> 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?
> 
> That one does depend on order. I'm unsure how to deal with the ShEx ordering. There are a lot of cool things one can do with a defined order (e.g. adding an ordinal to each constraint in a shape), but that's also rather controversial.
> 
> There are plenty of possible semantic actions which don't require order. The %sparql{%} one, for instance, assumes access to the whole graph (or at least the arcs with the subject of the focus node). But ordered stuff like GenX is also damned handy, albeit researchy.

I guess the root problem with %js as well as GenX is not order, but side effects.

Extensions with side effects are undoubtedly powerful and enable a lot of cool stuff, but would rely on order (thus limiting possible implementation strategies), and would require quite a bit of additional specification (for example, is the evaluation of conjunctions short-circuited, or is there a way to reset the context when a rule is completely evaluated).

> One thing to keep in mind is that %js{%} was meant as a platform-specific extension, i.e. one that is caters to the structures of some implementation and is thus powerful and cheap to implement

Fair enough.

This confirms my suspicion though: There seem to be no proposals for an extension mechanism before the WG that are designed to be interoperable across implementations and use something other than SPARQL.

This makes it hard to cater for extensions not based on SPARQL in the WG’s deliverables.

It also makes it somewhat unnecessary, as implementation-specific extensions are not intended for exchange between systems, and hence don’t require an interoperability story, and hence are not really in scope for a standards group.

>> But there is a certain view of the world where the extension construct is the most basic one.
> 
> True, but it's also the hardest as it involves the definition of envisionable expressivity. We could start with a simplish one that is unordered and returns an OK or FAIL.

Sure.

One difference between the way this works in ShEx extensions and Holger’s proposal is that in the latter, extensions are invoked per focus node, while in ShEx, it’s per outgoing arc of the focus node (if I read things correctly).

> From an implementation perspective, OK or error string would be cool, but may be tough to spec in any useful way. "A non-empty string signals an error, with which the application can do whatever the hell it wants.”

How about indicating success by returning nothing, and indicating failure by returning a “violation object”, that is, a set of key-value pairs where some keys have special meaning, and the values are generally RDF terms. The details of these violation objects and how they are aggregated in the high-level language remain to be defined.

Best,
Richard

Received on Saturday, 28 March 2015 18:32:36 UTC