Re: Input on request for link relation

On Thu, Sep 17, 2009 at 4:02 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote:

>
> I also want to point out that we really need to work on our messaging and
> perception that URI extension relation type are in any way inferior or "less
> cool" than the short registered ones. The sooner protocol authors accept
> this as a perfectly valid choice for their protocol needs, the better the
> link framework will be.


I couldn't have said it better myself. Basically what you are saying by
requesting a short relation is that you actively intend to share the
relation with others with a view to improving interoperability. By using a
URI you control you're saying you want it to have a specific, concrete
meaning (while retaining the option of sharing). The more I hear the more it
sounds like PubSubHubbub wants the latter and with that in mind I would
suggest that http://pubsubhubbub.org/ is as good an identifier as any.

Imagine a feed advertising both rssCloud and PuSH - without clarification of
the "hub" relation (for example by way of dedicated content types) clients
will have to use protocol discovery or trial and error to work out what to
use. It doesn't help that it's not so much a content type we're talking
about but a protocol, in which case a [registered] service name would be a
better fit (and even then registered service names are generally used in
conjunction with well-known port assignments rather than "everything over
HTTP").

I have a similar problem with OCCI <http://www.occi-wg.org/> whereby I want
to advertise console access to virtual machines via ssh, vnc-server
or ms-wbt-server - I guess we'll have to assign a separate link relation
(like  http://purl.org/occi/console#ssh) for each protocol, which is a bit
of a hack when e.g. a "service=ssh" attribute would accomplish the same.
Conversely content types work fine for advertising console screenshots in
e.g. PNG or JPEG.

Mark: perhaps you could consider including some wording like Eran's and/or
mine above into the Web Linking draft so we can point at it later? I would
also suggest that the "broadly useful" test needs some refinement - the
implication in rejecting applications is that the applicant's work is not
"broadly useful" while what we mean by this is that it is useful for
multiple/many standards.

Sam