W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > April 2016

Re: ISSUE-105: Prefixes in SPARQL fragments

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Sat, 23 Apr 2016 05:52:29 -0700
To: Holger Knublauch <holger@topquadrant.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Message-ID: <571B700D.5090104@gmail.com>
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 Saturday, 23 April 2016 12:53:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:31 UTC