W3C home > Mailing lists > Public > public-ldp-wg@w3.org > June 2013

Re: Discovery/Affordances

From: Alexandre Bertails <bertails@w3.org>
Date: Mon, 10 Jun 2013 16:45:44 -0400
Message-ID: <51B63AF8.3080103@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:51 UTC