Re: ISSUE-95: Template Simplifications

On 10/30/2015 9:16, Peter F. Patel-Schneider wrote:
> On 10/29/2015 03:50 PM, Holger Knublauch wrote:
>> On 10/30/2015 4:04, Peter F. Patel-Schneider wrote:
>>> On 10/28/2015 10:29 PM, Holger Knublauch wrote:
>>>> On 10/29/2015 14:14, Peter F. Patel-Schneider wrote:
>>> [...]
>>>>> 9.5
>>>>>
>>>>> [Remove, as implementing this will require parsing and modifying SPARQL
>>>>> bodies.]
>>>> What modifications are required? I had explained how these are invoked in 7.6
>>> Well then I don't understand how 7.6 is supposed to work.
>>>
>>> It appears to me that somehow the body of the node validation function is
>>> going to have to be modified and injected into the generated SPARQL query, so
>>> that !{validationFunction} can be executed.
>> Take the node validation function sh:hasDatatype as an example. The call would
>> become
>>
>>      FILTER (!sh:hasDatatype(?object, $datatype)) .
>>
>> i.e. no difficult SPARQL manipulation would be required.
>>
>> Holger
> So instead of code injection this requires the ability to call not just
> functions that have been implemented in the engine beforehand, but also the
> ability to call functions that are constructed on the fly?
>
> I suppose that this does get away from SPARQL manipulation here, but
> on-the-fly function generation doesn't seem to be a common facility in SPARQL
> engines.

It doesn't have to be on-the-fly. There are various implementation 
strategies to install the new functions beforehand. Usually there is a 
limited number of shapes graphs in a system. Installing new functions 
only needs to be done on the first call to SHACL with a given shapes 
graph. In TopBraid we also have a mechanism that walks through all SPIN 
files in the workspace (folders containing the RDF files) to pre-load 
all functions. But our Jena implementation can also create functions on 
the fly, by looking at the current query graphs.

Yes, this isn't necessarily a cheap feature, but - trust me - once you 
have gotten used to working with such functions, you would never want to 
go back. In many practical use cases (large commercial projects) SPARQL 
queries would become completely unmaintainable if we had to repeat the 
same patterns and sub-queries over and over again.

Holger

Received on Thursday, 29 October 2015 23:26:49 UTC