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.

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.


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