Warning:
This wiki has been archived and is now read-only.
Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)
Comparison: GSP vs LDP
This document gives a detailed overview of the comparison between the SPARQL 1.1 Graph Store Protocol (GSP) and the Linked Data Platform (LDP).
From the start GSP was identified as a specification LDP overlaps with. The Working Group therefore had a look at how GSP and the Linked Data Basic Profile submission compare and discussed what ought to be done.
The WG concluded that the two specifications aren't very different but because they have different goals they cannot be fully reconciled. As of September 2012, LDP was merely an Editor's draft while GSP was in Last Call with a WG ready to disband so, there was basically no way GSP could be modified in any significant way to align with LDP. If any alignment was possible it ought be done on the LDP side.
Based on this, the LDP WG decided on its September 17th, 2012 call that it will seek to align LDP to GSP as much as possible.
See email thread and minutes for further details.
This document discusses these two specifications in three contexts: general, operations and coexistence.
1 General
Graph Store Protocol (GSP) |
Linked Data Platform (LDP) | |
---|---|---|
W3C Spec Dependence |
Part of SPARQL 1.1 |
Stand-alone |
W3C Spec status |
Recommendation |
Working Draft |
Foundation |
HTTP 1.1 |
HTTP 1.1 |
Restricted Equivalence |
Subset of SPARQL 1.1 Update Language |
None |
2 Operations
On the operation level, both specifications are closely related when accessing resources. However, they differ significantly on the semantics-based functionality.
GSP, as its name implies, can be seen as a HTTP protocol definition on how to interact with a quad (graph) store. The model, as seen as from HTTP clients, can be that HTTP resources are equal to a graph. This is useful for HTTP clients that know they are working with graph stores. These graphs group triples under one URI, but do not imply any extra functionality.
In LDP, this is not the case. LDP looks to abstract away the server storage model and focus on the protocol for the lifecycle of HTTP resources and relationships (links and containers). LDP could be implemented with a graph store underneath. LDP specific semantics, confined in the RDF, imply certain server behaviour. An important example is an LDP ‘collection’. This distinction is discussed later on.
The following table summarizes the high-level characteristics of the two:
Graph Store Protocol (GSP) |
Linked Data Platform (LDP) | |
---|---|---|
Mutable objects |
Named Graph |
LDP Resource |
Required representation support |
TURTLE, RDF/XML or N-Triples |
TURTLE |
Security |
HTTP Conformance |
Not specified |
Semantics based functionality |
No |
Yes |
Paging |
No |
Yes |
Sorting |
No |
Yes |
Multipart/form-data |
Yes |
Not specified |
2.1 Collections
The notion of ‘collection’ is very different between both protocols.
Graph Store Protocol (GSP) |
Linked Data Platform (LDP) | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Request |
Graph C identified by URI-C |
LDPC C identified by URI-C | ||||||||||||
GET |
REQUIRED
To /rdf-graph-store?graph=<URI-R> endpoint
|
REQUIRED
| ||||||||||||
HEAD |
REQUIRED No added headers |
REQUIRED No added headers | ||||||||||||
OPTIONS |
Not specified |
REQUIRED No added headers | ||||||||||||
PUT |
REQUIRED
To /rdf-graph-store?graph=<URI-R> endpoint
|
REQUIRED
| ||||||||||||
POST |
REQUIRED
To /rdf-graph-store?graph=<URI-R> endpoint
|
REQUIRED
| ||||||||||||
DELETE |
REQUIRED
|
REQUIRED
| ||||||||||||
PATCH |
OPTIONAL Informative With SPARQL UPDATE in body
|
OPTIONAL |
2.2 Resources
Graph Store Protocol (GSP) |
Linked Data Platform (LDP) | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Request |
Graph R identified by URI-R |
LDPR R identified by URI-R | ||||||||||||||||||||
GET |
REQUIRED
To /rdf-graph-store?graph=<URI-R> endpoint
|
REQUIRED
| ||||||||||||||||||||
HEAD |
REQUIRED No added headers |
REQUIRED Same headers as OPTIONS | ||||||||||||||||||||
OPTIONS |
Not specified |
REQUIRED | ||||||||||||||||||||
PUT |
REQUIRED
To /rdf-graph-store?graph=<URI-R> endpoint
|
REQUIRED
| ||||||||||||||||||||
POST |
REQUIRED
To /rdf-graph-store?graph=<URI-R> endpoint
|
Not specified | ||||||||||||||||||||
DELETE |
REQUIRED
|
REQUIRED
| ||||||||||||||||||||
PATCH |
OPTIONAL Informative With SPARQL UPDATE in body
|
OPTIONAL Add Accept-Patch header Body is not specified |
2.3 Coexistence
When Linked Data Platform and Graph Store Protocol cohabit on one a server, conflicts can arise. When sharing a set of triples, they can break their counterpart. GSP generally ignores the semantics of the triples, making the LDP service is the most ‘at risk’. However, GSP defines a specific endpoint to handle graph creation, which could be influenced by the manipulation functionality of LDP collections. In the table below, we provide an overview of the various coexistence conflicts.
LDP Resource = GSP graph |
LDP Container = GSP graph |
LDP Resource = GSP endpoint |
LDP Container = GSP endpoint | |
---|---|---|---|---|
GET |
No conflict |
No conflict |
No conflict, GSP returns undefined |
No conflict, GSP returns undefined |
HEAD |
No conflict |
No conflict; added LDP headers |
No conflict; added LDP headers |
No conflict; added LDP headers |
OPTIONS |
No conflict |
No conflict; added LDP headers |
No conflict; added LDP headers |
No conflict; added LDP headers |
PUT |
No conflict |
No conflict |
Conflict |
Conflict |
POST |
No conflict |
No conflict? Different functionality is to be expected, but do not influence each other |
Conflict |
Conflict |
DELETE |
No conflict |
No conflict |
No conflict |
No conflict |
PATCH |
No conflict |
Conflict; changes through GSP can break consistency in LDPC |
No conflict |
No conflict |