Re: Restpark - Minimal RESTful API for querying RDF triples

Kingsley, this is exactly my problem with SPARQL. So much jargon and
complexity. Cursors? Scrollable engine? Column-storage? Vectorized
execution?

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!


On Tue, Apr 16, 2013 at 11:38 PM, Kingsley Idehen <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 <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<http://lod.openlinksw.com/c/GNC4S3R>-- query result re. count
> 2. http://lod.openlinksw.com/c/**GSNV76O<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/~kidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>