RE: Update and opportunities with SHACL

+ public-data-shapes-wg@w3.org (this time with the right address)

On 3 Aug 2015 at 05:59, Holger Knublauch wrote:
> Dear Hydra group members,

Hi Holger,

Sorry for the late reply. The fantastic weather makes it very hard to do some work besides the necessary day-to-day work :-) It's probably a bit easier in your hemisphere at this time of the year.

 
> I would like to draw your attention to the RDF Data Shapes Working Group
> [1] which has made some progress towards defining the Shapes Constraint
> Language (SHACL) [2]. For a quick tutorial, see [3].

Great to see that you already implemented it.


> While the language is not yet complete and far from being officially
> standardized, I believe most major design decisions have been made and
> the syntax is now reasonably stable.

OK. What are the major missing parts? I tried to keep up with the discussions on the mailing list but the volume of mails has been way too high. I had a quick look at the current draft. I was kind of surprised by the few constraints it defines. Is this something that still will be addressed?


> We had previous discussions here why there could be some good synergies
> between SHACL and Hydra (and Linked Data Fragments). Among others, SHACL
> shapes could serve as structural definitions of web service input and
> output. There are two aspects where the SHACL group could need input and
> possibly contributions:
> 
> 1) SHACL should have a standard JSON-LD Context. While I do understand
> JSON-LD, I believe someone with more JSON-LD experience could do a much
> better job in defining a standard @context file to make shape
> definitions as readable as possible - before everyone invents their own
> variation of this.

I can certainly help with that.


> 2) SHACL can interact with JavaScript! The WG has decided that
> structural constraints (and template macros etc) can be defined in any
> number of execution languages. SHACL comes built-in with SPARQL, but we
> explicitly leave the door open for JavaScript-based execution; either in
> conjunction with SPARQL or without SPARQL and even without any RDF at
> all. One example syntax had been outlined in [4]:
> 
> 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" ;
>       ] .
>
> (Imagine a corresponding JSON-LD syntax if item 1 is solved). The above
> would mean that a constraint violation is reported if the given
> jsExpression evaluates to false. Maybe it could be of interest to people
> here at Hydra to have a standard vocabulary to communicate such
> constraints to clients (or node.js servers).

This is certainly nice but I think those extension points should be just that.. extension points. In most cases users shouldn't need to use them but just choose from a set of predefined constraints. If the set of predefined constraints isn't compelling enough, I'd expect SHACL to be a quite tough sell.

 
> While I am not officially speaking on behalf of the WG, I believe the
> group would welcome any volunteer who would like to work on a JavaScript
> extension document for SHACL, possibly as a separate WG deliverable in
> addition to the SPARQL stuff. A chance to get your name on a W3C
> publication. I am confident that such a JavaScript binding will evolve
> sooner or later anyway, but it would be a much stronger story for SHACL
> if it had these two language bindings from day 1.
> 
> Regards
> Holger
> 
> [1] https://www.w3.org/2014/data-shapes/wiki/Main_Page
> [2] http://w3c.github.io/data-shapes/shacl/
> [3] http://www.topquadrant.com/technology/shacl/tutorial/
> [4]
> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0216.html

Received on Monday, 10 August 2015 20:06:54 UTC