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

On 10 Oct 2012, at 18:05, Henry Story wrote:

> 
> On 10 Oct 2012, at 17:03, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
> 
>> 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.
> 
> There are a few answers to that:
> 
> A. you simply don't parse the RDF and just serialise it to disk into 
>  the file name created around 3 in your design. Doing that everything will
>  work just right, because the relative URLs will automatically turn into 
>  the right URLs when fetched in the next round.
>   (I imagine that this is exactly what MUST happen in WebDAV or Atom)

hi Henry, 

I'm not sure about WebDAV, but, with Atom, the POSTed entity is only attribute/value pairs, and the server creates the name for the resource. There isn't any explicit relative addresses in the request, and I've never seen references to 'self' in the request ... (??)

Related: with Atom, how does a server describe to a client what makes sense inside the POSTed <entry> element ? and more importantly what will the equivalent mechanism be for LDP ? Is it specified ? 

regards, 
Roger

> 
> B. You parse the incoming stream into a graph that accepts relative URLs, 
>   and then in 3/ either
>     a- place it into a store that accepts relative URLs
>     b- resolve the URLs against the full store url
> 
>  C. You delay the parsing until around 3 or 4 when you know the full
>   URL.
> 
> The fact that A works, is very good reason to believe that my proposal -
> which Steve Battle named A) is the correct design. 
> 
> B seems to make a good case for having at least parsers that can parse
> documents with relative URLs without needing to resolve them.
> 
> C. Should be quite possible to do, since downloading documents should
> be done asynchronously, and takes time, whereas finding out from the 
> path that a resource needs to be created can be done extremely quickly.
> 
> 
> 
> 
> 
>> 
>> 	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
>> 
> 
> Social Web Architect
> http://bblfish.net/
>