Re: SPARQL, philosophy n'stuff..

On 4/18/13 7:46 AM, Luca Matteis wrote:
> How about the fact that SPARQL is very complex to implement on top of 
> existing storage solutions? You need to use a proper triple store (RDF 
> database such as Virtuoso), and be sure it implements all of SPARQL 
> features correctly.

What does that mean? That's the kind of generic comment that ultimately 
opens up a can or worms.

>
> Having a lightweight alternative to SPARQL which developers could 
> implement themselves on top of their existing storage solution (MySQL, 
> MongoDB, etc.) using the language they want (PHP, Java, Node.js), 
> would lower the entry barrier for Semantic Web data understanding and 
> retrieval.

What lightweight examples exist for SQL or any other query language?

Data access technology history isn't hard to find. Ditto the history of 
DBMS oriented query languages.

Show me an example and I'll triangulate back to some branch in the Data 
Access technology genealogy tree.

Slapping "complexity" on to of SPARQL isn't the way to go. There is much 
more to it than jumping to such conclusions.


Kingsley

>
> On Thu, Apr 18, 2013 at 1:21 PM, Jürgen Jakobitsch SWC 
> <j.jakobitsch@semantic-web.at <mailto:j.jakobitsch@semantic-web.at>> 
> wrote:
>
>     i think there's yet another point overlooked :
>
>     what we are trying to do is to create barrier free means of
>     communication on data level in a globalized world. this effort
>     requires
>     a common language.
>
>     my personal view is that providing simplier subsets of such a language
>     (an api) only leads to the fact that nobody will learn the
>     language (see
>     pocket calculators,...), although there's hardly anything easier
>     than to
>     write a sparql query, it can be learned in a day.
>
>     i do not really understand where this "the developer can't sparql, so
>     let's provide something similar (easier)" - idea comes from.
>
>     did anyone provide me with a wrapper for the english language?
>     nope, had
>     to learn it.
>
>     wkr jürgen
>
>     On Thu, 2013-04-18 at 11:27 +0100, Leigh Dodds wrote:
>     > Hi Hugh,
>     >
>     > On Thu, Apr 18, 2013 at 10:56 AM, Hugh Glaser
>     <hg@ecs.soton.ac.uk <mailto:hg@ecs.soton.ac.uk>> wrote:
>     > > (Yes, Linked Data API is cool!, and thanks for getting back to
>     the main subject, although I somehow doubt anyone is expecting to
>     read anything about it in this thread now :-) )
>     >
>     > I'm still hoping we might return to the original topic :)
>     >
>     > What this discussion, and in fact most related discussions about
>     > SPARQL as a web service, seems to overlook is that there are several
>     > different issues in play here:
>     >
>     > * Whether SPARQL is more accessible to developers than other
>     forms of
>     > web API. For example is the learning curve, harder or easier?
>     >
>     > * Whether offering query languages like SPARQL, SQL, YQL, etc is a
>     > sensible option when offering a public API and what kinds of quality
>     > of service can be wrapped around that. Or do other forms of API
>     offer
>     > more options for providing quality of service by trading off
>     power of
>     > query expression?
>     >
>     > * Techniques for making SPARQL endpoints scale in scenarios
>     where the
>     > typical query patterns are unknown (which is true of most public
>     > endpoints). Scaling and quality of service considerations for a
>     public
>     > web service and a private enterprise endpoint are different. Not all
>     > of the techniques that people use, e.g. query timeouts or partial
>     > results, are actually standardised so plenty of scope for more
>     > exploration here.
>     >
>     > * Whether SPARQL is the only query language we need for RDF, or for
>     > more general graph databases, or whether there are room for other
>     > forms of graph query languages
>     >
>     > The Linked Data API was designed to provide a simplified
>     read-only API
>     > that is less expressive than full SPARQL. The goals were to make
>     > something easier to use, but not preclude helping developers towards
>     > using full SPARQL if that's what they wanted. It also fills a
>     > short-fall with most Linked Data publishing approaches, i.e. that
>     > getting lists of things, possibly as a paged list, possibly with
>     some
>     > simple filtering is not easy. We don't need a full graph query
>     > language for that. The Linked Data Platform is looking at that area
>     > too, but its also got a lot more requirements its trying to address.
>     >
>     > Cheers,
>     >
>     > L.
>     >
>     > --
>     > Leigh Dodds
>     > Freelance Technologist
>     > Open Data, Linked Data Geek
>     > t: @ldodds
>     > w: ldodds.com <http://ldodds.com>
>     > e: leigh@ldodds.com <mailto:leigh@ldodds.com>
>     >
>
>     --
>     | Jürgen Jakobitsch,
>     | Software Developer
>     | Semantic Web Company GmbH
>     | Mariahilfer Straße 70 / Neubaugasse 1, Top 8
>     | A - 1070 Wien, Austria
>     | Mob +43 676 62 12 710 <tel:%2B43%20676%2062%2012%20710> | Fax
>     +43.1.402 12 35 - 22 <tel:%2B43.1.402%2012%2035%20-%2022>
>
>     COMPANY INFORMATION
>     | web       : http://www.semantic-web.at/
>     | foaf      : http://company.semantic-web.at/person/juergen_jakobitsch
>     PERSONAL INFORMATION
>     | web       : http://www.turnguard.com
>     | foaf      : http://www.turnguard.com/turnguard
>     | g+        : https://plus.google.com/111233759991616358206/posts
>     | skype     : jakobitsch-punkt
>     | xmlns:tg  = "http://www.turnguard.com/turnguard#"
>
>
>


-- 

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