- From: Ashok Malhotra <ashok.malhotra@oracle.com>
- Date: Thu, 20 Sep 2012 05:07:10 -0700
- To: public-ldp-wg@w3.org
The link took me to an unpopulated website. All the best, Ashok On 9/20/2012 1:02 AM, Andy Seaborne wrote: > > > On 19/09/12 23:56, Ashok Malhotra wrote: >> Thanks, Andy, that very useful but your example >> http://server/graphstore?graph=http://example/snapshot556 >> did not work for me. > > In what way do you mean "did not work"? It's just an example, of named graph <http://example/snapshot556> at graph store <http://server/graphstore>, not an operational system. > > It is simply not possible to manage a typical graph store without some way to name a graph by full IRI so indirect naming is a MUST for GSP. The fact that this unfriendly format has to used is "unfortunate" (worse - it has to be %-encoded to be used). > > Andy > >> All the best, Ashok >> >> On 9/19/2012 2:48 PM, Andy Seaborne wrote: >>> tl;dr: >>> >>> GSP is a description of how to use HTTP for data management. It >>> defines very little; it is a direct use of HTTP. >>> >>> LDBP provides a higher level notion of resource - it places >>> restrictions on data to enhance app interoperability but making it >>> unsuitable for general data management. >>> >>> They are addressing different use cases. >>> >>> ---------------------------------- >>> >>> See [1] - I see the two protocols (LBDP and GSP) as siblings both >>> built on RFC 2616. They have different use cases. >>> >>> LBDP adds machinery and restrictions to the use of HTTP in order to >>> provide a lifecycle. >>> >>> GSP is a data management protocol for SPARQL graph stores. It defines >>> only: >>> >>> GSP-1: Indirect naming. >>> GSP-2: POST means add triples. >>> >>> it is arguable that GSP-2 is "defining" anything because in RFC2616 >>> section 9.5 already says: >>> """ >>> - Extending a database through an append operation. >>> """ >>> >>> So GSP defines indirect naming, nothing else. This has been shown to >>> be a useful and effective means of managing a graph store 9a >>> collection of graphs). GSP is deployed and in use today with multiple >>> implementations. >>> >>> Indirect naming is the ability to have a graph name in a store that is >>> not related to the local server name. It is a common usage for graph >>> store management. >>> >>> http://server/graphstore?graph=http://example/snapshot556 >>> >>> Other than that, GSP is a description of how HTTP (RFC 2616) applies >>> to a graph store. GET means GET, PUT means create/replace, POST means >>> add data, DELETE means delete. A valid implementation of direct >>> naming GSP is a file-system backed HTTP server. >>> >>> GSP has no concept of a container with an RDF presentation or >>> containers-in-containers or of paging or ordering. >>> >>> LDBP does not consider indirect naming. >>> >>> LDBP is unsuitable for data management - it forbids general RDF data, >>> for example. (4.1.9 - "BPR representations MUST use only the following >>> standard datatypes"; 4.4.5 is also problematic where it hints at >>> changing the predicates it does understand; 4.1.4 is at odds with IRI >>> resolution; other requirements are problematic in intent and approach). >>> >>> If LDBP for BPRs removes the restrictions on simple "upload-download" >>> to result in the same data then it might be able to use GSP(direct), >>> and in fact it would just be RFC2616. >>> >>> LDBP for BPCs is not relevant for graph stores. Graph stores do not >>> have such a container model. >>> >>> Alternative: >>> >>> Why not make LDBP for BPRs be simply a link to RFC 2616? + discussion >>> that text/turtle be provided. Then a plain HTTP server can be used to >>> provide LDBP for BPRs (not BPCs). >>> >>> > The reality is that many implementations of LDBP will be >>> > based on graph stores, >>> >>> The key here is "will be based on graph stores" rather than "will be >>> graph stores" -- the graph store is not directly implementing LDBP >>> but being used to implement it. There will need an additional layer >>> to implement the requirements specific to LDBP like containers. >>> >>> One final comment - I see nowhere in the submission that precludes a >>> single graph, which has all the resources and containers in it. A >>> graph store - multiple graphs, flat structure - is not necessary. Do >>> you want to constraint >>> >>> Andy >>> >>> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0004.html >>> >> >
Received on Thursday, 20 September 2012 12:07:40 UTC