Subject: What is the document base URI of a POSTed document?

From: "Steve Battle" <[email-masked]>
Date: Wed, 17 Oct 2012 16:11:27 +0100

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:[email-masked]> [email-masked]
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.

---

From: James M Snell <[email-masked]>
Date: Wed, 17 Oct 2012 08:18:40 -0700

On Wed, Oct 17, 2012 at 8:11 AM, Steve Battle <[email-masked]>wrote:

> [snip]
>
> ** **
>
> RFC 3986 is written more from the perspective of HTTP GET, so for HTTP
> POST we have to read between the lines.****
>
> 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..****
>
> created resource.****
> **

I would say this is certainly a reasonable and logical assumption. Note,
however, that you need to account for the possible presence of the
Content-Location header within the POST request. If the POST includes a
Content-Location, it's value effectively establishes the base URI.

- James

> **
> issues.****
> ** **
> Thanks for your considered opinions,****
>
> Steve.****
>
> ** **
>
> --****
>
> Steve Battle
> Semantic Engineer
>
> Mobile: +44 (0)7503 624 613****
>
> E-mail: [email-masked]
> Web: www.sysemia.com****
>
> ** **
>
> Sysemia Limited
> DISCLAIMER****
> are virus checked before they are opened.****
>
> ** **
>

---

From: Mark Baker <[email-masked]>
Date: Sat, 20 Oct 2012 21:57:59 -0400

> Content-Location, it's value effectively establishes the base URI.

I wish :) See the discussion associated with this issue;

http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i80

Mark.

---

From: James M Snell <[email-masked]>
Date: Sat, 20 Oct 2012 19:05:25 -0700

Granted, there may be implementations that have issues with it.. I'm basing
this off the language in the latest httpbis draft (
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics)...

Specifically...

<snip>
If the request has a Content-Location header field, then the
sender asserts that the payload is a representation of the
resource identified by the Content-Location field-value.  However,
such an assertion cannot be trusted unless it can be verified by
other means (not defined by HTTP).  The information might still be
useful for revision history links.
...
If Content-Location is included in a request message, then it MAY be
interpreted by the origin server as an indication of where the user
agent originall  y obtained the content of the enclosed representation
(prior to any subsequent modification of the content by that user
agent).  In other words, the user agent is providing the same
representation metadata that it received with the original
representation.
...
A Content-Location field received in a request message is transitory
information that SHOULD NOT be saved with other representation
metadata for use in later responses.  The Content-Location's value
might be saved for use in other contexts, such as within source links
or other metadata.
</snip>

As with everything tho, YMMV...

- James