Re: How would option b) on the last straw poll of 12 March work?

Hi Karen,

(just before I sent this off I saw your more recent message, yet the 
content below seems still fitting as a clarification...)

On 3/17/2015 1:20, Karen Coyle wrote:
>
>
> On 3/15/15 8:27 PM, Holger Knublauch wrote:
>> Arnaud had suggested a way to resolve that impasse, and I have reworked
>> the SHACL spec [1] to implement that idea. The high-level language is
>> now edited out from the SPARQL aspects, and IMHO this addresses all
>> needs by the implementers of light-weight engines that only want to
>> support the core profile. Please review that document and tell me where
>> you see specific remaining problems.
>
> Holger, the sentence:
>
> "SPARQL is the only built-in execution language in SHACL, but other 
> languages may be supported future versions or by third parties."
>
> is problematic given the intended separation of language from 
> implementation. First, there are no "third parties" -- we're all just 
> "parties."

Changed to "but other languages may be supported in future versions or 
by other communities." Is that better?


> Second, I believe we intend SPARQL as a definitional language, knowing 
> full-well that it will also be an execution language. But the 
> agreement at the f2f was to use SPARQL to define the meaning of the 
> language. I don't think there should be a built-in execution method or 
> language in the SHACL language spec.

I admit I cannot quite follow you here. The sentence above is *not* 
about how SHACL is formally defined, but about the fact that people can 
use SPARQL and other languages to define their own macros and 
constraints. Let me give you an example to make sure we are talking 
about the same thing.

Assuming you want to express a (silly) global constraint that the graph 
must not have more than 10 triples.

ex:NotMoreThanTenTriplesConstraint
     a sh:GlobalConstraint ;
     sh:sparql "ASK { FILTER ex:graphSize() > 10 }" ;
     shx:javaScript "return graph.size() > 10" ;
.

The example above uses two executable languages, identified by their 
"trigger" properties sh:sparql and shx:javaScript. SHACL includes a 
definition of sh:sparql as an executable language, with instructions on 
how the system must parse the provided sh:sparql string, execute the 
query and then produce sh:ConstraintViolations from it. These details 
are elaborated in http://w3c.github.io/data-shapes/shacl/#sparql

Some other community may decide to define a similar specification for 
shx:javaScript, based on some yet-to-be-standardized JavaScript API for 
RDF and some variable naming conventions (here: graph represents the 
whole RDF graph). The spec leaves this possibility open and provides a 
flexible mechanism in the Operations section 
http://w3c.github.io/data-shapes/shacl/#operation-checkConstraint so 
that some implementations that live in a web browser can exploit the 
presence of a JavaScript snippet without requiring a full SPARQL engine. 
(By the way, SPARQL engines for JavaScript do exist, but that's just one 
implementation option; working directly on JSON-LD objects is another).

So now back to the interplay of this specification mechanism of 
executable languages and the definition of the built-in high-level 
language of SHACL. Each of the properties such as sh:minCount is backed 
by a SHACL Template, which in turn has one sh:sparql query behind it. 
This SPARQL query, together with the built-in execution language, will 
provide a formal and unambiguous definition of what needs to happen when 
someone executes a sh:minCount constraint. The built-in execution 
language is required as part of the standard because otherwise sh:sparql 
would just be a string without any instructions on how to produce 
sh:ConstraintViolations from it.

Does this clarify it? The intent is clearly that SPARQL is used to 
define the language, yet at the same time SPARQL is also used to 
implement the fall-back mechanism for complex constraints and thus we 
catch two flies with one stone and get a built-in execution language for 
free. This does not mean that everyone must use SPARQL for their 
implementation.

Thanks,
Holger


>
> I suggest this as a substitute for that sentence:
>
> SHACL is defined in this document using SPARQL statements. It may be 
> implemented using any suitable execution language.
>
> Then, if we agree on the intent, I can read through the rest with that 
> in mind.
>
> kc
>

Received on Monday, 16 March 2015 23:07:31 UTC