representative-hcard

This article is actively undergoing a major edit for a short while. As a courtesy, please do not edit this page while this message is displayed. The user who added this notice will be listed in the page history. If this page has not been edited for over an hour, please remove this template. This message is intended to help reduce edit conflicts; please remove it between editing sessions to allow others to edit the page.

representative hCard

This page is for keeping track of the representative hCard effort, which is part of hcard-brainstorming, specifically to figure out how to both explicitly specify and discover the representative hCard for a page.

problem statement

Short version: Given a URL, how do you determine which hCard is the representative hCard for that page?

Longer: Given a URL to a page that represents a person, how do you determine which hCard on that page is the hCard for that person? Variants:

• Given a URL to a person's hCard supporting user profile, how do you determine which hCard on the profile page represents that person?

goals

• should leverage current hCard information publishing patterns
• should not require any additional user interface elements (i.e. links) on any hCard supporting user profiles.

effort

• representative-hcard-examples - analysis of examples of hCards in the wild on pages representing individual people
• representative-hcard-formats - previous attempts at providing representative hCard or "person info" in general for a page that represents a person.
• representative-hcard-brainstorming - proposals for solving the problem

Representative hCard discovery

See representative-hcard.

Ways to auto discover the representative hCard for a page, that is the hCard that is the person (or organization) that the page represents.

Applications for auto-discovery of the representative hCard for the page

• representative vCard auto extraction from the page
• profile icon discovery (e.g. what people use gravatar for and have proposed pavatar for).
• social-network-portability

Related but slightly different concepts:

• contact for the page. similarly, the person a page represents is usually the person to contact for/about the page. as documented in the hCard FAQ, the contact for a page SHOULD be marked up with an <address> hCard.
• author hCard. typically the person that a page represents is also the author of the page. possible (theoretical until someone finds/cites real world) examples: biographies, e.g. a page that represents person A is authored by person B.
  • common misconception: "using <address> works when the person is the principal author of the page". This is misleading at best. It may "work", but <address> means contact for the page (as documented above), not necessarily the author. The two might coincidentally (even typically) be the same, but are not semantically equivalent.
• owner hCard. more often than not, the person that a page represents is also the person that owns (meaning has primary control over, in the property sense) the page.

Methodology for a solution: The preferred option is to use only visible semantic HTML (POSH).

User scenario: Here is a scenario that outlines the proposed auto-discovery process:

1. I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
2. That site goes and gets it (e.g. using hKit), and then:
   1. checks to see if there is an hCard with a "url" property on a rel="me" hyperlink (since rel="me" only works from a whole page to a whole page, if an hCard contains such a URL, then that hCard must represent the page. see XFN identity consolidation for more details.), and uses it if it finds it. (if there is more than one such hCard on the page? for now use the first such hCard.)
   2. checks to see if there is an hCard with a "url" property that points to the current page, and uses it if it finds it. similar to the above rel="me" case, if an hCard is pointing to the current page, then it is likely that the hCard is about the current page. (if there is more than one such hCard on the page? for now use the first such hCard.)
   3. checks to see if there is an <address> hCard (thus meaning contact for the page), and uses it if it finds it. (what if there is more than one such hCard on the page? e.g. such as the multiple address hCards for hAtom entries. for now use the first such hCard.)
   4. otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on Flickr and Technorati, will work as expected).
3. The site looks in the hCard for a "logo" property and uses the first one if it finds any.
4. Otherwise it looks for a "photo" property and uses the first one if it finds any.
5. Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.

See Also

• hcard
• hcard-brainstorming