[TagCommons-WG] SPARQL and query services over tag data

[Richard Newman]

> (Group: Here is a good introductory article on SPARQL that explains  
> that it is both a query language and a data access protocol layered  
> on Web Services.
More accurately, the SPARQL query language is a query language; the  
SPARQL Protocol is a data access protocol, conventionally implemented  
using simple HTTP. I have never seen a SOAP, XML-RPC, or WS-*ey  
implementation of the SPARQL Protocol.
>  I would also point people to the tools and services enabled by the  
> Redland RDF Libraries maintained by Dave Beckett, who is on this  
> list).
There is a moderately complete list at

http://esw.w3.org/topic/SparqlImplementations

I say "moderately" because AllegroGraph is not yet listed, because I  
haven't got round to adding it.
> Your example of revyu.com and del.icio.us is instructive.   As you  
> and others have pointed out, the various ontologies for tagging we  
> have looked at all have core concepts that could be mapped to the  
> data that both revyu.com and del.icio.us expose through APIs.
Or, indeed, to each other through ontology mappings.
> The main difference seems to be in the completeness of the  
> inferential/retrieval services exposed.  I don't know whether being  
> a compliant SPARQL endpoint implies returning results for all legal  
> (and computationally tractable) queries in the language (does SQL?   
> I think so).
Being a compliant SPARQL endpoint means that if the endpoint chooses  
to answer a request (rather than returning QueryRequestRefused), it  
must conform to the SPARQL spec. This still allows it some latitude,  
such as what to do with FROM/FROM NAMED, how to treat the default  
dataset, etc.
> The del.icio.us API only answers some kinds of queries, such as  
> "return all the tag assertions by me".
>
>
> If we specified a tag ontology, and showed how it mapped to various  
> APIs (possibly by just writing some of them as in the XSLT example  
> from Marja), then we would have the ability to write brokers and  
> mediators that could query across sources -- with one caveat.  The  
> broker / mediator would have to know the computational capabilities  
> and limitations of each endpoint, and reason about that.  For  
> example, one service might be able to directly return the set of  
> tag labels for a given item by a given person, whereas another  
> could only return the whole row set of tag assertions by any person  
> using any tag label for the item.
Assuming that each endpoint implements SPARQL, and has the data  
available, no such reasoning is necessary. I think that's excessive  
complexity at this stage.