Re: Combining multiple queries for execution

I think this inlining of functions should work for many cases, and is 
one of the optimization techniques that would distinguish efficient 
implementations from slow ones. I have personally not worked on inlining 
SPIN functions, but I am sure this can be achieved through nesting { ... 
} blocks.

Likewise, optimized engines could combine multiple constraint checks 
into a single SPARQL string. The spec would only define input and 
expected output, and the internal workings are a matter of 
implementation, just like any SPARQL engine can optimize different 
patterns. For example, in TopBraid we have overloaded several SPIN 
functions with native Java implementations that do not require the 
overhead of instantiating another query execution (spl:object and 
spl:objectCount are examples).

On the topic of round-trips, I would assume that a SPIN-compliant 
database would handle SPIN function calls natively, and therefore no 
extra round-trips would be needed.

Holger



On 11/19/14, 6:43 PM, Arthur Keen wrote:
>
> The discussion on whether or not shapes can be classes touched 
> combining multiple queries into one versus many individual queries for 
> validating a constraint.
>
>> Instead of all these nested SELECTS to compute cardinalities, in SPIN 
>> you would just use the function spl:objectCount(?subject, 
>> ?predicate). Any number of similar helper functions can be defined to 
>> make the queries significantly shorter.
>
> I am focusing the performance and scale tradeoff of one big SPARQL 
> query versus many functionally coupled SPARQL queries.  Short queries 
> are not necessarily less computationally complex than long ones. 
>  There are other factors to consider 1) Multiple database query round 
> trips versus a single optimized round trip, 2) the ability to push 
> down restrictions into subqueries to reduce the data processed, 3) 
> common subquery optimization, and many more optimization techniques. 
>  I understand that SPIN definition for validating constraints could be 
> a call graph relating multiple SPIN functions and that the reference 
> implementation uses procedural logic to control execution of SPARQL 
> queries that result from binding the SPIN functions parameters.
>
> Would it be permissible within the scope of the specification for an 
> implementer to view the SPIN definition for constraints as a logical 
> specification and then for actually validating constraints generate 
> equivallent nested subqueries in one large SPARQL query that is 
> submitted to the system?  Ignoring recursion and iteration, this would 
> allow the implementor to leverage SPIN for compositionality and 
> interoperability and choose how queries are actually packaged for 
> execution.
>
> Arthur K
>
>
>
> Arthur Keen,
> Chief Scientist
> arthur.keen@sparqlcity.com <mailto:arthur.keen@sparqlcity.com>
>
>
> *SPARQLcity reshapes the world of big data.*
> Immediately gain knowledge from NoSQL databases.