- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 02 Jun 2015 09:49:53 +1000
- To: public-data-shapes-wg@w3.org
On 6/1/2015 22:47, Peter F. Patel-Schneider wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 05/31/2015 03:53 PM, Holger Knublauch wrote: >> On 5/31/2015 22:47, Peter F. Patel-Schneider wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> On 05/31/2015 12:15 AM, Simon.Cox@csiro.au wrote: >>>>> In general I believe we have an immense opportunity here to create >>>>> something that could propel Semantic Technology into much more >>>>> mainstream use cases, as a schema language for JavaScript >>>>> applications, and servers using JSON for data exchange and >>>>> interface definitions. >>>> JavaScript also covers additional use cases that cannot be expressed >>>> in SPARQL. >>> Which use cases are these? >> >> Karen's group had presented specific requirements to check whether >> certain URLs are resolvable and produce certain response headers. >> It's easy to come up with other ideas, e.g. checking the current >> exchange rate of a currency via a web service, complex string or math >> operations - anything that goes beyond the hard-coded standard >> functionality of SPARQL engines. > There are lots of things that one might want to do. There are even lots of > things that one might want to do with a constraint engine. There are > probably even lots of things that one might want to do SHACL. That doesn't > make them use cases. At best, the last are potential use cases for SHACL. > > So maybe the ability to do something on the web is a potential use case for > SHACL. It turns out that this has recently turned into an approved use > case, S40 on the wiki. > > Can this be done in JavaScript? I don't know. Yes, e.g. http://en.wikipedia.org/wiki/XMLHttpRequest > > Can this be done in SPARQL? I think that this depends on what parts of > SPARQL can be used in SHACL. I don't think that SPARQL queries can do this > without using an extension function. SPARQL extension functions would be another partial option. But you'd also then need functions that parse and handle the results (XML, JSON etc). So this would be a far more expensive approach than simply allowing JavaScript in general. Instead of getting lost in such details, I would encourage everyone to look at the big picture: Assuming we would publish SHACL with built-in support for SPARQL and JavaScript. With the syntax that I proposed a few emails up [1], code could easily be executed by a JavaScript client in the browser. The same code could be executed for testing on the server (node.js,Rhino etc). This means that people could - Use SPARQL as a server storage layer (possibly something like D2RQ if the data is relational) - Clients could GET resources that they want to edit -> JSON-LD with SHACL - Clients can validate the instance client-side - Clients can PUT the resource back - Server can perform the same tests, with exactly the same SHACL definitions The breakthrough here is that a lot of business logic that is currently hidden in JavaScript or Java code could be made explicit, declarative and shareable. The "Model" part of a Model-View-Controller architecture could be a JavaScript file that is shared between client and server, and which is called from SHACL via JavaScript functions. At the same time, SHACL would interact nicely with SPARQL databases and other semantic web concepts such as URIs. We would significantly broaden the potential user base of this technology, at comparably little cost. Thanks, Holger [1] https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0216.html
Received on Monday, 1 June 2015 23:52:00 UTC