- From: Jürgen Jakobitsch SWC <j.jakobitsch@semantic-web.at>
- Date: Thu, 18 Apr 2013 13:21:14 +0200
- To: Leigh Dodds <leigh@ldodds.com>
- Cc: public-lod@w3.org
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> 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 > e: 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 | Fax +43.1.402 12 35 - 22 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#"
Received on Thursday, 18 April 2013 11:21:50 UTC