RE: shapes-ISSUE-60 (Other Extension Languages): Shall SHACL support other extension languages beside SPARQL (like JavaScript)? [SHACL Spec]

> In general I believe we have an immense opportunity here to create something that could propel Semantic Technology into much more mainstream use cases, as a schema language for JavaScript applications, and servers using JSON for data exchange and interface definitions. 
JavaScript also covers additional use cases that cannot be expressed in SPARQL.

+1

-----Original Message-----
From: Holger Knublauch [mailto:holger@topquadrant.com] 
Sent: Sunday, 31 May 2015 3:14 PM
To: RDF Data Shapes Working Group
Subject: Re: shapes-ISSUE-60 (Other Extension Languages): Shall SHACL support other extension languages beside SPARQL (like JavaScript)? [SHACL Spec]

Thinking a bit more about JavaScript support for SHACL, I believe the following syntax would be quite attractive and is easy to implement:

ex:MyShape
     sh:constraint [
         sh:message "The URL {?value} cannot be resolved for {?predicate}" ;
         sh:predicate ex:imageURL ;
         sh:jsExpression "helper.isResolvableMedia(value)" ;
         sh:jsLibrary "http://example.org/helper.js" ;
     ] .

If a constraint has a sh:jsExpression, then the system would walk through all values of the provided sh:predicate and invoke sh:jsExpression with the given object pre-assigned to the JavaScript variable "value". The example above would call a helper function, but this could be any JavaScript snippet that returns a boolean result. If false, a constraint violation is produced using the sh:message template. 
sh:jsLibrary would point at a required JavaScript file that the engine needs to use. I implemented something very similar with SPINx [1] and it works quite well with embedded JavaScript APIs such as Mozilla Rhino [2]. The example above could of course also be turned into a SHACL template, so that the actual JavaScript details get hidden, and people just instantiate

ex:MyShape
     sh:constraint [
         a lib:ResolvableMediaConstraint ;
         lib:predicate ex:imageURL ;
     ] .

This approach could be in addition to the JSON-LD approach suggested by Arthur (which has higher implementation costs but is more general). 
Maybe the IBM people who championed this topic could provide feedback.

In general I believe we have an immense opportunity here to create something that could propel Semantic Technology into much more mainstream use cases, as a schema language for JavaScript applications, and servers using JSON for data exchange and interface definitions. 
JavaScript also covers additional use cases that cannot be expressed in SPARQL.

Thanks
Holger

[1] http://spinrdf.org/spinx.html

[2] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino



On 5/30/2015 11:48, RDF Data Shapes Working Group Issue Tracker wrote:
> shapes-ISSUE-60 (Other Extension Languages): Shall SHACL support other 
> extension languages beside SPARQL (like JavaScript)? [SHACL Spec]
>
> http://www.w3.org/2014/data-shapes/track/issues/60

>
> Raised by: Holger Knublauch
> On product: SHACL Spec
>
> We have frequently discussed that there could be other extension languages beside SPARQL, but I don't think we ever formally closed this topic. The current spec would allow other languages such as JavaScript, identified through some property such as shjs:js. My impression from discussions in the WG was that most people would be in favour of allowing this flexibility, but I believe Peter was against that. In any case, we need a resolution.
>
> Once we do that, we could discuss whether we also want to do a JavaScript deliverable as part of the WG, but that would be a separate ticket.
>
>
>

Received on Sunday, 31 May 2015 07:16:08 UTC