- 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