Re: Discovery/Affordances

On 10 Jun 2013, at 17:18, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi, 
> 
> We all agree that somehow a client needs to be able to figure out it is dealing with an LDP server. The argument seems to be about how the client makes that determination. From what I've seen we have two groups of people. 
> 
> One group thinks that RDF provides all the client needs. The RDF typing a la ldp:Container is the indicator. I believe this would mean that an LDPR must also be typed with something LDP specific but I'll leave that out for now. 

That's me

> 
> The other group argues that this is something the client should be able to figure out just from the information contained in the HTTP layer. Using a new mediatype would be one way to do that. It could be a new mediatype entirely or one derived from existing mediatypes using the profile mechanism. 
> 
> I believe both techniques can work but they have different pros and cons.

The second technique contains 2 different proposals, one of which I am for the other against.

I argue strongly against using mediatypes as it is mistaking syntax with semantics. Simply put: the content in bytes sent from the server to the client
is known as a representation of the resource ( it has a syntax defined by its mime type ) One CANNOT apply the method 
GET/POST/DELETE, etc on a representation - a stream of bytes - one can only do that on a resource, which is what the 
URI ( Uniform Resource Identifier ) refers to in  { <> a ldp:Container } 

But I am not against using HTTP headers to express something about the resource that is the container.
As it turns out one can use the Link relation to do that with  ( http://tools.ietf.org/html/rfc5988 ) 

Link: <http://www.w3.org/ns/ldp#Container>; rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"

Perhaps we could do the HTTP/RDF community a favor to register the relation
http://www.w3.org/1999/02/22-rdf-syntax-ns#type to the shorthand "type" so that
the above could become 

Link: <http://www.w3.org/ns/ldp#Container>; rel="type"

> Here is my analysis: 
> 
> Relying on RDF alone has the advantage of not requiring anything new at the HTTP level. On the other hand it requires everything to be typed for LDP specifically and it ties the interaction model to the LDP vocabulary which can be seen as limiting. 

Why would that be limiting? And why should we care if people wrongly see it to be tied to ldp vocabulary?
Other vocabualries can be invented and add more restrictions, that's just the nature of RDF.

> 
> For instance, if I happen to retrieve some LDP content from an LDP server and decide to store it into a vanilla, non-LDP enabled, triple store a client accessing that triple store would be misled to think it is talking to an LDP server when it's not. The counter argument to this is that this is simply something one shouldn't do: one shouldn't serve LDP content from a non-LDP server. 

exactly. That is no different than if an IBM employee mistyped a form on IBMs e-commerce site. We don't try to make
forms meaningless in order to avoid such accidents happening. We rather give forms a meaning in human readable
text surrounding it, and then set up test suites and feedback mechanisms to catch errors.

> 
> Relying on HTTP to provide the indicator that this an LDP server has the advantage of allowing the LDP interaction model to be applied on resources that are not specifically typed for LDP (the spec doesn't currently require typing of LDPRs). It also allows LDP content to be served by non-LDP servers without implying support of the LDP interaction model. 

But then you have just pushed the problem one little step further along, because however you describe your
interaction model, once you allow it to describe something - ie to make some distinction in the world - 
then you inevitably allow the distinction to be made truely or falsely, ie for the description to correspond
to the way the world is or not.  So your distinction will imply support of some interaction model then, and you'll have the
same problem.

> 
> On the other hand this requires defining something beyond the existing RDF mediatypes already in use for non-LDP purposes. Defining a new mediatype entirely or as a profile seems pretty heavy to me. But that's not the only way. Another way to communicate that the server supports the LDP interaction model would be to add an HTTP header. One such possibility would be to have a Link header with a rel=profile and a link to an LDP specific profile a la http://www.w3.org/ns/ldp/profile as the target. 

So as argued above you can use the Link header and also use the ldp:Container there in the same
way as you do with the body. What is the profile adding?  What vocabulary would need to be used to
describe the profile?  Do we need this now or can we add it later?  Unless those questions are answered
this seems like a lot of work to do when we can just use ldp:Container to mean: you can POST to this
container.

> 
> According to Erik while this isn't common (the spec is very recent) it would be reasonable. 
> 
> I think this is the way we should go. If some people want to ignore the Link header they are welcome to do so and it is there for those who care. 
> 
> Comments? 
> 
> Thanks. 
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Social Web Architect
http://bblfish.net/