Getting Semantic With Microformats, Part 6: hResume ~ A Blog Not Limited

I began this series a little over two months ago. I wanted to share my love of microformats and detail how I've implemented them, in hopes of encouraging more people to embrace them.

So far, I've covered a lot:

Rel-based microformats in Part 1
XFN in Part 2
hCard in Part 3
hCalendar in Part 4
hAtom in Part 5

And now, as I conclude this series, it is time to talk about the hResume microformat which is used to add semantics and structure to résumé and CV information on the web.

hResume Background

Before I dive into the markup and details of hResume, how about a bit of background information?

Draft Specification

hResume is a draft microformat. What does this mean? Ultimately, it hasn't been officially approved. And that means that it can (and probably will) change to some degree until becomes a formal specification.

Does this matter? Maybe to you, not to me. I pretty much accept that most web technologies are moving targets. It is just the nature of the web. No reason for me to not implement a technology in which I believe.

The Best of Microformats

hResume is, at its base, one of the simpler microformats, with only eight properties. At the same time, hResume is a compound microformat; it utilizes three other microformats: rel-tag, hCard and hCalendar.

In many ways, this represents the best of microformats: they utilize existing standards.

And the Worst

That said, how hResume utilizes hCard and hCalendar was, at least for me, confusing and frustrating at times. Perhaps this is due to the draft status and will be resolved before final approval. Perhaps it is me and my inability to think of my résumé content in the way required to apply hCard and hCalendar.

Regardless of the reason, hResume also respresents the worst of microformats … at least from my perspective.

It isn't the hResume itself that I find problematic per se. It is the overwhelming lack of comprehendible information and good documentation. This is something I think plagues microformats, in general, and specifically the Microformats Wiki.

Granted, hResume is a draft, so it is hard to expect there to be a lot of people invested in sharing information about it. But the wiki information for hResume leaves much to be desired.

I realize how horrible it is to say this, especially when I owe the wiki (not to mention its authors and contributors) a debt of gratitude for providing me what information is there. But the wiki is difficult to digest at its best, and flat-out confusing at its worst.

And when there are very few other resources for hResume, it makes for a very painful and frustrating process to implement the microformat.

But that is why I'm blogging about microformats, and I hope others do as well. The more people that talk about them (good, bad or indifferent), the better the information available will be.

So, done with my mini-rant. Moving on.

History

hResume has a very simple history. Unlike hCard, hCalendar and hAtom, it does not have a tie to a "precursor" technology.

It was, however, developed based on research of existing resume formats such as HR-XML and Europass.

The Basics

As with all microformats, there are a few "rules" that I'll mention (yet again):

Properties and sub-properties are expressed as class values. These are what define the hResume microformat.
Property and sub-property names are case-sensitive.
The "root" property cannot be combined with any of its sub-properties. Thus, <p class="hresume contact"> is invalid.
The markup used is irrelevant to the microformat (though the markup should be valid and semantic).

The Profile

Update: 04/21/2010

Recently, the microformats community completed updates to the profile URIs for all microformats. The correct values have been updated in this article. See my Microformats Profile URIs Updated post for further details.

Where you implement hResume, you should be sure to include its profile in the <head>:

<head profile="http://microformats.org/wiki/hresume-profile/http://microformats.org/profile/hresume">

As I've mentioned, hResume can take advantage of both hCard and hCalendar. So if you choose to utilize these additional microformats with your hResume, you should be sure to include their profiles, as well.

The W3C allows multiple profile values (separated by white space), so you could conceivably have all three profiles:

<head profile="http://microformats.org/wiki/hresume-profile/http://microformats.org/profile/hresume http://purl.org/uF/hCard/1.0/http://microformats.org/profile/hcard http://purl.org/uF/hCalendar/1.0/http://microformats.org/profile/hcalendar">

However, because both hCard and hCalendar are formal specifications, they are included in the combined profile URL that covers all non-draft microformats. I recommend using this single, combined profile with the hResume profile:

<head profile="http://microformats.org/wiki/hresume-profile/http://microformats.org/profile/hresume http://purl.org/uF/2008/03/http://microformats.org/profile/specs">

The Example

Unlike all the other microformats I've covered in this series, I did not implement hResume on A Blog Not Limited. I don't really see a reason to have my résumé on my personal blog, plus I already had it on my design portfolio.

The following example is taken directly from the résumé on my portfolio. It is a rather long bunch of markup and information, so I've cut that which is redundant in terms of hResume and replaced it with ellipses. I've also removed class values that are related to styling and have nothing to do with the hResume microformat.

If needed, you can always view the source of my live page to see it in its full glory.

<div class="hresume">
<div class="contact vcard">
<img src="/images/personal/emilyLewis.jpg" width="150" height="203" class="photo" alt="Emily Lewis" />
<h2 class="fn n" id="emily-hcard-name"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></h2>
<p class="adr"><span class="locality">Albuquerque</span>, <abbr class="region" title="New Mexico">NM<abbr> <span class="postal-code">87106</span> <abbr class="country-name" title="United States of America">USA</abbr></p>
<ul>
<li><a href="mailto:[email protected]" class="email">eplewis[at]gmail[dot]com</a></li>
<li><a href="http://www.emilylewisdesign.com/" class="url" rel="me">Design Portfolio</a></li>
<li><a href="http://www.linkedin.com/in/emilyplewis/" rel="me">LinkedIn profile</a></li>
</ul>
</div>
<h3>Highlights of Qualifications</h3>
<ul class="summary">
<li>Web designer specializing in hand-coded semantic XHTML, cross-browser CSS, progressive enhancement accessibility and usability</li>
<li>Expert in the design of corporate web sites, intranets, email campaigns and e-commerce applications</li>
…
</ul>
<h3>Technical Expertise</h3>
<h4>Web Design & Development</h4>
<ul>
<li><a href="http://technorati.com/tag/xhtml" class="skill" rel="tag">XHTML</a> — 9 yrs</li>
<li><a href="http://technorati.com/tag/css" class="skill" rel="tag" >CSS</a> — 9 yrs</li>
…
</ul>
…
<h3>Experience & Accomplishments</h3>
<div class="vcalendar">
<div class="experience vevent vcard">
<a class="include nonVisual" href="#emily-hcard-name"></a>
<h4 class="title summary">Web Designer</h4>
<p class="org fn">Pitney Bowes Business Insight</p>
<p><abbr class="dtstart" title="2004-12-01">December 2004</abbr> – present</p>
<ul class="description">
<li>Designed interfaces and developed XHTML, CSS and graphics for main corporate site, international sites, marketing newsletters, corporate blog, corporate intranet and user conference site</li>
…
</ul>
</div>
…
</div>
<h3>Education</h3>
<div class="vcalendar">
<div class="education vevent vcard">
<h4 class="summary">Web Design & Development Certification</h4>
<p class="org fn"><a href="http://www.gwu.edu/index.cfm" class="url" title="Link opens off this site">George Washington University</a>, Center for Professional Development</p>
<p><abbr class="dtstart" title="2001-09-01">September 2001</abbr>–<abbr class="dtend" title="2003-06-01">June 2003</abbr></p>
<p>GPA 3.8</p>
</div>
</div>
…
</div>

Root Property: `hresume`

The root property is hresume and it is required. All hResume information should be contained by an element assigned class="hresume":

<div class="hresume">

Required Property: `contact`

hResume has only one required property, contact, which indicates the name and contact information for the résumé owner. It can be used only once.

Additionally, hResume requires that the contact information be an hCard:

<div class="contact vcard">
<img src="/images/personal/emilyLewis.jpg" width="150" height="203" class="photo" alt="Emily Lewis" />
<h2 class="fn n" id="emily-hcard-name"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></h2>
<p class="adr"><span class="locality">Albuquerque</span>, <abbr class="region" title="New Mexico">NM<abbr> <span class="postal-code">87106</span> <abbr class="country-name" title="United States of America">USA</abbr></p>
<ul>
<li><a href="mailto:[email protected]" class="email">eplewis[at]gmail[dot]com</a></li>
<li><a href="http://www.emilylewisdesign.com/" class="url" rel="me">Design Portfolio</a></li>
<li><a href="http://www.linkedin.com/in/emilyplewis/" rel="me">LinkedIn profile</a></li>
</ul>
</div>

Identity Consolidation With `rel-me`

Also note in my example that I used rel-me on the links to my web sites:

<li><a href="http://www.emilylewisdesign.com/" class="url" rel="me">Design Portfolio</a></li>
<li><a href="http://www.linkedin.com/in/emilyplewis/" rel="me">LinkedIn profile</a></li>

As I detailed in Part 1, rel="me" is used on hyperlinks from one page about a person to other pages about that same person.

Issues With `address`

The hResume specification further recommends using <address> for containing the person's contact information.

According to the W3C, the <address> element is:

"… used by authors to supply contact information for a document or a major part of a document such as a form."

In the case of a résumé, <address> is semantically correct because the contact information is for the résumé owner.

However, you will note that I do not use <address> in my example (gasp!). This is because <address> can't contain block-level elements.

Sure, I could replace all the <p>s and the <ul> with <span>s, but that makes even less semantic sense to me than forgoing <address> entirely.

Optional Property: `summary`

The optional property summary indicates the overview of qualifications and objectives. It, too, can only be used once in an hResume.

In my résumé, I don't state an objective, but I do provide a list of qualifications:

<h3>Highlights of Qualifications</h3>
<ul class="summary">
<li>Web designer specializing in hand-coded semantic XHTML, cross-browser CSS, progressive enhancement accessibility and usability</li>
<li>Expert in the design of corporate web sites, intranets, email campaigns and e-commerce applications</li>
…
</ul>

Optional Property: `skill`

The optional skill property is applied to content that indicates a person's specific skills. skill can be used multiple times within an hResume.

The specification requires that skill content be contained by a link assigned class="skill" and rel="tag":

<ul>
<li><a href="http://technorati.com/tag/xhtml" class="skill" rel="tag">XHTML</a> — 9 yrs</li>
<li><a href="http://technorati.com/tag/css" class="skill" rel="tag">CSS</a> — 9 yrs</li>
…
</ul>

Link Crazy

While I've applied the skill property as the specification indicates, I really do not like all the extra links. I don't quite understand why the specification requires that the property be applied to link … why not any element?

All those extra links seem superflous on a résumé. And I'm not entirely sure they provide added value, particularly for a potential employer. In fact, it could be a distraction for someone interested in learning about me and my professional qualifications.

Tagspaces Seem Irrelevant

Another problem I have with the specification is that it also requires the links be assigned rel="tag".

In Part 1, I explained that rel-tag indicates the destination of the link is a tag (or keyword) that tells what the current page — or part of the page — is about.

Additionally, rel-tag requires that the link destination (href) include the actual value of the tag as the final segment of the URL value. This is known as the "tagspace."

Given these requirements, all of my skill links are directing to Technorati, since it provides such tagspaces.

However, this makes these links even more irrelevant as far as I'm concerned. If I'm going to have all these links, I would much prefer they go to something that provides discrete information about the tag, such as Wikipedia, but there aren't entries for all of my skills and I wanted to at least be consistent.

Ultimately, I may end up changing the link destinations to Wikipedia pages where they are available and removing skill links for which there aren't Wikipedia entries. Or I may decide to remove the skill links entirely. They are optional.

Optional Property: `experience`

The optional experience property indicates a person's various work experiences. It can be used multiple times.

The specification requires each work "event" be an hCalendar and that each work role/title be an hCard:

<div class="vcalendar">
<div class="experience vevent vcard">
<a class="include nonVisual" href="#emily-hcard-name"></a>
<h4 class="title summary">Web Designer</h4>
<p class="org">Pitney Bowes Business Insight</p>
<p><abbr class="dtstart" title="2004-12-01">December 2004</abbr> – present</p>
<ul class="description">
<li>Designed interfaces and developed XHTML, CSS and graphics for main corporate site, international sites, marketing newsletters, corporate blog, corporate intranet and user conference site</li>
…
</ul>
</div>
…
</div>

The Include Pattern: Avoiding Redundancy

Because the specification requires the assignment of hCard for all job roles/titles and hCard requires the fn property (the person's formatted name), this would mean that for each experience in my résumé, I would have to list all the name information.

This makes no sense whatsoever and goes against the expected format/content of a résumé.

Fortunately, the microformats folks came up with the include design pattern, which allows data from one area of a page be used in other areas of the same page.

By using the include pattern, I can include my fn information from my contact hCard in my experience hCard and avoid having to repeat it.

First, I had to assign my contact hCard fn information an id that I can reference in my include:

<h2 class="fn n" id="emily-hcard-name"><span class="given-name">Emily</span> <span class="additional-name">Paige</span> <span class="family-name">Lewis</span></h2>

Then, for all of my experience hCards, I added an <a> assigned class="include" with an href value equal to the fn id:

<div class="vcalendar">
<div class="experience vevent vcard">
<a class="include nonVisual" href="#emily-hcard-name">Emily Paige Lewis</a>
<h4 class="title">Web Designer</h4>
<p class="org fn">Pitney Bowes Business Insight</p>
<p><abbr class="dtstart" title="2004-12-01">December 2004</abbr> – present</p>
<ul class="description">
<li>Designed interfaces and developed XHTML, CSS and graphics for main corporate site, international sites, marketing newsletters, corporate blog, corporate intranet and user conference site</li>
…
</ul>
</div>
…
</div>

Alternately, the include pattern allows for the use of <object> rather than a link. <object> is actually more semantically correct than <a>, however it causes some display issues.

In Safari, for example:

Chrome does the same thing with scrollbars:

Opera doesn't show the scrollbars, but shows a ton of white space where <object> is:

Both IE6 and IE7 show something (I don't know what to call it) for the <object>:

Given these display inconsistencies, the link is the recommended method for the include pattern. Yet it, too, has issues.

Well, not "issues" really, just something to keep in mind: the link must have inner content to guarantee accessibility for screenreaders.

This means it will display on the browser, which necessitates that I use CSS to hide the content (via display:none) so that the link doesn't appear multiple times.

Datetime Design Pattern

Update: 06/02/2009

The datetime design pattern is now deprecated in favor of the value class pattern. See part 8 of this series for more on this new pattern.

For each of my work "events" I use hCalendar as recommended. This also means I'm using the datetime design pattern for my start and end dates:

<p><abbr class="dtstart" title="1999-11-01">November 1999</abbr> – <abbr class="dtend" title="2004-01-01">January 2004</abbr></p>

This pattern specifies that the containing element is an <abbr> which has a title attribute value that reflects "machine-readable" date/time information while the contained information (and what displays in the browsers) is "human-readable" date/time information.

Further, the datetime design pattern specifies that the title value should be expressed in ISO 8601 format.

As I detailed in Part 4, there are accessibility concerns surrounding the datetime design pattern that have yet to be addressed.

Optional Property: `education`

The optional education property indicates education "events," such as undergraduate schooling. education can be used multiple times within an hResume.

Similar to experience, the specification requires that each education "event" be an hCalendar. And while it isn't part of the specification, I also added hCard information for each institution:

<div class="vcalendar">
<div class=" education vevent vcard">
<h4 class="summary">Web Design & Development Certification</h4>
<p class="org fn"><a href="http://www.gwu.edu/index.cfm" class="url" title="Link opens off this site">George Washington University</a>, Center for Professional Development</p>
<p><abbr class="dtstart" title="2001-09-01">September 2001</abbr>–<abbr class="dtend" title="2003-06-01">June 2003</abbr></p>
<p>GPA 3.8</p>
</div>
</div>

What I Didn't Use

hResume also supports affiliation and publication information. I did not use either of these in my résumé because they aren't relevant to me (yet). But here are some examples of how I would implement them.

Optional Property: `affiliation`

The optional affiliation property indicates organizations with which a person is affiliated. affiliation can be used multiple times in an hResume.

The specification requires that the organization contained by affiliation be an hCard:

<ul>
<li class="affliation vcard"><span class="fn org">Association for Accounting Marketing</span></li>
<li class="affliation vcard"><span class="fn org">NM Adobe Users Group</span></li>
</ul>

Publications

hResume doesn't have a property specific to publications. Instead, the specification recommends the use of <cite> to indicate publications a person has authored:

<cite>"Choosing the Best Managed Care Plan"</cite>, New OD, September 1998

Tools to Make it Easier

That covers the entirety of hResume. Now, how about making it easier on yourself? There are a few tools to help you implement hResume:

hResume creator generates an hResume from submitted information.
The hResume Project has created an hResume plugin for WordPress.
Emurse offers some templates that generate hResume.
LinkedIn generates hResume for all of its 9 million public profiles.
CV Antix is a dynamic, web-based resume/CV builder.
Resolio creates all résumés in hResume format.

Other Tools

There is a LinkedIn hResume plug-in for WordPress that extracts hResume content from a LinkedIn public profile, which can then be added to a WordPress page.
Brian Suda has a beta hResume to resume XML tool.
The Optimus microformats transformer provides a transformer from hResume to JSON, XML or RSS.

Unfortunately, I couldn't find any hResume aggregators or extractors, although I've seen mention that SimplyHired uses hResume to aggregate job seekers' résumés. Unfortunately, I couldn't find specific information about this, nor did I see any hResume on the site.

I also couldn't find any browser plugins or add-ons, though, interestingly, an earlier version of the Tails Firefox extension supported hResume. But this doesn't work with the current version of Firefox.

On some level, this lack of tools this surprises me. But it also doesn't.

As I ranted at the beginning of this article, the available information on hResume is minimal and not too easy to digest. Plus, hResume is a draft. Doesn't surprise me that folks haven't invested too much in developing tools for it.

I hope this changes.

Benefits

For me, when someone asks why I'm using microformats, the answer is simply "Why wouldn't I?" Standards, semantics and microformats are all good in my world.

But here are just a few benefits of hResume and microformats for those who need convincing.

Standardization & Innovation

hResume provides a standardized way for people to control their résumé data, which is a needed foundation for innovative tools and technologies.

If job boards were to embrace hResume, this standardization means that résumé content could be housed and updated in one location, and then pinged to job boards when there are updates.

This standardization also provides the foundation for people to have rich and useful résumés that could be easily searched by potential employers and clients.

Semantics & Simplicity

hResume adds structure and meaning to résumé content and makes it both human– and machine–readable. All with existing standards for markup and data.

And despite my own struggle implementing hResume, it is intentionally simple. Just a few class names added to markup and hResume is in place.

That's It?

Well, that's all I have for hResume. But it isn't the true end of this series.

I have one more article: a conclusion where I plan to discuss what I've learned during the process of writing this series.

I also plan to touch on accessibility, semantics and standards (again). And a brief discussion of the "microformats vs. RDF" debate is in order. And whatever else may occur to me.

Until then …

Update: 12/07/2008

Jia Mi has translated this article in Chinese: 使用微格式来丰富网站语义：hResume.

I don't read Chinese, so I can't attest for the translation. But the intention is good, so I'm promoting it.

Update: 1/08/2009

Jan Sládek has translated this article in Czech: Kódujme sémanticky s mikroformáty: hResume.

A Blog Not Limited

to web design, standards & semantics