- From: Sandro Hawke <sandro@w3.org>
- Date: Thu, 22 Apr 2010 15:24:02 -0400
- To: Erik Wilde <dret@berkeley.edu>
- cc: Cory Casanave <cory-c@modeldriven.com>, public-egov-ig@w3.org, Richard Cyganiak <richard@cyganiak.de>
> > [cbc] All I can tell you is we and many others use REST interfaces to
> > RDF graphs and it works very well (including SPARQL at the same
> > endpoint) - REST & RDF are orthogonal just like XML and REST are
> > orthogonal.
>
> yes, REST and RDF are orthogonal. using RDF/semweb does not solve the
> problems that REST solves, such as telling me where to go if i want to
> do things, and what i can do there. (this is where quite a bit of
> "discovery" research work has been done in the semweb community.) it
> also is the reason why i was pointing out that we should look at
> services, too, because regardless of whether egov data is exposed as XML
> or JSON or RDF or CSV, it will be important to know what services you
> can use, i.e. where to go, and how to interact with those services, such
> as how you can for example update or annotate data. and in the same way
> as you don't give the world SQL access to your relational data, my guess
> is that you won't give the world SPARQL access to your RDF data;
Quite the contrary. If people have their data in an DBMS now, putting a
SPARQL endpoint in front of it is a great way to expose it to the world.
That's one of the main use cases for SPARQL, and one of its advantages
over SQL.
> the
> main reasons being that you want to be able to enforce constraints,
The current version of SPARQL is read-only, so that's not a problem.
When update is included (soon), sure, you'll need to do this, but you
can do it in the middle or back end. It's not a protocol issue.
> exercise access control,
No problem. Expose the tables you want via the endpoint you want.
> control optimized access paths,
That's kind of a philosophical point, with a tradeoff. Do you want to
dictate exactly which queries are allowed? Or do you want to allow all
queries, and try to make the common ones run faster?
> and you want
> the services to be independent of implementation details.
Exactly -- SPARQL is an interface protocol, independent of how your data
is stored and managed.
Also, as I mentioned during the call, once you have your data available
through a SPARQL endpoint, there are emerging tools that can provide
more traditional JSON and XML interfaces; hopefully we'll have some good
HTML ones too, soon.
-- Sandro
Received on Thursday, 22 April 2010 19:24:05 UTC