Re: ldp-ISSUE-57 (LDP Service ID): How can a client determine that it is in communication with an LDP service? [Linked Data Platform core]

hello david.

On 2013-03-15 10:35 , "Linked Data Platform (LDP) Working Group Issue
Tracker" <sysbot+tracker@w3.org> wrote:
>ldp-ISSUE-57 (LDP Service ID): How can a client determine that it is in
>communication with an LDP service? [Linked Data Platform core]
>
>I contend that several possible communications between client and LDP
>server would benefit from a client knowing that it is speaking with an
>LDP service.  If that statement turns out to be true, LDP servers may
>wish to advertise their LDP compliance (e.g. via an HTTP header).

absolutely agreed, and i hate to sound like a broken record again, but
that header would be the Content-Type header. speaking LDP should be
exposed at that level (so that any HTTP client can find out). it seems
that the group majority dislikes the idea of a media type, but there's
still the possibility to use a profile (if RDF media types were updated to
support a profile media type parameter).

>A client will need to discover (either via a discovery mechanism or a
>priori) a URL to POST, PUT or PATCH an LDPR.  It will also need to know
>the formats it can POST, PUT or PATCH and any server version restrictions
>(e.g. whether a particular server supports modifications to the PATCH
>format).  Those particular concerns may be addressed by the answers to
>ISSUE-17 and ISSUE-56.

one thing is exposing LDP as a service on the web level (Content-Type).
the next one would be to expose a home resource providing those
affordances that you are mentioning. this is a very common pattern for any
web service, and thus
http://tools.ietf.org/html/draft-nottingham-json-home is trying to come up
with a way how to expose this home resource. the current representations
of this model are JSON and XML, but deriving RDF from it would be a simple
mapping exercise.

in case somebody wan to see the draft's JSON example in XML, here it is:
https://github.com/dret/I-D-1/blob/dret/home-schema2/json-home/home-documen
ts-03.xml

>However, a client may POST, PUT or PATCH a binary object to an LDPC and
>MAY (in accordance with ISSUE-15) get back both Location: and Link:
>headers in a 201 Created response.  The client will not know how to deal
>with the possible Link: header, nor its relationship to the binary
>object's URI, unless it knows that the server is an LDP server.

but that's fine as long as the context of where the client found the link
clearly indicates that the client is about to engage in a LDP interaction.
and it absolutely should be doing this by providing a typed link that
identified the LDP interaction semantics.

>It seems to me that these concerns would be best addressed by the server
>advertising via an HTTP header that it supports a particular version of
>the LDP spec.

mostly, people in REST try to steer clear of putting versioning into
headers (i.e., media types) and instead try to version the vocabulary.
that is unless you introduce breaking changes, at which point you're
essentially creating a new media type.
http://www.mnot.net/blog/2012/12/04/api-evolution describes this nicely.

cheers,

dret.

Received on Friday, 15 March 2013 18:36:09 UTC