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

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, 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.

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.

> 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.

> Holger


Version: GnuPG v2


Received on Monday, 1 June 2015 12:48:36 UTC