Re: shapes-ISSUE-45 (SPARQL-extension): Should SPARQL be a built-in extension language [SHACL Spec]

On 4/17/15 4:14 PM, Simon Steyskal wrote:
>> Built-in here means part of the official spec (similar to how "my"
>> draft does this right now) - part of the "Full" language. Not just an
>> example, but mandatory for anyone claiming full SHACL support.
>
> So basically, although other languages could be supported as well 
> anyone who is claiming full SHACL support must be able to parse 
> constraint templates using SPARQL as extension language?

Yes, that would be my proposal. But SHACL "Full" would be one profile 
among others, alongside with SHACL Lite/Core and other subsets, or 
possibly even supersets such as SHACL-JS (JavaScript is more expressive 
than SPARQL).

>
> I guess the issue here is to clarify to what extent do we force SPARQL 
> support. What minimal subset of SPARQL (features) must be supported?

If we include a property sh:sparql, then it becomes impractical to limit 
its values to a subset of SPARQL. Neither would that make sense IMHO, 
because all relevant platforms now have SPARQL support.

However, a good follow-up question is how far the high-level language of 
SHACL should reach, and cover sub-sets of SPARQL. I have tried to 
illustrate this with a diagram here:

https://twitter.com/HolgerKnublauch/status/589674557746745345

If we consider this discussion a trade-off between
- expressivity (the more use cases SHACL can cover the better)
- declarativeness (tools can agree on high-level terms)

then the Core language would be a well-accepted collection of 
declarative templates for common use cases. However, to improve 
expressiveness, there is also a large area in the middle, where anyone 
(incl this WG) will be able to define additional templates that 
encapsulate reusable design patterns. These additional templates could 
include things like
- comparing language tags
- counting instances per graph
- comparing two values of different properties
etc. The most useful of those templates would evolve into de-facto 
standards and later official standards, possibly created by follow-up 
WGs. This way, more and more high-level elements would emerge that cover 
a growing subset of SPARQL.

Hope this clarifies it.
Holger

Received on Sunday, 19 April 2015 22:23:34 UTC