W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

Re: Implementations without SPARQL

From: Anamitra Bhattacharyya <abhattacharyya@us.ibm.com>
Date: Wed, 25 Mar 2015 00:02:03 -0400
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Message-ID: <OFC23E8AF5.721DFA1A-ON85257E13.00140F67-85257E13.0016296C@us.ibm.com>

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.

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.


(image/gif attachment: graycol.gif)

Received on Wednesday, 25 March 2015 04:05:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:18 UTC