1. Introduction
2. Notational Conventions
3. Terminology
4. Data Type Prefixes
5. Namespaces
6. Protocol Overview
7. Authentication
8. Protocol Operations
8.1. Submitting a New Document
8.1.1 Submitting a New Document with no self description
8.1.2 Submitting a New Document containing self description
8.1.3 Two-Part submission. Obtaining a directy editable Edit-IRI first.
8.2. Updating an Existing Document
8.2.1 Document Direct Update
8.2.2 In-Direct Document Update
8.3. Deleting Data
8.3.1 Deleting a Document
8.3.2 Delete via POST
8.3.3 Deleting Data
8.4 Retrieving Data
8.4.1 Implementing a Timegate
9. References
Technical Lead: David Tarrant, University of Southampton
Project Manager: Bram Van Der Werf, Open Planets Foundation
Technical Advisory Group
Chris Gutteridge, University of Southampton
Ian Millard, University of Southampton
Further acknowledgements of input
Linked-data is quickly becoming a widely used technology. However, maturity of best practices, management specifications and support for quad based models (to allow versioning and provence) are all still in their early stages of development. This specfication outlines an HTTP CRUD (Create, Retrieve, Update, Delete) based method for managing, versioning and tracking linked-data which supports provenance techniques.
This sepecification is based heavily on existing HTTP techniques and recommends some best practices for storing and managing documents containing data pertaining to a number of objects. By utilising the GUID, each document can be managed to create, update and delete data relating to objects being described. As the objects themselves cannot be edited directly, the document management system strictly enforces versioning and provenance support.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Throughout this document we will regularly refer to several items in a specific context, these are outlined here:
In order to segment data into understandable catagories, it is RECOMMMENDED that a series of data type prefixes be used. The main aim is to separate documents from physical/virtual things and separate both of these from dynamic data/metadata/reports which result from interacting with these things. Documents can describe both but should be careful with IRI/URI usage. The following IRIs and URIs are RECOMMENDED as best practise.
Several common namespaces in Linked-data shall be refered to by the following shorthand notation.
Data is managed but Creating, Reverting, Updating and Deleting (a variation on CRUD) Documents. No direct manipulation of objects is permitted other than retrieval.
When a Document is POST/PUT into the system, a document Edit-IRI is either created/identified or manually submitted by the user. This Edit-IRI MUST conform to the Edit-IRI namespace schema outlined by the host system. In the event where the submitting user has identified a different IRI, this MAY be translated into a conforming IRI if possible.
Data pertaining to the EDIT-URI MUST only relate to that document and SHOULD contain data such as when the document was created, by whom and with which tools. Data relating to the time the document was submitted and by who MUST be added (or checked existing) by the server side application handling the document submission.
The server SHOULD perform a series of checks to ensure that the document is appropriate for acceptance into the data store and the client MUST be able to handle the messages returned by the server.
Once a document is accepted, the server will return both the Edit-IRI and a static Doc-URL. The Edit-IRI MUST be capable of accepting Update and Delete requests. The Doc-URL gives the location of a specific version of the document, in most cases the one created as a result of the previous operation.
Authentication (if required) SHOULD use either Authenticated REST Requests (as per [Amazon Authentication Model]) or HTTP basic auth. It is recommended that Authenticated REST Requests be used where possible.
Unit Test | /unit_tests/authentication |
Result Exemplar | - |
A unit test client is available here to check Amazon based REST requests against a server implemtation. A server MUST supply an example file at http://server-name.com/tests/auth against which anyone can authenticate.
While specific HTTP status codes are used below, a client should be prepared to handle any status code as per the HTTP status code definitions [RFC2616]
There are two main considerations when submitting a new document which are outlined individually in this section.
In this case the document contains no pre-defined data of any kind relating to itself. The only data contained within the document relates to other objects and resources outside of document scope.
In order to submit a document with no self description the client roles are as follows:
The server also has various responsibilities to play in order to handle a document containing no self description.
The following represents an example of a document which defines data about a person called Bob.
POST DS-URL HTTP/1.1 Host: example.org Date: Sun, 1 Jan 2012 09:00:00 +0000 Content-Length: xxx Content-Type: application/rdf+xml Authorization: LDS LDSAccessKeyId:Signature <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#"> <contact:Person rdf:about="http://IRI-Prefix/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> </contact:Person> </rdf:RDF>
In order to process this request the server COULD follow the following proceedure:
If successful the servers response COULD look like the following:
201 Created Link: <[Edit-IRI] (e.g. http://IRI-Prefix/doc/4E5E357B-69A3-4C84-BCBA-572693FBCEA3)>; rel="edit-iri"; Content-Location: [Doc-URL/strong>] (e.g. http://IRI-Prefix/doc/4E5E357B-69A3-4C84-BCBA-572693FBCEA3/2011-12-31T23:59:00+00:00) Content-Length: xxx Content-Type: application/rdf+xml= <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="[Doc-URL]"> <dcterms:publisher>Dave Tarrant</dcterms:publisher> <dcterms:dateSubmitted>2011-12-31T23:59:00+00:00</dcterms:dateSubmitted> </rdf:Description> <contact:Person rdf:about="http://IRI-Prefix/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> </contact:Person> </rdf:RDF>
In this example note that:
The publisher could equally refer to a IRI of a person/entity rather than just be a textual name.
A unit test client is available here, this test client will attempt to post the document outlined in this section to a defined server, the DS-URL and the IRI-Prefix can be defined.
Unit Test | /unit_tests/simple_submit |
Result Exemplar | http://exemplar1.lds3.org/doc/65/2B/A97D/F286-45C7-8EE8-B569C2FEC8F2 (RDF) |
In this case the client wishes to pre-define some information about the document which the server MUST maintain when handling this document.
In order to submit a document containing self description the client roles are as follows:
The following represents an example of a document which defines data about a person called Bob.
POST DS-URL?Doc-URI=http://my-namespace.org/doc/this-doc HTTP/1.1 Host: example.org Date: Sun, 1 Jan 2012 09:00:00 +0000 Content-Length: xxx Content-Type: application/rdf+xml Authorization: LDS LDSAccessKeyId:Signature <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="http://my-namespace.org/doc/this-doc"> <dcterms:creator>Richard Philips</dcterms:creator> <dcterms:date>2011-12-26T12:30:14+00:00</dcterms:date> <dcterms:isPartOf rdf:resource="http://id.my-realy-cool-project.org/"/> </rdf:Description> <contact:Person rdf:about="http://IRI-Prefixstrong>/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> </contact:Person> </rdf:RDF>
The server has various key responsibilities:
If successful the server SHOULD return something similar to the following:
201 Created Link: <[Edit-IRI] (e.g. http://IRI-Prefix/doc/4E5E357B-69A3-4C84-BCBA-572693FBCEA4)>; rel="edit-iri"; Content-Location: [Doc-URL] (e.g. http://IRI-Prefix/doc/4E5E357B-69A3-4C84-BCBA-572693FBCEA4/2011-12-31T23:59:00+00:00) Content-Length: xxx Content-Type: application/rdf+xml <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="[Doc-URL]"> <dcterms:creator>Richard Philips</dcterms:creator> <dcterms:date>2011-12-26T12:30:14+00:00</dcterms:date> <dcterms:isPartOf rdf:resource="http://id.my-realy-cool-project.org/"/> <dcterms:publisher>Dave Tarrant</dcterms:publisher> <dcterms:dateSubmitted>2011-12-31T23:59:00+00:00</dcterms:dateSubmitted> </rdf:Description> <contact:Person rdf:about="http://IRI-Prefix/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> </contact:Person> </rdf:RDF>
Note that the document is still automatically annotated with the submission information and this information relates to the document alongside the data which the client submitted.
A unit test client is available here, this test client will attempt to post the document outlined in this section to a defined server, the DS-URL and the IRI-Prefix can be defined.
Unit Test | /unit_tests/custom_doc_submit |
Result Exemplar | http://exemplar1.lds3.org/doc/D2/27/49FD/09CA-4017-AFF9-B0D7B5A972B0 (RDF) |
In order to submit a document to a server, here a client requests an Edit-IRI first and then submits content directly to this IRI. In this case this Edit-IRI can also be used to define document data directly.
In order to obtain an Edit-IRI the client roles are as follows:
A set of similar requirements is placed upon the server:
Example request:
POST DS-URL HTTP/1.1 Host: example.org Date: Sun, 1 Jan 2012 09:00:00 +0000 Content-Length: 0 Authorization: LDS LDSAccessKeyId:Signature
Example Response
202 Accepted Link: <[Edit-IRI] (e.g. http://IRI-Prefix/doc/4E5E357B-69A3-4C84-BCBA-572693FBCEA3)>; rel="edit-iri"; Expires: Sat, 31 Dec 2011 23:59:59 GMT
The client can then use this Edit-IRI in order to construct any document and MAY include pre-defined metadata relating directly to the Document Edit-IRI as follows:
POST Edit-IRI HTTP/1.1 Host: example.org Date: Sun, 1 Jan 2012 09:00:00 +0000 Content-Length: xxx Content-Type: application/rdf+xml Authorization: LDS LDSAccessKeyId:Signature <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="[Edit-IRI]"> <dcterms:creator>Richard Philips</dcterms:creator> <dcterms:date>2011-12-26T12:30:14+00:00</dcterms:date> <dcterms:isPartOf rdf:resource="http://id.my-realy-cool-project.org/"/> </rdf:Description> <contact:Person rdf:about="http://IRI-Prefix/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> </contact:Person> </rdf:RDF>
In order to version the document:
The server response SHOULD look like the following:
201 Created Link: <[Edit-IRI] (e.g. http://IRI-Prefix/doc/4E5E357B-69A3-4C84-BCBA-572693FBCEA5)>; rel="edit-iri"; Content-Location: [Doc-URL] (e.g. http://IRI-Prefix/doc/4E5E357B-69A3-4C84-BCBA-572693FBCEA5/2011-12-31T23:20:00+00:00) Content-Length: xxx Content-Type: application/rdf+xml <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="[Doc-URL]"> <dcterms:creator>Richard Philips</dcterms:creator> <dcterms:date>2011-12-26T12:30:14+00:00</dcterms:date> <dcterms:isPartOf rdf:resource="http://id.my-realy-cool-project.org/"/> <dcterms:publisher>Dave Tarrant</dcterms:publisher> <dcterms:dateSubmitted>2011-12-31T23:20:00+00:00</dcterms:dateSubmitted> </rdf:Description> <contact:Person rdf:about="http://IRI-Prefix/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> </contact:Person> </rdf:RDF>
A unit test client is available here, this test client will attempt to create the Edit-IRI first and then post a document to this location, as per the example above. The DS-URL and the IRI-Prefix can be defined.
Unit Test | /unit_tests/two_part_submit |
Result Exemplar | http://exemplar1.lds3.org/doc/13/9C/86B3/01FF-49F0-86A1-1D38F156ECBC (RDF) |
As with creating a document there are two main techniques to update a document, direct and indirect update. In both cases the client MUST POST the update to the Edit-IRI.
When using direct update the client can either:
In order to update a document, the client roles are as follows:
Example:
POST Edit-IRI HTTP/1.1 Host: example.org Date: Sun, 1 Jan 2012 09:00:00 +0000 Content-Length: xxx Content-Type: application/rdf+xml Authorization: LDS LDSAccessKeyId:Signature <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="[Edit-IRI]"> <dcterms:creator>Richard Philips</dcterms:creator> <dcterms:creator>Brenda Rodgers</dcterms:creator> <dcterms:date>2011-12-26T12:30:14+00:00</dcterms:date> <dcterms:isPartOf rdf:resource="http://id.my-realy-cool-project.org/"/> </rdf:Description> <contact:Person rdf:about="http://IRI-Prefix/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <foaf:name>Bob Smith</foaf:name> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <foaf:mbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> <foaf:title>Dr.</foaf:title> <foaf:knows rdf:resource="http://IRI-Prefix/id/person/SueSmith"/> </contact:Person> <contact:Person rdf:about="http://IRI-Prefix/id/person/SueSmith"> <contact:fullName>Sue Smith</contact:fullName> <foaf:name>Sue Smith</foaf:name> <contact:mailbox rdf:resource="mailto:sue_smith@example.org"/> <foaf:mbox rdf:resource="mailto:sue_smith@example.org"/> <contact:personalTitle>Mrs.</contact:personalTitle> <foaf:title>Mrs.</foaf:title> <foaf:knows rdf:resource="http://IRI-Prefix/id/person/BobSmith"/> </contact:Person> </rdf:RDF>
In this example the client has added both data related to the document and the existing person from before (Bob). A new person (Sue) has also been defined by this same document. It is not recommended that one document be used to define all data!
In order to update the documument the server has many process to perform:
Below is an example response from the server, showing the link between the submitted version and a potential previous version:
200 OK HTTP/1.1 Link: <Edit-IRI>; rel="edit-iri"; Content-Location: [Doc-URL] Content-Length: xxx Content-Type: application/rdf+xml <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="Doc-URL"> <dcterms:creator>Richard Philips</dcterms:creator> <dcterms:creator>Brenda Rodgers</dcterms:creator> <dcterms:date>2012-01-03T14:34:14+00:00</dcterms:date> <dcterms:isPartOf rdf:resource="http://id.my-realy-cool-project.org/"/> <dcterms:publisher>Dave Tarrant</dcterms:publisher> <dcterms:dateSubmitted>2012-01-03T14:45:00+00:00</dcterms:dateSubmitted> <dcterms:replaces rdf:resource="http://IRI-Prefix/doc/4E5E357B-69A3-4C84-BCBA-572693FBCEA5/2011-12-31T23:20:00+00:00"/> </rdf:Description> <contact:Person rdf:about="http://IRI-Prefix/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <foaf:name>Bob Smith</foaf:name> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <foaf:mbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> <foaf:title>Dr.</foaf:title> <foaf:knows rdf:resource="http://IRI-Prefix/id/person/SueSmith"/> </contact:Person> <contact:Person rdf:about="http://IRI-Prefix/id/person/SueSmith"> <contact:fullName>Sue Smith</contact:fullName> <foaf:name>Sue Smith</foaf:name> <contact:mailbox rdf:resource="mailto:sue_smith@example.org"/> <foaf:mbox rdf:resource="mailto:sue_smith@example.org"/> <contact:personalTitle>Mrs.</contact:personalTitle> <foaf:title>Mrs.</foaf:title> <foaf:knows rdf:resource="http://IRI-Prefix/id/person/BobSmith"/> </contact:Person> </rdf:RDF>
A unit test client is available here, this test client will attempt to edit an existing Edit-IRI with the above data. A valid Edit-IRI and IRI-Prefix must be defined.
Unit Test | /unit_tests/direct_update |
Result Exemplar | http://exemplar1.lds3.org/doc/13/9C/86B3/01FF-49F0-86A1-1D38F156ECBC 8.1.1 Original RDF | 8.2.1 Updated RDF |
When using direct update the client can define additional document metadata using its own document URI, which is given to the server as part of the request. Note that the Edit-IRI is still the one needed to post the document too.
In order to update a document, the client roles are as follows:
Example: Same as in 8.2.1 except that the client has defined its own Document URI
POST Edit-IRI?Doc-URI=http://my-namespace.org/doc/this-doc HTTP/1.1 Host: example.org Date: Sun, 1 Jan 2012 09:00:00 +0000 Content-Length: xxx Content-Type: application/rdf+xml Authorization: LDS LDSAccessKeyId:Signature <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="http://my-namespace.org/doc/this-doc"> <dcterms:creator>Richard Philips</dcterms:creator> <dcterms:creator>Brenda Rodgers</dcterms:creator> <dcterms:date>2011-12-26T12:30:14+00:00</dcterms:date> <dcterms:isPartOf rdf:resource="http://id.my-realy-cool-project.org/"/> </rdf:Description> <contact:Person rdf:about="http://IRI-Prefix/id/person/BobSmith"> <contact:fullName>Bob Smith</contact:fullName> <foaf:name>Bob Smith</foaf:name> <contact:mailbox rdf:resource="mailto:bob_smith@example.org"/> <foaf:mbox rdf:resource="mailto:bob_smith@example.org"/> <contact:personalTitle>Dr.</contact:personalTitle> <foaf:title>Dr.</foaf:title> <foaf:knows rdf:resource="http://IRI-Prefix/id/person/SueSmith"/> </contact:Person> <contact:Person rdf:about="http://IRI-Prefix/id/person/SueSmith"> <contact:fullName>Sue Smith</contact:fullName> <foaf:name>Sue Smith</foaf:name> <contact:mailbox rdf:resource="mailto:sue_smith@example.org"/> <foaf:mbox rdf:resource="mailto:sue_smith@example.org"/> <contact:personalTitle>Mrs.</contact:personalTitle> <foaf:title>Mrs.</foaf:title> <foaf:knows rdf:resource="http://strong>IRI-Prefix/id/person/BobSmith"/> </contact:Person> </rdf:RDF>
As in 8.2.1 the client has added both data related to the document and the existing person from before (Bob). A new person (Sue) has also been defined by this same document. It is not recommended that one document be used to define all data!
In order to update the documument the server has many process to perform:
Having done all of this the response from the server should look the same as that in 8.2.1.
A unit test client is available here, this test client will attempt to edit an existing Edit-IRI with the above data. A valid Edit-IRI and IRI-Prefix must be defined.
Unit Test | /unit_tests/indirect_update |
Result Exemplar | http://exemplar1.lds3.org/doc/71/03/B08C/74D7-440A-90F2-109ED9B5AFE9 8.1.2 Original RDF | 8.2.2 Updated RDF |
As Doc-URLs are persistant and contain provenance information they can never be deleted completly. While the same is true of non document IRIs, data relating to these IRIs can be removed, thus emptying the current instance of the IRI. Deleting can either be done using a HTTP DELETE request on the Edit-IRI or by POSTing a blank document to the same IRI, both have the same affect.
Due to the fact that many documents can annotate a single Data-IRI, Data-IRIs MUST NOT directly support delete. This can only be achieved via document updating/deletion as outlined in this section.
Here the clients intention is to DELETE an Edit-IRI (the document container IRI), removing all data related to this document as well as information about the document itself. In order achieve this the client should request that the Edit-IRI be deleted, as follows:
DELETE Edit-IRI HTTP/1.1 Host: example.org Date: Sun, 1 Jan 2012 09:00:00 +0000 Authorization: LDS LDSAccessKeyId:Signature
Due to the requirement to maintain historical information the server MUST handle this request in the same way as a blank post:
While a delete operation is supported, for historical reasons the Edit-IRI should not be deleted completely (neither should any of the Doc-URLs). It is up to the server to decide if it still supports GET requests on the documernt-URI or marks the document as deleted and returns a 410 Gone response.
The server MUST support the re-use of an Edit-IRI, this can either be supported via a PUT or POST request to the Edit-IRI both the client and server have the same responsibilities as outlined in section 8.2.1.
A unit test client is available here, this test client will attempt to delete an existing Edit-IRI with the above data. A valid Edit-IRI must be defined.
Unit Test | /unit_tests/direct_delete |
Result Exemplar | http://exemplar1.lds3.org/doc/66/5D/0DF5/5ED7-4BB3-AF8E-9565B337A711 8.1.1 Original RDF | 8.2.1 Updated RDF | 8.3.1 Remaining RDF after Delete |
Delete via post simply represents an update (as in 8.2) where the document contains empty nodes, for example the client could post the following document:
POST Edit-IRI HTTP/1.1 Host: example.org Date: Sun, 1 Jan 2012 09:00:00 +0000 Content-Length: xxx Content-Type: application/rdf+xml Authorization: LDS LDSAccessKeyId:Signature <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dcterms="http://purl.org/dc/terms/"> </rdf:RDF>
As in 8.2 the client has many options for the update and the requirements on the server and client remain the same.
A unit test client is available here, this test client will attempt to edit an existing Edit-IRI with the above data. A valid Edit-IRI and IRI-Prefix must be defined.
Unit Test | /unit_tests/delete_via_post.php |
Result Exemplar | http://exemplar1.lds3.org/doc/F4/FD/2AA4/0F10-40CB-B1C2-7E9EEC184AB9 8.1.2 Original RDF | 8.2.2 Updated RDF | 8.3.2 Remaining RDF after Delete |
Due to the fact that many documents can annotate a single Data-IRI, Data-IRIs MUST NOT directly support delete. This can only be achieved via document updating/deletion as outlined in this section.
This section does not define any requirements on the server or client, but makes some recomendations on best practice and outlines some of the posibilities of what can be achieved by using this specification.
Generally:
It is advisable that any server implemenation use software such as [Puelia-PHP] which already provides a number of serialisations for data as well as the capability to serve it from a SPARQL server where it may be indexed.
Due to the server storing all historical instances of documents (and thus data) it should be possible for the client to be able retrieve historical data for any IRI (except Doc-URLs which are static already) using the [Memento TimeGate] specification.
The only issue here is that the server may not have historical versions of IRIs indexed, thus in order to acurately serve data from a specific time the server will need to build a tempory index in a sandbox and serve the data from this index. In this way content negotion can still happen against the tempory index instead of a whole new system being required. The server may choose to delay the processing of requests and the client should support the fact it might take some time to complete its request.
More on implementing a TimeGate will follow at the point when a reference implemenation is developed to accompany this specification.
[Amazon Authentication Model] Amazon, "Authenticating Requests Using the REST API", Amazon Web Services Developer API, March 2006, http://docs.amazonwebservices.com/AmazonS3/latest/dev/S3_Authentication2.html)
[iso8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601, 2004, http://www.iso.org/iso/catalogue_detail?csnumber=40874
[Memento TimeGate] VandeSompel et al, "HTTP framework for time-based access to resource states - Memento", Internet Draft, December 2011, http://www.mementoweb.org/guide/rfc/ID/#HTTP_TimeGate
[Puelia-PHP] - http://code.google.com/p/puelia-php/
[RFC2616] Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 http://www.w3.org/Protocols/rfc2616/rfc2616.html