Re: shapes-ISSUE-60 (Other Extension Languages): Shall SHACL support other extension languages beside SPARQL (like JavaScript)? [SHACL Spec]

On 5/31/2015 22:47, Peter F. Patel-Schneider wrote:
> Hash: SHA256
> On 05/31/2015 12:15 AM, 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
> Which use cases are these?

I assume we agree that JavaScript is more expressive than SPARQL - this 
is easy to prove because there exists at least one SPARQL engine 
implemented in JavaScript.

JavaScript is a general-purpose programming language with features such 
as loops and ifs, the ability to create intermediate helper objects, 
functions and reusable libraries. It's not just for client-side UI code 
and DOM manipulation, but is getting increasingly popular on the server 
too (node.js etc). JavaScript can invoke web services that produce 
(among others) XML or JSON.

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.

The answer to your question should be obvious. It's impossible to 
enumerate all these use cases because we cannot anticipate what 
real-world users will do with SHACL. Many of them are simply 
application-specific or API specific (like in the case of OSLC). The 
fact that we didn't record all these use cases as user stories is not a 
reason to exclude JavaScript support - it only shows that we were 
conservative and focused on the traditional home turf of the WG members. 
I urge the WG to look outside of our little worlds and embrace this 
opportunity. Obviously not every SHACL engine would have to support all 
of these features, but we already have this situation with the Core vs 
SPARQL divide.


Received on Sunday, 31 May 2015 22:55:05 UTC