W3C home > Mailing lists > Public > public-ldp-comments@w3.org > January 2015

Re: Fwd: POSTing RDF to LDPC without null URIs

From: Andrei Sambra <andrei@w3.org>
Date: Wed, 07 Jan 2015 10:40:58 -0500
Message-ID: <54AD538A.6000802@w3.org>
To: public-ldp-comments@w3.org
Hi,

On 1/7/15 8:47 AM, Andreea State wrote:
> Hello,
> 
> Thank you for your answer.
> In your opinion, should the LDP server return a Bad Request response,
> when relative URLs (except '<>') are used? If so, should this be added
> to the specification?

In your case, the server will almost always create a single resource
with a server-made URI -- i.e. http://example.com/123 (unless a Slug
header was sent). The spec does not say that servers need to resolve all
relative URIs and create those resources if they do not exist. The
interaction in your example is limited to the resource in question. Take
a look at the example in the Primer [1].


POST / HTTP/1.1
Host: example.come
Content-Type: text/turtle

@prefix <http://example.com/> .
<dog> a <Animal> .
<cat> a <Animal> .



HTTP/1.1 201 Created
Location: http://example.com/123
Link: <http://www.w3.org/ns/ldp#Resource>; rel='type'
Content-Length: 0


Hope this helps!

-- Andrei

[1]
http://www.w3.org/TR/ldp-primer/#creating-a-rdf-resource-post-an-rdf-resource-to-an-ldp-bc

> 
> Thank you,
> Andreea
> 
> On 7 January 2015 at 11:28, henry.story@bblfish.net
> <mailto:henry.story@bblfish.net> <henry.story@bblfish.net
> <mailto:henry.story@bblfish.net>> wrote:
> 
> 
>>     On 6 Jan 2015, at 16:50, Andreea State <andreea.state@factmint.com
>>     <mailto:andreea.state@factmint.com>> wrote:
>>
>>     Hello,
>>
>>     I have a query regarding LDP behaviour in the case of POSTing
>>     against a container. Let us assume "http://example.com/c1" is a
>>     container, and I POST the following turtle document:
>>
>>     @prefix <http://example.com <http://example.com/>>
>>     <dog> a <Animal> .
>>     <cat> a <Animal> .
> 
>     according to the URI spec if the document creater were
>     <http://example.com/c1/animal>
> 
>     then that would create a document whose content
>     represented as NTriples would be:
> 
>     <http://example.com/c1/dog> a <http://example.com/c1/Animal> .
>     <http://example.com/c1/cat> a <http://example.com/c1/Animal> .
> 
>     But LDP does not restrict the URL of the created document
>     to be of that type. It could also create a URL such as this
> 
>     <http://example.com/animal> in which case the returned graph
>     would be:
> 
>     <http://example.com/dog> a <http://example.com/Animal> .
>     <http://example.com/cat> a <http://example.com/Animal> .
> 
>     This is an indication that a client should not use relative URLS other
>     than <> in POSTing to a LDPC.
> 
>     If you want an LDPC to work for all relative URLs the intuitive way
>     other then
>     you would be in support of the addition of an intuitive container
> 
>     http://www.w3.org/2012/ldp/track/issues/50
> 
>     If so you can express your support for that and the working
>     group can consider it in the next iteration of LDP. 
> 
> 
>>
>>     The specification says that for null relative URIs the server
>>     returns a 'Location' header with a newly created resource. It does
>>     not appear to be obvious what the behaviour should be in the case
>>     of the above example - where there are no null URIs.
>>
>>     From the draft recommendation:
>>
>>     "5.2.3.1 LDP clients should create member resources by submitting
>>     a representation as the entity body of the HTTP POST to a known
>>     LDPC. If the resource was created successfully, LDP servers must
>>     respond with status code 201 (Created) and the Location header set
>>     to the new resource’s URL. Clients shall not expect any
>>     representation in the response entity body on a 201 (Created)
>>     response."
>>
>>     Does that only apply to LDP clients?
>>
>>     Some guidance would be appreciated.
>>
>>     Thank you,
>>     Andreea State
>>
>>
>>
>>
> 
>     Social Web Architect
>     http://bblfish.net/
> 
> 
> 


Received on Wednesday, 7 January 2015 15:40:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:40:58 UTC