Discovery/Affordances

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.

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

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.

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.

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.

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