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

Re: Fwd: POSTing RDF to LDPC without null URIs

From: Sergio Fernández <sergio.fernandez@salzburgresearch.at>
Date: Fri, 09 Jan 2015 13:16:30 +0100
Message-ID: <54AFC69E.6090301@salzburgresearch.at>
To: Andrei Sambra <andrei@w3.org>, public-ldp-comments@w3.org
Relative URIs would be resolved by the LDP server on parsing time.

Hre you can find another example how that works (using LDPy against 
Apache Marmotta):

sergio@wolfcastle:~$ python
Python 2.7.8 (default, Oct 18 2014, 12:50:18)
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import ldpy
 >>> data = """@prefix : <http://example.com> .
... <dog> a <Animal> .
... <cat> a <Animal> ."""
 >>>
 >>> resource = ldpy.create(payload=data, format="text/turtle")
 >>> print ldpy.read(resource).serialize(format="turtle")
@prefix child: <http://localhost:8080/ldp/e/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix parent: <http://localhost:8080/ldp/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix this: <http://localhost:8080/ldp/e#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

parent:cat a parent:Animal .

parent:dog a parent:Animal .

parent:e a ldp:BasicContainer,
         ldp:Container,
         ldp:RDFSource,
         ldp:Resource ;
     dcterms:created "2015-01-09T13:08:13+01:00"^^xsd:dateTime ;
     dcterms:modified "2015-01-09T13:08:13+01:00"^^xsd:dateTime ;
     ldp:interactionModel ldp:Container .


As Andrei already suggested, take a look to LDP Primer for getting a 
better overview of such things.

Cheers,

On 07/01/15 16:40, Andrei Sambra wrote:
> 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/
>>
>>
>>
>

-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
Received on Friday, 9 January 2015 12:17:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 9 January 2015 12:17:03 UTC