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

Re: Discovery/Affordances

From: Raúl García Castro <rgarcia@fi.upm.es>
Date: Mon, 10 Jun 2013 18:33:12 +0200
Message-ID: <51B5FFC8.2040609@fi.upm.es>
To: Arnaud Le Hors <lehors@us.ibm.com>
CC: public-ldp-wg@w3.org
El 10/06/13 17:18, Arnaud Le Hors escribió:
> 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/profileas 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?

Hi Arnaud,

Does your proposal refer to using only Link header or to using both RDF 
metadata and Link header (this last for those who care)?

Or are you just talking about the Link header case?

Kind regards,

-- 

Dr. Raúl García Castro
http://delicias.dia.fi.upm.es/~rgarcia/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19
Received on Monday, 10 June 2013 16:33:36 UTC

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