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

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

http://www.w3.org/2012/ldp/track/issues/57

Raised by: David Wood
On product: 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).

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.

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.

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.

Related issues include container affordances (ISSUE-21), the LDP-specific PATCH format (ISSUE-17) and discovering LDPR PUT URLs (ISSUE-56).

NB: The answer to ISSUE-32 may or may not provide an answer to this issue as well.  If so, this issue may be closed concurrently.

Received on Friday, 15 March 2013 17:35:58 UTC