Re: ISSUE-105: Prefixes in SPARQL fragments

FYI, I fixed a problem with sh:derivedValues. Previously, the sh:sparql 
queries there were expected to be SPARQL fragments, but this did not 
allow users to insert PREFIX declarations. In the new version, these 
values need to be SELECT queries. I assume this change is 
uncontroversial, as it removes the need for sh:prefix triples in another 
place and makes the overall use of SPARQL in SHACL more consistent.

https://github.com/w3c/data-shapes/commit/4e32b59a4940091a6602e892cd2bca68ad4e0d6d

Now the only other place where fragments would appear is in path 
expressions, if we ever want to support them, and for these we could 
theoretically create a triple-based syntax with classes such as 
sh:InversePath etc.

Holger



On 23/04/2016 9:35, Holger Knublauch wrote:
> I just thought about another problem with prefixes. Currently we have 
> one construct in the spec that operates on SPARQL fragments:
>
> ex:MyShape
>     a sh:Shape ;
>     sh:property [
>         sh:predicate ex:grandParent ;
>         sh:derivedValues [
>             a sh:SPARQLValuesDeriver ;
>             sh:sparql "$this ex:parent/ex:parent ?value" ;
>         ]
>     ] .
>
> Without something like sh:prefix, people would need to always spell 
> out the full URIs, because they cannot create PREFIX declarations in a 
> SPARQL fragment. We already do have other use cases of such fragments 
> in our tool suite (for expressions that constraint the applicability 
> of menu items etc), and it is quite plausible that the WG may want to 
> adopt the following syntax for path-based constraints in the future:
>
> ex:MyShape
>     a sh:Shape ;
>     sh:constraint [
>         a sh:PathConstraint ;
>         sh:path "ex:parent/ex:parent" ;
>         sh:minCount 2 ;
>         sh:maxCount 4 ;
>     ] .
>
> Without sh:prefix we would essentially rule out these syntactic 
> choices, unless we can get users enthusiastic about always using full 
> URIs.
>
> As always, there are work-arounds, e.g. we could force everything to 
> be SELECT or ASK queries. But at some stage I find the pain points are 
> really becoming too big.
>
> Thanks,
> Holger
>

Received on Monday, 9 May 2016 05:36:33 UTC