W3C home > Mailing lists > Public > public-egov-ig@w3.org > April 2010

Re: [dcat] Tomorrow's dcat Agenda

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>
Message-ID: <7371.1271964242@waldron>

> > [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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:43 UTC