RE: Update and opportunities with SHACL

Hi Markus,
Thank you for your feedback.

We've now heard from several people that to address their needs SHACL must 
provide a decent amount of built-in constraints. That's what we refer to 
as "the core". These are constraints one can use without having to write 
any SPARQL or using some other extension mechanism.

Of course, the difficulty is to determine what "a decent amount of 
built-in constraints" is but, it's becoming clear that what we currently 
have is not enough.

I think we need to look at our use cases and determine how much is covered 
by the core vs how much requires using the extension mechanism.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


"Markus Lanthaler" <markus.lanthaler@gmx.net> wrote on 08/10/2015 01:06:24 
PM:

> From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
> To: "'Hydra'" <public-hydra@w3.org>
> Cc: <public-data-shapes-wg@w3.org>, "'Holger Knublauch'" 
> <holger@topquadrant.com>
> Date: 08/10/2015 01:07 PM
> Subject: 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

> 
> 
>