- From: Sandro Hawke <sandro@w3.org>
- Date: Sun, 19 Jan 2014 15:43:53 -0500
- To: Alexandre Bertails <bertails@w3.org>,Henry Story <henry.story@bblfish.net>,Arnaud LeHors <lehors@us.ibm.com>
- CC: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>,Tim Berners-Lee <timbl@w3.org>
Alexandre Bertails <bertails@w3.org> wrote: >I think I can safely say (Henry please confirm :-) that Henry still >wants to communicate the interaction model through the Link header. I >also suspect that Henry knows that rel=type has little to do with >rdf:type because there is no explicit connection made in RFC 6903 [1]. > >That being said, I believe that there is something interesting in what >Henry is trying to say (if I understand correctly): > >* rel=type is about the resource itself, by saying that the [[ context > resource is an instance of the [target] resource ]], while > >* rel=profile is more about the [[ resource representation ]]. > >So it looks like the two Link headers are not _about_ the same >thing. That's a horrifying prospect. Double checking RFC 5988, it seems clear that the link header is always about links (relations) between the resources, so any sense otherwise in the definition of rel=profile and likely a confusion. I also totally understand why one would consider that >communicating the interaction model would fall under the [[ additional >semantics ]] that RFC 6906 talks about, that was my initial >reading. It would also be better if RFC 6906 was specifically >mentioning "extending the interaction model" as a use-case. > >So while ISSUE-92 mentions that [[ there is no mention of interaction >constraints being conveyed [by rel=type] ]], it's also true that >rel=profile seems more focused on the resource representation and is >not explicit about interaction constraints. > >Anyway, I think that Henry brought a reasonable question that was not >answered by the group, it would be good if Erik Wilde could help us >understand how exactly RFC 6903 differs from RFC 6906. Maybe RFC 6906 >could be updated? > >Until then, I would personally not be against keeping rel=type nor >going with rel=profile. > Excellent, then unless else someone comes forward with a formal objection to using link rel=type to signify ldp resource types, we're decided (since Henry was formally objecting on the other side of this issue). - Sandro >Finally, I'd suggest Henry not to make his arguments using RDF if the >reasoning is not about RDF (it was about spec interpretation >here). People missed your point because they thought you were >rejecting the recent accepted proposals, while you said that you're ok >with the status quo. > >Cheers, >Alexandre. > >[1] http://tools.ietf.org/html/rfc6903#section-6 >[2] http://tools.ietf.org/search/rfc6906 > >On 01/18/2014 03:41 AM, Henry Story wrote: >> >> On 18 Jan 2014, at 03:38, Arnaud Le Hors <lehors@us.ibm.com> wrote: >> >>> Just to clarify: The status quo allows one to have on an LDPC either >one of the following two headers: >>> >>> Link: <http://www.w3.org/ns/ldp/Container>; rel="type" >>> Link: <http://www.w3.org/ns/ldp/Resource>; rel="type" >>> >>> Are you saying you're happy with that? >> >> I thought we had agreed that an LDPC had to have the second header. >> And indeed that is confirmed by the comment at the end of >> http://www.w3.org/2012/ldp/track/issues/91 >> >>> I thought you said you would consider it to be a bug if the latter >was found on an LDPC. Yet, considering this a bug would make it >impossible to legitimately address Alexandre's use case: having an LDPC >without it's associated interaction. >> >> There are two ways a triple { <> a ldp:Container } can be found in a >request to a resource: in the body or in the header. >> Let's look at each case: >> >> (a) if it appears in the body: >> + if the resource acts like an LDPC then the statement { <> a >ldp:Container } is true >> + if the resource does not act like an LDPC then the statement { ><> a ldp:Container } is false >> >> (b) if it appears in the header in the form of >> Link: <http://www.w3.org/ns/ldp/Container>; rel="type" >> + if the resource acts like an LDPC then the Link header was >making a true statement >> + if the resource does not act like an LDPC then the Link header >was making a false statement >> >> Notice that there is no difference made semantically between the { <> >a ldp:Container } statement appearing >> in the body or the header. My only distinction is one of attribution: >i.e. In each case I answer differently >> the question: who is the author of the statement? >> >> + The header is the place where the server makes statements >> + The body is a document that can be attributed to any Agent >> >> Since the server is the one that determines how a resource acts, it >is the statements in the header that >> should have priority over the statements in the body for an agent >interpreting a response where the headers >> and the body are inconsistent. >> >> So Alexander's use case is addressed. If someone wishes to publish >a document where the content makes the >> false assertion that { <> a ldp:Container } but the header contains >> Link: <http://www.w3.org/ns/ldp/Container>; rel="type" >> then the client should follow the guidance of the header. >> >> This has a number of other advantages as I pointed out: >> * the server need not try to check the content of an LDPC to work >out how to interact with it. >> In our implementation an LDPC is represented by a directory, so >that the RDF content of the LDPC would not be relevant. >> * the client can know from a HEAD or OPTIONS if a resource is an >LDPC >> >>> >>> I can actually see why you would think it's wrong to have the type >specified at the HTTP level not match the one specified in RDF but this >is what motivated the proposal to change to rel="profile" which you're >opposing. >> >> It is wrong for a document to make a claim that it is an LDPC when it >is not, but the >> web will be full of false claims, and often unintentional false >claims ( such as when a resource >> points to another stating that it is an LDPC when it no longer is ). >> >> The final arbiter is how a resource acts, but a client should go by >what the resource header says >> in final analysis. >> >>> >>> I don't understand whether you actually accept Alexandre's use case >and how you propose to address it. >> >> As it is Alexander's use case is allowed and that is fine. >> >> >>> -- >>> Arnaud Le Hors - Software Standards Architect - IBM Software Group >>> >>> >>> Henry Story <henry.story@bblfish.net> wrote on 01/17/2014 04:29:25 >PM: >>> >>>> From: Henry Story <henry.story@bblfish.net> >>>> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, >>>> Cc: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>, >Tim >>>> Berners-Lee <timbl@w3.org> >>>> Date: 01/17/2014 04:30 PM >>>> Subject: Re: rel=type or rel=profile, issue 92 >>>> >>>> >>>> On 17 Jan 2014, at 23:45, Arnaud Le Hors <lehors@us.ibm.com> wrote: >>>> >>>>> Henry, this is not crazy. This is simply a practical way of making >>>> progress. We have two sets of people reading the text to mean >>>> different things. >>>> >>>> There was no serious reading of the RFC6906 text at any point yet >in >>>> this discussion. >>>> I quoted two extracts of the RFC at length here: >>>> >>>> >http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0060.html >>>> >>>> and could not find anything there that explained how this relation >>>> could in any way solve >>>> the problems put forward here and for which the rel=profile link >was >>>> meant to be an answer. >>>> I have not had anyone contradict my reading yet. >>>> >>>>> Not withstanding the fact that one of these two sets counts >>>> everyone in the WG but you and the other is a singleton called >Henry, >>>> >>>> That was last week when I asked for more time to review the >>>> proposal. Since then I have >>>> looked a lot more carefully at the issues, I have read in detail >the >>>> RFC 6906, and have >>>> discussed with a number of people openly on this list. I think we >>>> have made good progress, >>>> and I don't think that I am alone in my doubts any more. >>>> >>>>> why isn't it reasonable to turn to the author to arbitrate and >>>> tell us whether the proposed use is in the spirit of the spec or >not? >>>> >>>> The author can point to spec text, and explain how he believes this >>>> applies to what >>>> we are doing. But he is not an impartial player in this debate as >he >>>> wrote the text. >>>> >>>> The text of RFC 6906 combined with a description of our alleged >problem has >>>> to be the basis on which we come to a decision on this. >>>> >>>> I don't see furthermore how one can accuse me of holding up a >>>> process, since I am >>>> the one arguing here that the current spec is fine, and am >defending >>>> the status quo. >>>> >>>> Henry >>>> >>>> >>>>> -- >>>>> Arnaud Le Hors - Software Standards Architect - IBM Software >Group >>>>> >>>>> >>>>> >>>>> >>>>> From: Henry Story <henry.story@bblfish.net> >>>>> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, >>>>> Cc: "public-ldp-wg@w3.org Working Group" <public-ldp- >>>> wg@w3.org>, Tim Berners-Lee <timbl@w3.org> >>>>> Date: 01/17/2014 02:18 PM >>>>> Subject: Re: rel=type or rel=profile, issue 92 >>>>> >>>>> >>>>> >>>>> >>>>> On 17 Jan 2014, at 22:44, Arnaud Le Hors <lehors@us.ibm.com> >wrote: >>>>> >>>>>> John already reported that he checked with Erik Wilde on the >>>> proposed use of rel=profile for the purpose at hand and that Erik >>>> said it was fine. Why can't we accept the opinion of the very >author >>>> of the relevant RFC rather than try to second guess what the text >>>> was meant to allow or not? >>>>> >>>>> You're joking right? >>>>> >>>>> The text of an RFC is primary over the opinion of its author. It >>>> is the text that will be >>>>> used and referred to by developers in the future. We are >>>> discussing what type of relation >>>>> we want in the LDP spec, and for this we need to look at the text >>>> published here: >>>>> >>>>> http://tools.ietf.org/search/rfc6906 >>>>> >>>>> If the author could not get his thoughts through in this text, >>>> then there is no second >>>>> guessing. >>>>> >>>>>> Sorry but we just don't have time for this type of debate >>>> anymore. THAT is not constructive. >>>>> >>>>> This is crazy! Allowing this type of reasoning would be to akin to >>>>> writing blank checks in standards body. >>>>> >>>>> Henry >>>>> >>>>> >>>>>> -- >>>>>> Arnaud Le Hors - Software Standards Architect - IBM Software >Group >>>>>> >>>>>> >>>>>> Henry Story <henry.story@bblfish.net> wrote on 01/17/2014 >01:21:00 PM: >>>>>> >>>>>>> From: Henry Story <henry.story@bblfish.net> >>>>>>> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, >>>>>>> Cc: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org> >>>>>>> Date: 01/17/2014 01:21 PM >>>>>>> Subject: Re: rel=type or rel=profile, issue 92 >>>>>>> >>>>>>> >>>>>>> On 17 Jan 2014, at 20:24, Arnaud Le Hors <lehors@us.ibm.com> >wrote: >>>>>>> >>>>>>>> "Eric Prud'hommeaux" <ericw3c@gmail.com> wrote on 01/17/2014 >>>> 10:45:25 AM: >>>>>>>> >>>>>>>>> Apart from how we would best model types vs. interaction >models, we >>>>>>>>> are good netizens who use HTTP headers as the are intended, >and >>>>>>>>> rel=profile is intended to communicate the interaction model. >>>>>>>> >>>>>>>> The fundamental question is (again) whether we agree that the >>>>>>> interaction model isn't tied to the RDF data type and whether >>>>>>> Alexandre's use case - allowing one to have a container that >doesn't >>>>>>> behave like an LDPC but a mere LDPR - is legit and should be >supported. >>>>>>>> >>>>>>>> If we don't agree with that - and Henry apparently doesn't - >>>>>>> discussing how it should be supported is rather moot. >>>>>>>> >>>>>>>> Given the amount of discussion that has already taken place >over >>>>>>> this question - this is just a new occurence, it's not really >>>>>>> different from the discussion around mediatypes we had earlier >on - >>>>>>> I see little hope to get consensus on this unfortunately. It's >like >>>>>>> discussing politics or religion - people don't typically >>>> change their mind. >>>>>>> >>>>>>> Frankly dismissing arguments as religious is not very >constructive. >>>>>>> Precise arguments >>>>>>> were made that are eminently falsifiable. >>>>>>> >>>>>>> I have made a few: >>>>>>> >>>>>>> a) that rel="profile" as specified in rfc6906 makes no >mention of >>>>>>> interaction models. >>>>>>> => This can be falsified by pointing to relevant sections of >the wiki >>>>>>> >>>>>>> b) that the archiving problem could be applied just as well >to any >>>>>>> relation to interaction >>>>>>> models, so that the argument about moving to a relation >won't >>>>>>> solve the problem >>>>>>> => This can be falsified by explaining how this is mistaken >>>>>>> >>>>>>> >>>>>>>> Given how late we are already with regard to our schedule we >can't >>>>>>> afford to spend more airtime discussing this. >>>>>>>> >>>>>>>> This leaves us with two options: 1) give up on supporting >>>>>>> Alexandre's use case, 2) overrule Henry's objection and proceed, >>>>>>> leaving it to him to decide whether he wants to file a formal >>>> objection. >>>>>>>> >>>>>>>> Please, be prepared to vote on those options. >>>>>>>> >>>>>>>> Regards. >>>>>>>> -- >>>>>>>> Arnaud Le Hors - Software Standards Architect - IBM Software >Group >>>>>>>> >>>>>>> >>>>>>> Social Web Architect >>>>>>> http://bblfish.net/ >>>>>>> >>>>> >>>>> Social Web Architect >>>>> http://bblfish.net/ >>>>> >>>>> >>>> >>>> Social Web Architect >>>> http://bblfish.net/ >>>> >> >> Social Web Architect >> http://bblfish.net/ >> >> >>
Received on Sunday, 19 January 2014 20:44:05 UTC