Re: ISSUE-105: Prefixes in SPARQL fragments

That's an interesting thought, Peter. We could extend and generalize 
this further, basically eliminating the problem of possible prefix 
conflicts: Each sh:sparql triple is already wrapped into an object (such 
as sh:SPARQLValuesDeriver, sh:SPARQLSelectValidator, subclasses of 
sh:SPARQLExecutable) in the current draft. These wrapper objects could 
all have another property sh:prefixes, making it explicit which prefixes 
are to be used:

sh:DefaultPrefixes
     a sh:PrefixDeclaration ;
     sh:prefix [ sh:prefix "rdf" ; sh:namespace "http://..." ] ;
     sh:prefix [ sh:prefix "owl" ; sh:namespace "http://..." ] ;
     ...

ex:MyPrefixes
     a sh:PrefixDeclaration ;
     sh:extends sh:DefaultPrefixes ;
     sh:prefix [ sh:prefix "ex" ;  sh:namespace "http://example.com/ns#" ] .

and then

ex:MyShape
     a sh:Shape ;
     sh:property [
         sh:predicate ex:grandParent ;
         sh:derivedValues [
             a sh:SPARQLValuesDeriver ;
             sh:prefixes ex:MyPrefixes ;
             sh:sparql "$this ex:parent/ex:parent ?value" ;
         ]
     ] .

Very chatty syntax, but hopefully closer to acceptable to those who are 
currently against the whole idea.

Holger

On 23/04/2016 22:52, Peter F. Patel-Schneider wrote:
> Another possible approach would be to have a property on these constructs that
> provided prefixes for the construct only, as in
>
> ex:MyShape
>      a sh:Shape ;
>      sh:property [
>          sh:predicate ex:grandParent ;
>          sh:derivedValues [
>              a sh:SPARQLValuesDeriver ;
>              sh:prefixHere ( "ex" "http://example.com" ) ;
>              sh:sparql "$this ex:parent/ex:parent ?value" ;
>          ]
>      ] .
>
> On 04/22/2016 04:35 PM, 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 Sunday, 24 April 2016 05:14:35 UTC