Re: Implementations without SPARQL

Ok a solution that simply serializes the query graph to JSON-LD would 
work from my perspective. It will of course have performance 
considerations, but I guess many clients will operate on small snippets 
only anyway. Do you guys think we should aim at making this an official 
property (such as sh:javaScript or sh:js) in version 1.0? I remember 
Peter was against allowing anything that could not be expressed in 
SPARQL, so do you anticipate to require features and libraries of 
JavaScript that would go beyond SPARQL?

(Finally, if the client wants to operate on the JSON-LD directly, it may 
need to normalize the syntax first, since there are many different 
JSON-LD files for the same graph).

Holger


On 3/25/2015 22:59, Arthur Ryman wrote:
> On Tue, Mar 24, 2015 at 8:48 PM, Holger Knublauch
> <holger@topquadrant.com> wrote:
>> So which client-side data structures are those people using? Do they receive
>> JSON-LD and just leave them as JSON?
> Holger,
>
> While the current IBM implementation is useful as an existence proof,
> I think that for SHACL we should define an approach that aligns with
> W3C and industry best practices. I think the simplest approach is to
> define a JS language binding in which the RDF graph being validated is
> passed in to a JS function as a JSON-LD object. The JS function body
> can then access the JSON-LD object directly, or it can make use of any
> RDF library through usual JS facilities for loading libraries. This
> avoids the need for us to dictate one particular RDF library. We might
> also provide a mechanism for declaring a set of shared JS libraries to
> preload. JS developers expect to have freedom of choice of the
> libraries they use.
>
> -- Arthur

Received on Wednesday, 25 March 2015 22:45:47 UTC