Re: Implementations without SPARQL

Thanks for clarifying this. Could you further explain what data 
structure you have in JSON? Are these the same objects that come in as 
JSON-LD or is the plain JSON converted into some other API?

Also note that this question is not about whether the people creating 
the constraints need to use SPARQL. The example you state could be 
expressed using templates alone, e.g.

ex:MyClass
     a sh:Shape ;
     sh:property [
         # This constraint only applies if status = approved
         sh:scope [
             sh:property [
                 sh:predicate ex:status ;
                 sh:hasValue "approved" ;
             ]
         ] ;
         # Then asset is required
         sh:predicate ex:asset ;
         sh:minCount 1 ;
     ] ; ...

The question is entirely about whether a SPARQL engine could run in the 
background for the above syntax, i.e. whether you have some kind of RDF 
data model and API on the clients.

Thanks,
Holger


On 3/25/2015 14:02, Anamitra Bhattacharyya wrote:
>
> Hi
> The use case is fairly simple - our client side is a mobile device 
> that can stay disconnected for days (when workers go to remote places 
> - like under water/under ground mines for maintenance). These *offline 
> *mobile users would create/update resources (say Workorder or Tickets) 
> using the mobile app - -> json data is stored in the local device - to 
> be synced up with the server when the user comes back online. Its of 
> utmost importance that the "offline" created resources are validated 
> to the best possible extent. Static validations - data type  and enum 
> constraints are easily achieved by the current grammar of the Shape 
> spec - but conditional validations are not - if "status" is "Approved" 
> - "asset" and "location" are required. Such validations needs to get 
> expressed by a /language that is known to most developers/ and needs 
> to get executed at the mobile device - which has /no access to any 
> triple store/.
> Based on the customer feedback - using SPARQL to express those 
> constraints have is a non-starter.
> Anamitra
>
>
>
>
> Inactive hide details for Holger Knublauch ---03/24/2015 08:49:00 
> PM---On 3/25/15 10:43 AM, Arthur Ryman wrote: > Holger,Holger 
> Knublauch ---03/24/2015 08:49:00 PM---On 3/25/15 10:43 AM, Arthur 
> Ryman wrote: > Holger,
>
> From: Holger Knublauch <holger@topquadrant.com>
> To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
> Date: 03/24/2015 08:49 PM
> Subject: Re: Implementations without SPARQL
>
> ------------------------------------------------------------------------
>
>
>
>
>
> On 3/25/15 10:43 AM, Arthur Ryman wrote:
> > Holger,
> >
> > I believe that Amamitra's point is that the ecosystem of business
> > partners associated with his product is fluent in JavaScript. They
> > would not want to learn SPARQL. Therefore a JavaScript implementation
> > of SPARQL that ran in a browser would not help. This sentiment ties in
> > with the positive reception for JSON-LD by schema.org adoptors
> > reported by RV Guha.
>
> So which client-side data structures are those people using? Do they
> receive JSON-LD and just leave them as JSON?
>
>
> >
> > There is clearly a new generation of developers who are very
> > JavaScript-centric. Personally, I think SPARQL is vastly more powerful
> > and productive than JavaScript for expressing constraints, but many
> > developers like "monoglot" development in JavaScript. If we appeal to
> > them, it could make SHACL more impactful.
>
> Fully agreed, and that's why we could add JavaScript support. However,
> before we can do this, we would need a standard API that these JS
> snippets would work against. For people using client-side RDF, SPARQL
> would be the obvious choice.
>
> Holger
>
>
>