rel-values

 rel values  are values used in the HTML  attribute; several of which are used (sometimes optionally) in IndieWeb building blocks, yet no more are being proposed.

IndieWeb rel values
Rel values actively used in IndieWeb implementations and for what building blocks:

In use
These rel-values are actively in use as part of their indieweb building blocks:
 * feed
 * used on a home page
 * used by readers to discover additional h-feed(s)
 * used by Bridgy to do extended original post discovery


 * me
 * used by web-sign-in-protocol
 * used by IndieAuth


 * micropub
 * used by Micropub


 * authorization_endpoint, token_endpoint
 * used by IndieAuth when authorizing a Micropub endpoint


 * shortlink
 * used on posts
 * used by Bridgy Publish on POSSE copies to link back to the original


 * webmention
 * used by Webmention

Optional legacy
These rel-values are both optional, sometimes legacy to support existing content, and superseded by more robust approaches, usually a property scoped to a microformat it applies to:
 * author
 * superseded by  inside h-entry, optionally with an embedded h-card
 * used by authorship


 * in-reply-to
 * superseded by  inside h-entry
 * used in reply posts
 * used by Salmention
 * used by Webmention receivers (e.g. for comments-presentation)


 * syndication
 * superseded by  inside h-entry
 * used on links to POSSE copies
 * used in original post discovery

External dependency
Some rel values are not used by IndieWeb building blocks per se, but rather by external services or applications, sufficiently to justify using them.


 * icon, shortcut, apple-touch-icon
 * used on a home page
 * used for icon support by web browsers, especially mobile browsers

History
Some historical aspects of rel values, especially legacy ones, and how they originated.

Any rel values discussed below should be considered abandoned unless noted above or in a specific current building block page.

Brainstorming rel vs class

 * As per feedback by User:Tantek.com, we should use rels in addition to u-like, etc. (used in RSSB) for responses.
 * Based on the discussion/brainstorming below, and the apparent difficulty it poses, I'm no longer convinced that it's worth it to have rels in addition to u-like-of etc. Tantek 17:10, 9 August 2013 (PDT)
 * In particular, in any instance where we have a replacement  class name, use that instead of the rel value. See Optional legacy above for such rel-values and the u-* class names that supersede them. Tantek 18:18, 4 April 2016 (PDT)

naming rel values

 * See http://microformats.org/wiki/rel-faq#What_does_a_rel_value_really_mean.3F and http://microformats.org/wiki/existing-rel-values for better understanding rels
 * Suggestions by User:Waterpigs.co.uk for coming up with rel values
 * "destination is a rel-name of source”
 * "destination is source’s rel-name"

object of action
Using likes as the example for specific brainstorming:
 * rel="like-of"
 * rel="object-of-like"
 * Coming up with a good name for the "object of a like" is actually a problem of coming up with a name for objects of monotransitive verbs (which is what almost all responses are). The object-of-verb seems to be a good template for naming these objects. &mdash;User:Sandeep.io
 * rel="liked-thing" can be used to label the thing that was liked. It's simpler, reads better and is in common usage &mdash; Www.sandeep.io 16:33, 26 June 2013 (PDT)
 * The "common usage" is a misconception. The search only shows use as a label, not as a relation, which is a key aspect of rel values. Despite that "evidence" being inapplicable, as a brainstorm suggestion we should still consider rel="liked-thing" relative to the others. "Thing" has a bad history in semantic labeling - usually a sign of a very bad ontology/taxonomy. However we should consider other "liked-*" possibilities Tantek 17:23, 26 June 2013 (PDT)
 * My bad. By common usage I meant everyday usage by regular people (without a semantic bent) to refer to the thing we are trying so hard to find a name for. -Www.sandeep.io 17:07, 27 June 2013 (PDT)
 * I specifically chose thing (over object, post, etc.), to allow for "liking" anything (e.g., app website, tool website, company website, profile page, etc.). -Www.sandeep.io 17:07, 27 June 2013 (PDT)
 * Use of thing by other: http://schema.org/Thing -Www.sandeep.io 12:01, 30 June 2013 (PDT)
 * Schema is a good example of a VERY BAD object hieararchy (part of that bad history I mentioned). So much extra overdesigned and miscategorized crap in the 150+ objects in schema.org (e.g. different types of businesses that should just all be tags on a simple organization object like hCard). Schema is like a brainfart from a bad 1990s summer intern project. There's no evidence that Google even does anything with their Thing. - Tantek 18:32, 30 June 2013 (PDT)
 * I would be tempted to use rel="liked" on its own - after all, we're parsing the linked-to page for microformats, so should be aware of what kind of object it is in its own right. This also gives us the benefit of being able to "like" anything with a URI. (Although I'm certain I'm missing an important use case here.) Ben 17:30, 26 June 2013 (PD)
 * Ben, I had suggested this but it implies past tense --Www.sandeep.io 17:07, 27 June 2013 (PDT)
 * rel="liked-object" - similar, but what makes the destination an object?
 * rel="liked-post" - this seems to have the advantages of "liked-thing" but without the disadvantages, and is more specific - the thing you're linking to *is* a post. Or are there non-post examples? (none so far).
 * rel="liked-item" - We could also consider "liked-item" - inspired by h-item -Www.sandeep.io 12:01, 30 June 2013 (PDT)
 * "liked-item" sounds a bit better than "liked-thing" or "liked-object". It's shorter too. - Tantek 18:32, 30 June 2013 (PDT)
 * rel="like-target" - inspired by the terms "link target address" or "target of the hyperlink" and an attempt at a rel name that avoids the past tense of the verb. -Www.sandeep.io 17:09, 4 July 2013 (PDT)
 * this also gives us the symmetrical rel="like-source" for the opposite direction. -Www.sandeep.io 09:15, 24 July 2013 (PDT)

Others:
 * rel="object-of-reply" (as an alternative / replacement for rel-in-reply-to which we can still support consuming for backward compat, since that rel value came from Atom originally - I think? citation needed. Tantek 07:49, 25 June 2013 (PDT)).
 * This is also good enough for special replies like RSVPs (so no rel="object-of-rsvp").
 * If an action is a special kind of "reply" we don't need a new rel value for it. Tantek 08:04, 25 June 2013 (PDT)
 * rel="object-of-favorite" - how or is this any different from "like"? Fhere's some anecdotal evidence that users consider "likes" (as props/compliments) different from "favorites" (special, collecting, curating). Though I don't know of any systems that have both. - Tantek 08:31, 25 June 2013 (PDT)
 * rel="object-of-repost"

Unnecessary:
 * rel="object-of-mention" - all links are implicit mentions, so there's no need / use-case for marking them explicitly as such. Tantek 08:04, 25 June 2013 (PDT)
 * This was specified in RSSB as well. One problem that I had while implementing RSSB was that I was calling this type of response a "mention" (in code and database) which sounds weird as a type of mention. I might be renaming this type of mention to "link" in Converspace. Based on this maybe rename that and say rel="object-of-link" is unnecessary as it makes is really obvious. -Www.sandeep.io 17:07, 27 June 2013 (PDT)

past examples
For an example of different responses in action with previous class names, see http://www.sandeep.io/39

response collections
Original posts may have a section (e.g. in the footer) that displays an aggregation or list of responses, and then link back to each response. These links could have rel values themselves (not sure why - need a use-case for this) as inverses of the "object-of-*" values above. Ironically, these are easier, typically working as specific past present conjugation of the "*" term in the first place. E.g.

Likes:
 * rel="liking". Links from a post to each individual "like" post can simply link to what the destination is, a liking of the current page.
 * Why not rel="like" - because that could be easily misinterpreted as the destination page being something that is a "like" of the person represented by the current page.

Favorites:
 * rel="favoriting". Links from a post to each individual "favorite" post can simply link to what the destination is, a favoriting of the current page.
 * Why not rel="favorite" - because that could be easily misinterpreted as the destination page being something that is a "favorite" of the person represented by the current page.

Not sure if it is worth further exploring response collections rels until there's a use case for marking them up explicitly.

Activity Streams has an extensions specially for this. One use-case might be to show these counts in feeds of followers as an indicator of popularity and might also be used for curating/filtering/sorting. &mdash;Www.sandeep.io 16:38, 26 June 2013 (PDT)

Related Posts

 * 2009-04-17 Mark Pilgrim : The Road to HTML 5: Link Relations "Link relations are a way to explain why you're pointing to another page. They finish the sentence 'I'm pointing to this other page because...'""... people typo the 'rev' attribute more often than they intentionally use it, which suggests that the world would be better off if validators could flag it as non-conforming. The decision to drop the rev attribute seems especially controversial. The same question flares up again and again on the working group's mailing list: 'what happened to the rev attribute?' But in the face of almost-universal misunderstanding (among people who try to use it) and apathy (among everyone else), no one has ever made a convincing case for keeping it that didn't boil down to 'I wish the world were different.' Hey, so do I, man. So do I."


 * Some pointer to previous discussion about this in the foaf-protocols community
 * read through some of this - seemed like a lot of overly complicated stuff, and some missing the forest for the trees problems too. - Tantek

Origins
This page was necessitated by RSSB introducing more types of responses than just comments which share common characteristics. See http://www.sandeep.io/79.