- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sun, 24 Apr 2016 15:13:59 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
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