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