Re: ldp-ISSUE-80 (post create media type): How does a client know which POST requests create new resources [Linked Data Platform Spec]

On 6/7/13 6:55 PM, Wilde, Erik wrote:
> hello john.
>
> On 2013-06-07 11:19 , "Linked Data Platform (LDP) Working Group Issue
> Tracker" <sysbot+tracker@w3.org> wrote:
>> ldp-ISSUE-80 (post create media type): How does a client know which POST
>> requests create new resources [Linked Data Platform Spec]
>> HTTP tells a client how to know (after the fact) if it created a resource
>> (201 status code), but not *in advance* how to know if that¹s the
>> semantic it will get should its POST be accepted.
>> Proposal: define a new HTTP header Accept-Post-Create whose value is a
>> media type list to communicate which media types the server accepts when
>> creating resources.
> while it is possible to define and register new HTTP headers, it is not
> the only (and many would argue not the best) way to go. all depends on
> context and preferences, but just to get things going, here are some
> considerations:
>
> - if the accepted media types of POST are fix, this can be defined in the
> media type (or in our case in the vocabulary) and then the rules of
> engagement are well-defined. but i think in this case, they are not fix;
> each LDP server can decide to accept different media types.
>
> - if this is runtime, then one pattern to do this is to do what AtomPub
> did, by including this information as part of the vocabulary:
> http://tools.ietf.org/html/rfc5023#section-8.3.4
>
> - another way to go is to try to make this concept reusable but still
> within the context of vocabularies (i.e., not minting a new header), and
> introduce the concept of "link hints", currently proposed (but not yet
> standardized) here:
> http://tools.ietf.org/html/draft-nottingham-json-home-03#section-4.4
>
> so i would at least not jump to the conclusion that you need such a new
> header field. btw, if you want to go "header field shopping",
> http://www.iana.org/assignments/message-headers/perm-headers.html is a
> good place to see what's already there. i don't think what you're looking
> for is in there, though.
>
> personally, i'd rather handle this in the vocabulary than in a header.
> also, i think it would be great to handle this generically (a la link
> hints) and thus allow other hints to be used as well, without having to
> change the vocabulary. but that may be a bit ambitious at this point in
> time, especially since the link hint registry is not yet existing. so
> pragmatically, i would probably add something along the lines of AtomPub's
> approach, i.e. something in the vocabulary that represents this link hint.
Excerpt from the document you referred to above:

" In contrast, a "follow your nose" API advertises the resources
    available to clients using link relations [RFC5988] and the formats
    they support using internet media types [RFC6838].  A client can then
    decide - at run time - which resources to interact with based upon
    its capabilities (as described by link relations), and the server can
    safely add new resources and formats without disturbing clients that
    are not yet aware of them."

Assuming "vocabulary" implies <http://www.w3.org/ns/ldp#> which is 
described by <http://www.w3.org/ns/ldp.ttl> which is bears content of 
media type <http://www.w3.org/ns/formats/Turtle>, then the statement 
above works, and it isn't ambitious at all. Why? Because its semantics 
are expressible in RDF syntax using a variety of notations. All of this 
can be handled at the HTTP metadata level (via Link: header) and/or in 
the RDF based Linked Data exchanged between client and server.

>
> cheers,
>
> dret.
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen