Combining multiple queries for execution

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


-- 

*SPARQLcity reshapes the world of big data.*
Immediately gain knowledge from NoSQL databases.