Re: ShEx extensions (was: Re: Implementation feasibility)

* Richard Cyganiak <richard@cyganiak.de> [2015-03-23 13:31+0000]
> 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?

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.


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

That was my assumption. 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. (15 lines:
    jsHandler: function () {
        return {
            when: 0,
            _callback: function (code, valRes, context) {
                eval("function action(_) {" + code + "}");
                ret = action(context, { message: function (msg) { RDF.message(msg); } });
                var status = RDF.DISPOSITION.PASS;
                if (ret === false)
                { status = RDF.DISPOSITION.FAIL; valRes.error_badEval(code); }
                return status;
            },
            begin: function (code, valRes, context) { return this._callback(code, valRes, context); },
            post: function (code, valRes, context) { return this._callback(code, valRes, context); }
        }
    },
)


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

It has access to the results of the validation which means it can access the visited nodes "below or behind" the focus node.


> I take it that the following is a valid shape definition; what are s, p and o in this case?
> 
>   <IssueShape> { %sparql{ … %} }

?s ?p ?o are the variables bound when validating the current arc. For SPIN rules, ?s would be ?this (which would be easy to change in the demo). For an example of the SPARQL, see the generated SPARQL queries.


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

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


> Best,
> Richard

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 26 March 2015 21:52:21 UTC