SPARQL, philosophy n'stuff..

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