You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by Reto Bachmann-Gmür <re...@apache.org> on 2012/11/22 12:31:44 UTC

Linked Data Platform Comformance

I've created http://wiki.apache.org/clerezza/LinkedDataPlatform to describe
in how far Clerezza is compliant with the linked data platform
recommendations[1]. I think the main incompatibility lies in the fact that
an HTTP PUT will cause the uploaded entity to be returned on subsequent
GETs and the message body is treated as a literal while the recommendations
seem to expect a PUT to behave like what is an MPUT in URIQA[2]

Reto

1. http://www.w3.org/TR/ldp/
2. http://sw.nokia.com/uriqa/URIQA.html

Re: Linked Data Platform Comformance

Posted by Andy Seaborne <an...@apache.org>.
On 22/11/12 13:57, Reto Bachmann-Gmür wrote:
> On Thu, Nov 22, 2012 at 2:24 PM, Andy Seaborne <an...@apache.org> wrote:
>
>> On 22/11/12 11:31, Reto Bachmann-Gmür wrote:
>>
>>> I've created http://wiki.apache.org/**clerezza/LinkedDataPlatform<http://wiki.apache.org/clerezza/LinkedDataPlatform>to describe
>>> in how far Clerezza is compliant with the linked data platform
>>> recommendations[1]. I think the main incompatibility lies in the fact that
>>> an HTTP PUT will cause the uploaded entity to be returned on subsequent
>>> GETs and the message body is treated as a literal while the
>>> recommendations
>>> seem to expect a PUT to behave like what is an MPUT in URIQA[2]
>>>
>>> Reto
>>>
>>> 1. http://www.w3.org/TR/ldp/
>>> 2. http://sw.nokia.com/uriqa/**URIQA.html<http://sw.nokia.com/uriqa/URIQA.html>
>>>
>>>
>> Does Clerezza process the vocabulary for LDPR's dcterms:modified etc?
>>
>> No. As soon as you do a PUT  the resource is treated as non-LDPR and it
> description is available at {resource-uri}-description (where it has
> dctermas-properties). These is so that clerezza behaves consistently for
> all put request and could also be used for WebDAV (which is not currently
> implemented but wouldn't be icmpatible with the design). It seems that
> these are the issues Patrick Stickler addresses with the proposed new HTTP
> methods.
>
>
>
>> (looking in the RDF exchanged is hard part of LDPRs otherwise the
>> requirements are little more than basic HTTP operations)
>>
>> The large part of the spec though is containers (LDPC). Sections 5.3-5.9
>> (only 5.1 and 5.2 are non-normative). e.g. paging, accessing non-container
>> properites, sub-resource creation.
>>
>
> Ah, ok, Thanks. Many things here have to still be implemented but I see no
> similar architectural conflict as with PUT.

Nor do I.

The vocabulary processing and the containers do change LDP from a "best 
practices for using HTTP and RDF" into a non-trivial platform.

And there will be major decisions outside the LDP spec - how containers 
are configured for example.

	Andy

>
> Reto
>
>>
>> And expect significant changes.  It's only a first published working draft
>> and the use case and requirements isn't finished yet.
>>
>>
>


Re: Linked Data Platform Comformance

Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
On Thu, Nov 22, 2012 at 2:24 PM, Andy Seaborne <an...@apache.org> wrote:

> On 22/11/12 11:31, Reto Bachmann-Gmür wrote:
>
>> I've created http://wiki.apache.org/**clerezza/LinkedDataPlatform<http://wiki.apache.org/clerezza/LinkedDataPlatform>to describe
>> in how far Clerezza is compliant with the linked data platform
>> recommendations[1]. I think the main incompatibility lies in the fact that
>> an HTTP PUT will cause the uploaded entity to be returned on subsequent
>> GETs and the message body is treated as a literal while the
>> recommendations
>> seem to expect a PUT to behave like what is an MPUT in URIQA[2]
>>
>> Reto
>>
>> 1. http://www.w3.org/TR/ldp/
>> 2. http://sw.nokia.com/uriqa/**URIQA.html<http://sw.nokia.com/uriqa/URIQA.html>
>>
>>
> Does Clerezza process the vocabulary for LDPR's dcterms:modified etc?
>
> No. As soon as you do a PUT  the resource is treated as non-LDPR and it
description is available at {resource-uri}-description (where it has
dctermas-properties). These is so that clerezza behaves consistently for
all put request and could also be used for WebDAV (which is not currently
implemented but wouldn't be icmpatible with the design). It seems that
these are the issues Patrick Stickler addresses with the proposed new HTTP
methods.



> (looking in the RDF exchanged is hard part of LDPRs otherwise the
> requirements are little more than basic HTTP operations)
>
> The large part of the spec though is containers (LDPC). Sections 5.3-5.9
> (only 5.1 and 5.2 are non-normative). e.g. paging, accessing non-container
> properites, sub-resource creation.
>

Ah, ok, Thanks. Many things here have to still be implemented but I see no
similar architectural conflict as with PUT.

Reto

>
> And expect significant changes.  It's only a first published working draft
> and the use case and requirements isn't finished yet.
>
>

Re: Linked Data Platform Comformance

Posted by Andy Seaborne <an...@apache.org>.
On 22/11/12 11:31, Reto Bachmann-Gmür wrote:
> I've created http://wiki.apache.org/clerezza/LinkedDataPlatform to describe
> in how far Clerezza is compliant with the linked data platform
> recommendations[1]. I think the main incompatibility lies in the fact that
> an HTTP PUT will cause the uploaded entity to be returned on subsequent
> GETs and the message body is treated as a literal while the recommendations
> seem to expect a PUT to behave like what is an MPUT in URIQA[2]
>
> Reto
>
> 1. http://www.w3.org/TR/ldp/
> 2. http://sw.nokia.com/uriqa/URIQA.html
>

Does Clerezza process the vocabulary for LDPR's dcterms:modified etc?

(looking in the RDF exchanged is hard part of LDPRs otherwise the 
requirements are little more than basic HTTP operations)

The large part of the spec though is containers (LDPC). Sections 5.3-5.9 
(only 5.1 and 5.2 are non-normative). e.g. paging, accessing 
non-container properites, sub-resource creation.

And expect significant changes.  It's only a first published working 
draft and the use case and requirements isn't finished yet.

	Andy