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/