Hi Mark,
>> GET /projects?partners=fr&extrafields=funding HTTP/1.0
Granted, this covers one set of use cases. I guess this boils down to
the discussion of when we will see the SPARQL killer app.
So can treat RDF data as a data cube (i.e. multi dimensional data; even
without any special vocab).
So with SPARQL we have a standardized way of accessing data any way we
want (dice and slice the cube in whatever way), which for instance might
become very interesting for Business reporting / Intelligence, when you
can click together your report from a SPARQL endpoint (or at least click
together the table which can be exported to Excel - which is where
SemMap is going). But oh, clicking together data about e.g. Twitter
feeds or Facebook (if it all were RDF) would be just the same workflow.
Combined with SPARQL-push approaches you can then even make a
live-dashboard from the data, by informing a client about changes in a
SPARQL queries corresponding result set. Yes, it will be still a while
until this becomes mainstream, but I would think that once the tooling
support is there, publishing data via SPARQL and making use of it -
especially live- will be faster than wrapping a SPARQL endpoint with a
use case specific REST API and writing the corresponding client.
Cheers,
Claus
On 04/18/2013 04:21 PM, Mark Baker wrote:
On Thu, Apr 18, 2013 at 9:46 AM, Claus Stadler
<cstad...@informatik.uni-leipzig.de> wrote:
For example:
"Show me projects, corresponding partners in France and their amount of
funding". Whats missing in SemMap is just adding UI elements that add
sorting and aggregation to the generated SPARQL query. (Yes, Freebase can do
that too).
Now show me how you would do that with a REST API ;)
GET /projects?partners=fr&extrafields=funding HTTP/1.0
along with a form and supporting declarative metadata describing the
relationship between the two pages in play (the form and the result
page from submitting the form).
More generally, I think an old blog post of mine about REST and SPARQL
is still bang-on about why we haven't, and won't ever, see SPARQL
endpoints being anything other than a niche offered either by those
who can afford to run such a service, or published privately to
partners;
http://www.markbaker.ca/blog/2006/08/sparql-useful-but-not-a-game-changer/
The economics of publication are just drastically different between
exposing a RESTful interface, and exposing a query language.
Mark.
--
Dipl. Inf. Claus Stadler
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org/
Workpage & WebID: http://aksw.org/ClausStadler
Phone: +49 341 97-32260
