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]

On 15 Mar 2013, at 18: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]
> 
> 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).

(aside: Talk of LDP service seems misleading to me. It brings up the idea that there is some controller of a set of resources at a domain name, that the web has a point at which one accesses a service. But the Web is a web of hypelinked resources, and the whole point of it is that there is architecturally no single entry point. One should be able to get to any resource to any other by following hyperlinks. All that a client ever interacts with are individual resources. A domain could have only one LDPC or be entirely composed of LDPCs. It should not matter.)

So currently if you do a GET on a LDPC it will advertise that it is an LDPC with the triple

  <> a ldp:Container .

An LDPR could do the same with 

  <> a ldp:Resource .

Section 4.6 points out that a HEAD on a resource can return the Allow header 
   http://www.w3.org/TR/ldp/#http-head
which can tell you what methods you are allowed to use. This could be added to section 4.2
so that a GET also gives you the allowed methods.

> A client will need to discover (either via a discovery mechanism or a priori) a URL to POST, PUT or PATCH an LDPR.  

What is the problem here with using linked data and the ontology we allready have. Any resource on the internet can advertise another one as being an ldp:Container by just writing:

     <http://some.server.com/2013/04/01/> a ldp:Container . 

If you do an HTTP GET on <http://some.server.com/2013/04/01/> you should check
for confirmation that it is an ldpc, since resources themselves are always the
final arbitrator of their capabilities. So you would check that it contains

  <> a ldp:Container .

The URL you POST, PUT, or PATCH to should be the URL that you want to change. 


> 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.

for POST if something advertises itself as an LDPC then Turtle can be assumed as the default.
Additional supported formats could be added by something like

   <> acceptedFormats "*/*" . 

Perhaps this can be generalised a bit:

   <> interaction [ rdfs:subClassOf POST;
                    accept "*/*"; ],
                  [ rdfs:subClassOf PATCH;
                    accept "text/sparql", "text/trig" ],
                    ...

> 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.

For binary objects the binary clearly cannot describe this information. This may be just the 
place where the Link: <;m>; rel=meta header is useful. 

> 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.

I don't think that would be flexible enough, since every resource can allow different interactions patterns on it. 

Once the above ontology is specified one could then make things more efficient by using POWDER to describe the capabilities of a set of resources and then have each resource link to that POWDER document. ( This may be close to what some people describe as the service document, but from this position we start with individual resources to go to service documents, rather than thinking there could be a service document that had a well known location from which we would have to start ).


> 
> 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.
> 
> 
> 

Social Web Architect
http://bblfish.net/