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

ISSUE-105: Prefixes in SPARQL fragments

From: Holger Knublauch <holger@topquadrant.com>
Date: Sat, 23 Apr 2016 09:35:51 +1000
To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Message-ID: <0469d0e5-2c86-e0ab-5444-6ba3302e04c8@topquadrant.com>
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 Friday, 22 April 2016 23:36:27 UTC

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