What is the document base URI of a POSTed document?

Apologies up front for cross-posting, but I'm seeking clarification on the
issue of 

'What is the document base URI of a POSTed document?'

 

The Linked Data Platform http://www.w3.org/2012/ldp working group has a use

case to be able to create an resource within a container, whereboth the
container and subordinate resource can be described by RDF.

<http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements#UC-BPC2:_Create_
resource_within_a_container>. 

The intention is to be able to HTTP POST an RDF representation to a
container URI.

 

The working scenario is very similar to the use of POST as defined in 'The
Atom Publishing Protocol' (RFC 5023).

The use-case is to create a new subordinate resource within a container
resource identified by the Request-URI (consistent with RFC 2616).

 

POST http://example.com/contacts/ HTTP/1.1

Host: example.com

Content-Type: text/turtle

Slug: my contact

 

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

 

<> a foaf:PersonalProfileDocument ;

foaf:primaryTopic <#me> .

<#me> a foaf:Person ;

foaf:name "Henry" .

 

The server answers with:

 

HTTP/1.1 201 Created

Location: http://example.com/contacts/my-contact

ETag: W/"1234567890"

                   

In Turtle URIs in angle brackets may be relative URIs (relative to the
base), so '<>' is the base URI of the document.

This allows the RDF to be 'self-describing', allowing us to state that this
document is a foaf:PersonalProfileDocument.

 

In order to correctly parse and interpret this document we assume that the
document base is the URI of the resource created by the POST,

i.e. the URI returned in the 'Location' header.

 

A subsequent HTTP GET on this location returns a description of the created
resource. The example illustrates that this is not necessarily syntactically
equivalent to the original POSTed document; it includes additional
relationships that link it to the container it was added to.

 

GET http://example.com/contacts/my-contact HTTP/1.1

Host: example.com

Accept: text/turtle

 

HTTP/1.1 200 OK 

Content-Type: text/turtle

ETag: W/"123456789"

 

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix : <http://example.com/contacts/> .

 

<> a foaf:PersonalProfileDocument ;

foaf:primaryTopic <#me> .

<#me> a foaf:Person ;

foaf:name "Henry" .

: rdfs:member :my-contact .

 

RFC 3986: 'Uniform Resource Identifier (URI)' section 5.1 defines how the
current (in-scope) base URI is established.

 

1. Base URI Embedded in Content (e.g. in Turtle, the in-scope base URI may
be set with the @base directive).

2. Base URI of the encapsulating entity "the base URI is defined by the
representation's retrieval context"

3. URI used to retrieve the entity "if a URI was used to retrieve the
representation, that URI shall be considered the base URI"

4. Default Base URI

 

RFC 3986 is written more from the perspective of HTTP GET, so for HTTP POST
we have to read between the lines.

Returning to the issue, we would like to know if it is OK to assume in the
context of an HTTP POST and the above scenario that:

 

1. If there is no embedded @base and..

2. there is no retrieval context for POST and..

3. no URI was used to retrieve the representation, then..

4. the default base URI can be set by the application to be the URI of the
created resource.

 

It might also be helpful if 2616 could provide clarification on these
issues.

 

Thanks for your considered opinions,

Steve.

 

--

Steve Battle
Semantic Engineer

Mobile: +44 (0)7503 624 613

E-mail:  <mailto:steve.battle@sysemia.co.uk> steve.battle@sysemia.co.uk
Web:  <http://www.sysemia.com/> www.sysemia.com

 

Sysemia Limited
The Innovation Centre, Bristol &  Bath Science Park, Dirac Crescent,
Emerson's Green, Bristol BS16 7FR
Registered in England and Wales. Company Number: 7555456

DISCLAIMER

Information contained in this e-mail is intended for the use of the
addressee only, and is confidential and may also be privileged. If you
receive this message in error, please advise us immediately. If you are not
the intended recipient(s), please note that any form of distribution,
copying or use of this communication or the information in it is strictly
prohibited and may be unlawful. Attachments to this e-mail may contain
software viruses which may damage your systems. Sysemia Ltd have taken
reasonable steps to minimise this risk, but we advise that any attachments
are virus checked before they are opened.