Re: SPARQL GSP vs BP

(after s/GPS/GSP/g)

* Steve K Speicher <sspeiche@us.ibm.com> [2012-07-09 08:53-0400]
> > From: Arnaud Le Hors/Cupertino/IBM@IBMUS
> > To: public-ldp-wg@w3.org, 
> > Date: 07/05/2012 10:59 AM
> > Subject: SPARQL GSP vs BP
> > 
> > Looking at how the SPARQL Graph Store Protocol (GSP) and Basic Profile 
> (BP) 
> > submission compare, the most obvious difference I see is the fact GSP 
> > primarily deals with "graphs" while BP deals with Basic Profile 
> Resources 
> > and Containers. 
> > 
> > So, I'd like to ask whether considering a BPR as a graph would, at least 
> to 
> > some extend, provide some alignment between the two specs. I think two 
> > aspects need to be considered: 1) what URL is used, 2) what triples are 
> returned. 
> > 
> > Thoughts?
> 
> Disclaimer: I have no implementation experience with this and only a basic 
> understand on the review given on a previous call.
> 
> 1) GSP for SPARQL-compliant graph store implementation and wants to expose 
> it via HTTP (even though the abstract says it isn't limited to this), in 
> contrast with BP where someone may not have a SPARQL-compliant graph 
> store.
> 
> 2) I also see BP as being focused on the resource-centric view of the web 
> with access and manipulation of the resource being done via HTTP and 
> representations.  GSP is mapping HTTP operations to named graphs.
> 
> 3) BP of course adds a number of rules on representations, including 
> defining a best practice concept of containers
> 
> I believe that there is value in both and they are not the same.   If GSP 
> was built "on top" of BP, it would impose perhaps too many rules on 
> resources and their representations.  If BP was built "on top" of GSP, it 
> would impose graph constraints.

The mapping of BP resources to GSP graphs seems pretty inevitable to me. We can measure this by examining how much of BP *could be* implemented by a generic SPARQL engine. The Annotea (which was similar to Basic Profile app) implementation knew as little as possible about annotations and bookmarks as possible. The guts were all a generic query languags (Algae2) which recognized a list of patterns (which happened to corresponded to shared annotations and bookmarks) and mapped particular blank nodes to newly-minted resource names. SPARQL doesn't have a built-in mechanism to add the magic arcs (dc:creator, dc:date in Annotea's case, these and a bunch more for BP <http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/#bpr-prop>), but then neither did Algae2. In this respect BPR looks like GSP graphs with a few more restrictions/semantics.

Containers in BP (as in Annotea) can also be particular advertised URLs which *could be* mapped internally to queries queries, with a bit thicker custom semantics layer than exists for BPR; we'd expect that PUTs to collections would either do something very very clever, or just not be allowed.

I've described BP as being implementable as a thin veneer over a graphs store. As it turns out, I created Algae2 'cause I wanted to factor out a lot of code from the Annotea implementation, but this factoring of API code into a generic query language may not float everyone's boat.


> It would seem that GSP would be more analogous to a SPARQL endpoint, while 
> BP would be analogous to the access and manipulation of resources based on 
> their URL directly.
> 
> Perhaps we should start a wiki page to track a more detailed comparison?
> 
> Thanks,
> Steve Speicher | IBM Rational Software | (919) 254-0645
> 
> 

-- 
-ericP

Received on Monday, 9 July 2012 14:21:00 UTC