Re: Linked Data Platform ISSUE-20: What is the base URI of a POSTed document?

This does have a real consequence to implementation:

A design that

1/ receive POST -- some general receipt handling
2/ content-type: parse body as RDF
3/ Decide it's a container
4/ dispatch request to container
5/ Create new BPR

trying to create an abstraction of "incoming RDF", does not work because 
the parsing happens before the operation is known to be a container with 
specific action of creating the new BPR.

	Andy

On 10/10/12 15:47, Andy Seaborne wrote:
>
>
> On 10/10/12 15:10, Steve Battle wrote:
>> The Relevant Standard:
>>
>> RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
>>
>> 5.1.  Establishing a Base URI: The base URI of a reference can be
>> established in one of four ways:
>>
>> 1. Base URI embedded in Content.
>>
>> 2. Base URI of the encapsulating entity. “If no base URI is embedded,
>> the base URI of a document is defined by the document's retrieval
>> context.”
>>
>> 3. URI used to retrieve the entity. “if a URI was used to retrieve the
>> base document, that URI shall be considered the base URI.”
>>
>> 4. Default Base URI (application-dependent)
>>
>> However, as a POSTed resource has no real retrieval context it appears
>> to drop right through levels 2 and 3, leaving us with an application
>> dependent choice.
>>
>> In a linked data context one might then ask , “if a URI _were­_ used to
>> retrieve the base document, that URI shall be considered the base URI.”
>> In that case (A) is the most natural solution.
>>
>
> The text is more about client-side determination of base URI but if (and
> it's arguable) we take the request and response to have the same
> determination of base URI, then 5.1.3 applies. "retrieval" is very much
> response language but "request URI" is a common concept (with
> redirections applied).
>
> If some POST operation causes "<>" to be in the body of the response,
> it's the container URI.  It might be seen as odd if the request and
> response have different meaning of "<>".
>
>      Andy

Received on Wednesday, 10 October 2012 15:03:51 UTC