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 <[email protected] <mailto:[email protected]>> 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




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to