- From: Alexandre Bertails <bertails@w3.org>
- Date: Mon, 10 Jun 2013 16:45:44 -0400
- To: Arnaud Le Hors <lehors@us.ibm.com>
- CC: public-ldp-wg@w3.org
On 06/10/2013 11:18 AM, Arnaud Le Hors 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. > > 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. I guess it depends on what you mean exactly by LDP content :-) > > 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. Having this extra constraint in the headers would be enough for most of my use-cases, so I would support the approach if it helps moving forward. As you've guessed, we'll need support for both LDPC-s *and* LDPR-s. > 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/profileas the > target. > > According to Erik while this isn't common (the spec is very recent) it > would be reasonable. As far as I'm concerned, this would do most of the job. I think it's clear that we will never agree on any on the "purist" approaches. > > 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 for brevity of the proposal! I agree with "this is the way we should go". Alexandre. > > Thanks. > -- > Arnaud Le Hors - Software Standards Architect - IBM Software Group
Received on Monday, 10 June 2013 20:45:54 UTC