hCard Auto-discovery Brainstorming
- 1 hCard Auto-discovery Brainstorming
- 1.1 Authors
- 1.2 Representative hCard discovery
- 1.3 hCard to hCard relationships
- 1.4 Auto-Discovery for XFN
- 1.5 rel=me
- 1.6 vCard link rel auto-discovery
- 1.7 Related Pages
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.
- 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="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:
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?
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 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).
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”.
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.
- 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 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.