RE: Feedback for draft-nottingham-http-link-header-03

I really like the explanation below. It solves my dilemma with having both rel/rev. Hopefully we can incorporate something just like that but either way I don't have an objection to both anymore (not that it was blocking in any way before).



EHL


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wednesday, December 03, 2008 6:57 PM
To: Eran Hammer-Lahav; 'Mark Nottingham'; 'Phil Archer'
Cc: ietf-http-wg@w3.org
Subject: RE: Feedback for draft-nottingham-http-link-header-03

[disclaimer: I'm new to the rel/rev discussion so ignore all this if I'm treading on well-worn territory.]

I agree that if both "rel" and "rev" are included for outbound and inbound links, respectively, their semantics must be uniform for all applications.

I also agree that the semantics of being able to assert both outbound and inbound links are very useful (with my OASIS XDI TC co-chair hat on I'd be shot if I said anything else - XDI RDF lives and breaths by such statements).

But I honestly don't know how useful it is specifically for HTTP Link headers. I don't have enough experience there.

What I can offer is this perspective on the two solutions I see being discussed in the thread below (Solution #1 being to keep both "rel" and "rev" and clearly define the semantics of each to be the directionality of the relation, and Solution #2 being what Eran suggests to keep only "rel" and put the semantics defining directionlity _in the relation URI_.)

Both approaches work, but there's a huge difference in how the semantics are expressed (more on that below). However I don't believe it should have anything to do with authority (the thread quoted below Eran's reply). To illustrate that I'd just put it in terms of a graph model (not necessarily an RDF graph model - I think the following would apply to any directed graph model):

* Any node of the graph with URI X can declare that it has an outgoing arc or an incoming arc, i.e., "I have an outbound arc of relation type Y to the node with URI Z" and "I have an inbound arc of relation type Y from the node with URI Z". The authority for node X _is_ authoritative for both of those statements, and they stand independent of any statement from the authority for node Z.

* That doesn't mean both of those statements are true. The first one - the statement of an outbound link - is a priori true because the node is the source of the link. The second one - the statement of an inbound link - _might_ be true. If you trust statements from the authority for node X, you can stop there. If you don't trust that authority (or you like to trust but verify ;-), you can verify by finding out if the authority for node Z makes the inverse statement, i.e. "I have an outbound arc of relation type Y with the node at URI X." We've been dealing with that kind of trust verification in XRI resolution for a few years now.

So it's valid for any node make statements about both outbound and inbound arcs to that node - and both types are particularly useful from a discovery perspective, and can be verified as necessary by consuming applications. So that would argue in favor of keeping the ability to express both outbound and inbound links in Link headers.

Now about the difference in how it's done.

* Doing it with separate attributes for the relation type URI is clean and doesn't affect the semantics of the relation type URI at all. But it requires both "rel" and "rev".

* Doing it with just "rel" and putting the semantics in the relation type URI is theortically more elegant because then you only need one attribute. However it has two challenges. The first is that URIs don't currently carry such semantics. Eran's suggestion of using rel="rev/next", i.e.:

                Link: <http://example.com/resource/1>; rel="rev/next"
                Where a 'rev/' prefix means the same rel but inbound.

...would imply the semantics that the string "rev/{some-relative-URI}" mean the inverse arc of the relation defined by {some-relative-URI}. That's a cool idea, but it puts semantics into what otherwise are opaque identifiers. (The reason I'm sympathetic to this approach is that this is exactly what XRI syntax was create for - establishing shared semantics for URIs. In fact XDI RDF has even defined an XRI prefix for other XRIs that does exactly what Eran suggests. But XRIs only work when the base URI establishes an XRI context, and I doubt you want to require all link relations to be XRIs ;-)

The second challenge is that it changes the semantics of the "rel" attribute itself in comparison to other specs like HTML that use it. As I understand it, in those specs, "rel" always means "outbound link" and "rev" (when used) means "inbound link".

So in the HTTP/HTML Web world where the vast majority of URIs today are opaque, keeping "rel" and "rev" seems a little cleaner if you want to keep the ability to express both outbound and inbound links.

Hope this helps,

=Drummond

________________________________
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, December 03, 2008 3:34 PM
To: Mark Nottingham; Phil Archer
Cc: ietf-http-wg@w3.org; Drummond Reed
Subject: Re: Feedback for draft-nottingham-http-link-header-03

Either they have a clear meaning or they don't. If the interaction between rel and rev is application specific, what is the value of having rev in the spec? It doesn't help with interop.

For example, if the response to GET /resource/2 is:
Link: <http://example.com/resource/1>; rev="next"

It can either be the *same* as a GET /resource/1 returns:
Link: <http://example.com/resource/2> rel="next"

OR

Can be equally expressed like this (in response to GET /resource/2):
Link: <http://example.com/resource/1>; rel="rev/next"
Where a 'rev/' prefix means the same rel but inbound.

To leave the choice between these interpretations two up to each application seems to void the benefit of having both rel and rev. I think the second interpretation is the right one, which calls for dropping 'rev'.

EHL


On 12/3/08 2:39 AM, "Mark Nottingham" <mnot@mnot.net> wrote:
I think the key is to define the semantics of rel vs. rev well enough
that a relation doesn't necessarily have to say something about them,
but that it still can without conflicting.

Yes, that's a fine line to walk.


On 03/12/2008, at 8:53 PM, Phil Archer wrote:

> I'd just like to jump in on one point:
>
> Eran Hammer-Lahav wrote:
> [..]
>>>>>  Each link-value MUST have at least one "rel" or "rev" parameter
>>>>> whose
>>>>>  value indicates the relation type.  If the "rel" parameter is
>>> used,
>>>>>  it indicates that the link's direction for that relation type is
>>>>>  outbound; if the "rev" parameter is used, the given relation
>>> type's
>>>>>  direction is inbound.
>>>> Is 'rev' considered as authoritative as 'rel' (as in, 'type' is
>>>> non-
>>>> authoritative, just a hint)? Forward looking links using 'rel' are
>>>> clearly authoritative as they indicate the view-point of the
>>>> resource, which has the authority to declare its own perceive links
>>>> to other resources. However, 'rev' can go both ways. It seems to be
>>>> semantically equivalent to an identical 'rel' coming from the
>>>> linked
>>>> resource. For example:
>>>>
>>>> Resource A: Link: <http://example.com/b>; rel="friend"
>>>> Resource B: Link: <http://example.com/a>; rev="friend"
>>>>
>>>> If the two are semantically identical, 'rev' must be non-
>>>> authoritative as it serves as a hint as to what another resource
>>>> view the relationship as: "A declares B to be <<its friend>>, B
>>>> hints that A <<declares B its friend>>". However, if 'rev' is meant
>>>> to be authoritative, the two links above cannot be semantically the
>>>> same, as they read: "A declares B to be <<its friend>>, B declares
>>>> that A <<consider it a friend>>". The question is, is 'rev' simply
>>>> an implied 'rel' from the other direction (and so, non-
>>>> authoritative), or 'rev' is a reverse "opinion" of 'rel' which is
>>>> completely relative to the resource regardless of any actual 'rel'
>>>> from the other direction (and so, authoritative).
>>> This draft isn't attempting to establish a framework for semantics
>>> or
>>> trust, and I'm tempted to take out anything that might imply this...
>> I think at a minimum it needs to clearly define the relationship
>> between 'rel' and 'rev'. This is why I liked it better when 'rev'
>> was dropped. If you only have 'rel', you can express 'rev' with
>> another 'rel' value, and that will solve my issue. If you keep
>> both, I can't see how you can avoid explaining their relationship
>> to one another as listed in the example above.
>
> I just wrote out an argument for why I felt it was important to keep
> rev... and realised that my own arguments convinced me that it
> probably isn't needed for HTTP Link after all. The arguments over
> the relative authority and semantics of rel and rev links is pretty
> compelling.
>
> And yet, and yet... I would still be concerned to see it go because
> it is *really* useful in RDFa. HTML 5 has dropped rev for the link
> element and if the tide is against keeping rev in HTTP Link then the
> impression being given might be that rev is deprecated everywhere.
> Even though that is not what is being said or implied here, it could
> lead to future confusion.
>
> Phil.
>
> --
>
> Phil Archer
> w. http://philarcher.org/


--
Mark Nottingham     http://www.mnot.net/