sh:sparqlFilter (was: On the inevitability of SPARQL/SPIN for SHAQL)

On 3/3/2015 13:04, Peter F. Patel-Schneider wrote:
> Even if other execution languages for SHACL are possible, an execution 
> language selector in SHACL will only balkanize SHACL. 

Related to this, I had thought about allowing something like 
sh:sparqlFilter as syntactic sugar, as illustrated in the following example

ex:MyShape
     sh:constraint [
         sh:message "All values of myProperty must be IRIs" ;
         sh:path ex:myProperty ;
         sh:sparqlFilter "!isIRI(?value)" ;
     ] .

which would be translated into

SELECT (?this AS ?root) (ex:myProperty AS ?path) ?value
WHERE {
     ?this ex:myProperty ?value .
     FILTER (!isIRI(?value))
}

This may potentially provide a cleaner separation of selection paths and 
a FILTER condition, probably closer to what Jose suggested in his XPath 
discussion. If SPARQL is the main language, then the property 
sh:sparqlFilter could be called sh:filter.

It however also raises new questions:
- adds complexity to implementers/new users
- many ways of representing the same thing
- some tools may decide to only support those (another balkanization)
- unclear whether FILTER should return true or false (as with ASK)
- it would still only address a (small?) fraction of the overall problem 
space
- it may invite similar properties such as sh:xpath - unclear whether we 
want this

So that relative benefits of this proposal would need to be carefully 
evaluated. The Simister/Brickley paper [1] had a similar idea.

Regards,
Holger

[1] 
http://www.w3.org/2001/sw/wiki/images/0/00/SimpleApplication-SpecificConstraintsforRDFModels.pdf

Received on Tuesday, 3 March 2015 03:22:34 UTC