Re: Restpark - Minimal RESTful API for querying RDF triples

On 4/16/13 5:48 PM, Aidan Hogan wrote:
> Hi,
>
> [Sorry, I could have consolidated with previous mail.]
>
> On 16/04/2013 22:10, Kingsley Idehen wrote:
>> On 4/16/13 4:27 PM, Aidan Hogan wrote:
>>> In summary:
>>>
>>> * "SPARQL scales in some cases" = vague, but okay
>>> * "SPARQL scales" = not okay
>> Does SQL scale?
>
> No.
>
>> In short, does any query language scale in this context?
>
> In which context? I don't know if it answers your question, but XPath 
> 1.0 is PTime and is parallelisable. 

So is SPARQL. That and when I mention vectorized execution I am 
referring to doing this in a very fine-grained manner such that threads 
(which execute queries in parallel) are scoped to CPU cores.

> It scales better than SPARQL, but I would still hesitate to call it 
> "scalable".

No it doesn't if it did, we would be showcasing XPath instead of SPARQL 
re. the virtues of massively scalable RDF based Linked Data deployment 
and management.

Note, SPARQL 1.1. offer property paths.

>
> In any case, this is besides the point of whether or not "SPARQL scales".
>
> To reassure, I like SPARQL. I am not criticising SPARQL or saying that 
> there's something that is better than SPARQL at what it does. Anything 
> that offers the power of the SPARQL query language will have the same 
> scalability concerns.

No, not if your scalability yardstick boils down to cursor-less patterns 
against massive datasets of the form:

1. SELECT * FROM TABLE_X
2. SELECT DISTINCT * WHERE {?s ?p ?o}
3. etc..

>
> My core point is that *one cannot make blanket guarantees for 
> scalability with respect to something like SPARQL*. I hope we could 
> agree on that point.

We can, and that's my point. We can make that claim [1] and defend it.

>
>> How does some RESTful pattern scale in a manner that surpasses what's
>> possible with a declarative query language?
>
> ... if it is possible to "support" the RESTful pattern in a compliant 
> manner over larger (general) inputs than likewise possible for the 
> declarative language.

RDBMS engines have known about stored procedures for eons. You can keep 
processing logic close to the data. You can even do much more then 
entity relationship semantics are discernible from the data itself, 
which is where RDF shines.

>
>> My original context for scale was a single interaction pattern over HTTP
>> that's endowed with a declarative query language.
>
> Perhaps we were not originally on the same page then. Apologies if so.

Yes, we cross wires a little, but opened up another interesting topic 
anyhow. Data matters from the RDBMS realm also apply to the RDF DBMS 
realm. If you combine the two the end result is quite special.

>
>> SPARQL Protocol patterns are more scalable than REST interaction
>> patterns since you have one vs a N number of different RESTful patterns.
>
> You mean that if I wanted to run 1 SPARQL query, I would have to 
> create N Restpark requests? I can't imagine that the intention of 
> Luca's proposal is to support generic SPARQL queries.

No, re. REST I am referring to the fact that a zillion different 
developers will come up with a zillion different interaction patterns 
without any uniformity in sight. Should they ever come to some unified 
agreement they'll start a journey towards recreating something like 
SPARQL (query language, protocol, and results serialization formats).

>
>> That said, I am eternally interested in useful SPARQL queries that make
>> a useful case for SPARQL not being scalable when the goal is a useful
>> solution.
>
> See previous mail. :)

Replied :-)

Links:

1. http://bit.ly/14ULX2F -- what you can achieve with 50 - 150 Billion 
Triples when reapply existing technology from RDBMS realm to RDF data 
management.
>
> Cheers,
> Aidan
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen