Re: Implementations without SPARQL

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






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