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