hcard-brainstorming-autodiscovery

hCard Auto-discovery Brainstorming

This page is for brainstorming about the auto-discovery of hCard. This page contains proposals. For the current state please see hCard.

Authors

• ???

Representative hCard discovery

Given a page with one or more hCards, which hCard is the representative hCard for the page?

See representative-hcard.

hCard to hCard relationships

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

home page to contact page

Numerous individuals and organizations identify themselves through their URL, and then include a separate page for their contact info. This is an existing practice that could be represented with microformats.

Examples:

• Ryan King, http://theryanking.com/ , http://theryanking.com/contact/
• Tantek Çelik, http://tantek.com/ , http://tantek.pbwiki.com/ContactCard/
• Google, http://www.google.com/ , http://www.google.com/intl/en/contact/index.html

These could be addressed by the following, mini hCard to expanded hCard brainstorming.

mini hCard to expanded hCard

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:

• rel="expanded"
• rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
• rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:

• rel="author"
• rel='contact'
• rel="contactinfo"
• rel='hcard'
• rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:

• rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
• rel='about' - what does "about" have to do with a person or even authorship?
• rel="profile" - should be reserved for meaning here is an XMDP profile for the current page.
• rel='PIM' - not sure about how this makes any sense either.

mini hCard to remote site

Per the instructions in hcard-examples for marking up people in blogrolls, you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

mini hCards and nearby expanded hCard links

Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on FactoryCity, blog posts have mini-hCards for "published by", e.g. (white space added for readability):

Published by 
<span class="vcard author">
 <a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
  Chris Messina
 </a>
</span>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

Auto-Discovery for XFN

An author will typically publish their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

rel=me

rel=me from XFN can be used to discover other pages with hCards. If a page needs an hCard, however, it likely should have the data right on the page (humans first, machines second).

vCard link rel auto-discovery

A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.

On the page with the hCard encoding, the best link would be as follows: <link rel="alternate" type="text/directory" href="..." /> this HTML page is an alternate view of the vCard.

The registered and appropriate type for vCard entities is “text/directory”, as defined in Internet RFC 2425, “A MIME Content-Type for Directory Information”. RFC 2426, “vCard MIME Directory Profile”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, Björn Höhrmann sent to the HTML Working Group a request for clarification on the issue.

When on a different page, referencing that encoded page in the href would not be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

Related Pages

• hCard
• hCard cheatsheet - hCard properties
• hCard creator (feedback) - create your own hCard.
• hCard authoring - learn how to add hCard markup to your existing contact info.
• hCard examples - example usage of various classes within hCard.
• hCard examples in the wild - an on-going list of websites which use hCards.
• hcard-supporting-user-profiles - sites with user profiles marked up with hCard - a very common example.
• hCard FAQ - if you have any questions about hCard, check here.
• hCard implementations - websites or tools which either generate or parse hCards.
• hCard parsing - normative details of how to parse hCards.
• hCards and pages - semantic distinctions between different hCards on a page, and how to identify each
• hcard-user-interface - techniques and issues surrounding user-interfaces to author, publish, and display hCards.
• hCard profile - the XMDP profile for hCard
• hCard singular properties - an explanation of the list of singular properties in hCard.
• hCard tests - a wiki page with actual embedded hCards to try parsing.
• hCard advocacy - encourage others to use hCard
• hCard "to do" - jobs to do

The hCard specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

• hCard brainstorming - brainstorms and other explorations relating to hCard.
  • hcard-parsing-brainstorming - brainstorming specific to parsing of hCard
  • geo brainstorming
• hCard feedback - general feedback (as opposed to specific issues).
• hCard issues - specific issues with the specification.
• vCard errata - corrections to the vCard specification, which underlies hCard.
• vCard suggestions - suggested improvements to the vCard specification.