Re: Restpark - Minimal RESTful API for querying RDF triples

On 4/16/13 5:47 PM, Luca Matteis wrote:
> Kingsley, this is exactly my problem with SPARQL. So much jargon and 
> complexity. Cursors? Scrollable engine? Column-storage? Vectorized 
> execution?

So you've gotta have the same jargon problem with SQL and RDBMS 
technology too. Why are you singling out SPARQL? Those items are old 
news in the RDBMS realm.

>
> Web service REST APIs are usually located on top of SQL interfaces for 
> this very reason! Because SQL is too complex to be exposed as a 
> service to users!

SQL isn't too complex. It is too limited for the stuff that RDF makes 
possible :-)


Kingsley
>
>
> On Tue, Apr 16, 2013 at 11:38 PM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
>     On 4/16/13 5:22 PM, Aidan Hogan wrote:
>
>         On 16/04/2013 22:05, Kingsley Idehen wrote:
>
>             On 4/16/13 4:15 PM, Aidan Hogan wrote:
>
>
>                 The ability to answer "I don't know" or "cannot
>                 compute right now" or
>                 "I need more time" would make anything trivially
>                 scalable. But "I
>                 don't know" or "cannot compute" or "I need more time"
>                 is not a valid
>                 SPARQL answer. Nor is stopping after the first X
>                 answers are returned.
>
>             Let's have a constructive conversation via SPARQL protocol
>             URLs.
>
>
>         I thought my comments were constructive? (If not, I'd be happy
>         to hear why not.)
>
>         Anyways, as per my previous reply ...
>
>         With respect to this SPARQL query service:
>
>         http://lod.openlinksw.com/sparql
>
>         I would like a response complaint with the SPARQL standard for
>         either of the following two SPARQL queries:
>
>             SELECT * WHERE
>             {?s foaf:knows ?o}
>
>         or
>
>             SELECT * WHERE
>             {?s foaf:knows ?o . ?o foaf:knows ?o2 .}
>
>         Cheers,
>         Aidan
>
>
>
>     Did you perform a count on either? If so, why no LIMIT in the
>     query ?  If you want no LIMIT into what bucket are you placing the
>     result? Would you dare send the following to a decently sized
>     RDBMS and use it as the basis for assessing scale:
>
>     SELECT * FROM TABLE_X
>
>     Anyway, re. my comments above,  SPARQL Protocol URLs:
>
>     1. http://lod.openlinksw.com/c/GNC4S3R -- query result re. count
>     2. http://lod.openlinksw.com/c/GSNV76O -- query definition re. the
>     above.
>
>     So what do you do when the result set exceeds the capacity of the
>     bucket? You make a scrollable cursor (the types vary: snapshot,
>     keyset, dynamic, or mixed model) and then page through the data.
>     Alternatively, you make a multi-dimensional view (known as facets
>     in the RDF / Semantic Web UI world) and you leverage the entity
>     relationship semantics as the basis for a scrollable cursor.
>
>     The paragraph above describes what's happening at:
>     http://lod.openinksw.com/fct -- its a scrollable cursor engine,
>     something that's quite common in the RDBMS realm, but they lack
>     relation semantics of RDF. Same thing applies to column-storage,
>     key compression, and vectorized execution which are also
>     reapplications of RDBMS realm technology in new RDF context so
>     that we have the best of both worlds.
>
>
>
>
>     -- 
>
>     Regards,
>
>     Kingsley Idehen
>     Founder & CEO
>     OpenLink Software
>     Company Web: http://www.openlinksw.com
>     Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>     <http://www.openlinksw.com/blog/%7Ekidehen>
>     Twitter/Identi.ca handle: @kidehen
>     Google+ Profile: https://plus.google.com/112399767740508618350/about
>     LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>


-- 

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