Re: ISSUE-105: Prefixes in SPARQL fragments

On Apr 24, 2016 7:15 AM, "Holger Knublauch" <holger@topquadrant.com> wrote:
>
> 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.

This doesn't address Mark's comment about cut/pastability but very nicely
reduces the uncertainty associated with default prefixes.

> 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
>>>
>>>
>
>