Re: rel=type or rel=profile, issue 92 - rel=profile definition problem

On 18 Jan 2014, at 20:00, 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.

yes. As I said I am supporting the status quo :-)

> 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 does not follow. It is not because an explicit connection is not
made that the things are different. I'd say one is not far off wrong
in interpretying the link type as rdf:type . 

[[http://tools.ietf.org/html/rfc6903#section-6
   The "type" link relation can be used to indicate that the context
   resource is an instance of the resource identified by the target
   Internationalized Resource Identifier (IRI).
]]

The talk of "instance " of a resource, plus the use of the word type, does
indicate a notion very close to rdf:type at least. If this were to be felt really 
problematic one could use rdf:type directly.

Still this may not be the time to argue this. 

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


Yes, and this is problematic. RFC5988 Web Linking defines a link as follows:

[[ http://tools.ietf.org/search/rfc5988#section-3

   In this specification, a link is a typed connection between two
   resources that are identified by Internationalised Resource
   Identifiers (IRIs) [RFC3987], and is comprised of:

   o  A context IRI,

   o  a link relation type (Section 4),

   o  a target IRI, and

   o  optionally, target attributes.

   A link can be viewed as a statement of the form "{context IRI} has a
   {relation type} resource at {target IRI}, which has {target
   attributes}".
]]

(That text shows how clearly the relations are very close to semantic web relations.)
Furthermore the context IRI is specified to be by default

[[ http://tools.ietf.org/search/rfc5988#section-5.1

   By default, the context of a link conveyed in the Link header field
   is the IRI of the requested resource.
]]

So given that 

  the interpretation of a Link relation is specified in RFC5988 in a precise way,
  that the examples of Link rel=profile and rel=type made them have the same context uri
  that IRIs only refer to one resource

it follows that the subject of the relations rel=type and rel=profile should/MUST 
be the same in both cases. 

It is difficult to square this then with rel=profile's talk of the subject of the
relation being a representation. Eg:

[[
   However, hCard (see
   Section 5.1) is a profile of (X)HTML because it adds processing rules
   that allow a client to extract additional semantics from a
   representation, without changing any of the processing rules and
   semantics of (X)HTML itself. 
]]

This does not have much to do with interaction semantics on the resource, 
( the thing that returns representations), which would be what happens when 
one POSTs, DELETE's etc, various resources.

And in my view if rel=profile is to work at all it should probably not be as part of 
a Link header since the subject of such a relation has to be the resource, whereas
for most uses of rel=profile the subject of the resource must be the body sent in 
the request, and so is closer to a Content-Type, or Content-Length header.

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

If it did it would end up being a pretty big hodge-podge of a relation.

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

We have been allowing rel=type in the header for quite a while now, in some
ways interchangeably with the { <> a ldp:Container } in the body. Working on
the semantics at both levels was aimed to help show the continuity between 
both headers and body.

Anyway, thanks very much for starting this thread to look closer at the
problem of the definitions of rel-profile.

Henry

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

Social Web Architect
http://bblfish.net/

Received on Saturday, 18 January 2014 23:03:42 UTC