Re: SPARQL, philosophy n'stuff..

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
> <cstadler@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

Received on Thursday, 18 April 2013 14:54:51 UTC