Warning:
This wiki has been archived and is now read-only.

Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)

From Linked Data Platform
Jump to: navigation, search

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
LDP Container

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
Body: LDPR R identified by URI-R

GET

REQUIRED

200 C

To /rdf-graph-store?graph=<URI-R> endpoint

200

C

REQUIRED

200

C

303

Redirection to URI-C?firstpage

HEAD

REQUIRED

No added headers

REQUIRED

No added headers

OPTIONS

Not specified

REQUIRED

No added headers

PUT

REQUIRED


201

C created

200, 204

C replaced

400

Payload is not parseable according to Content-type header

appropriate

C could not be replaced/created

To /rdf-graph-store?graph=<URI-R> endpoint


201

C created; Location: URI-R

REQUIRED


201

C created; Location: URI-C

POST

REQUIRED


200

append to C

To /rdf-graph-store?graph=<URI-R> endpoint 


201

C created; Location: URI-C

REQUIRED


200

append R in body to C; Location: URI-R

DELETE

REQUIRED

200, 204

C deleted

404

C does not exist

REQUIRED

200

delete C; delete members

PATCH

OPTIONAL

Informative

With SPARQL UPDATE in body

422

modified graph is not exclusively C

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

200

R

To /rdf-graph-store?graph=<URI-R> endpoint

200

R

REQUIRED


200

R

303

Redirection to URI-R?firstpage

HEAD

REQUIRED

No added headers

REQUIRED

Same headers as OPTIONS

OPTIONS

Not specified

REQUIRED

PUT

REQUIRED

201

R created

200, 204

R replaced

400

Payload is not parseable according to Content-type header

appropriate

R could not be replaced/created

To /rdf-graph-store?graph=<URI-R> endpoint

201

R created; Location: URI-R

REQUIRED

201

R created

200, 204

R replaced

412

R not replaced, collision detected

428

No precondition for condtional request, R not replaced/created

appropriate

R could not be replaced

POST

REQUIRED

200

append to R

To /rdf-graph-store?graph=<URI-R> endpoint 

201

R created; Location: URI-R

Not specified

DELETE

REQUIRED

200, 204

R deleted

404

R does not exist

REQUIRED

200, 204

R deleted

404, 410

R does not exist

PATCH

OPTIONAL

Informative

With SPARQL UPDATE in body

422

modified graph is not exclusively C

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