E-Resume Formats Analysis

h-Resume and JSON Resume

I have been pondering CV formats of late, not because I am looking for another job, but because someone I know is, and they are getting increasingly annoyed with replicating the information they have onto application forms.

After looking around there seems to be two major contenders for a preferred format, h-resume and JSON Resume. I am going to take some time analysing these two formats and then compare and contrast them before making a decision as to what I will suggest my friend uses as a base format to store data for filling in application forms.

h-Resume

This microformat is a way of using standard HTML markup to allow the parsing of resume data. It uses a number of specific attributes in the markup to indicate the meaning of the content of the markup. It builds upon other microformats such as h-card and h-event and as such has an august ancestry.

I have used h-card extensively and implement it in all of the projects I can but think that I am in a minority. The idea of having the same data parsable by both humans and machines is something which has been an ideal for many years and is one of the strands of the Semantic Web and microformats could play a part in this ideal. As an idea the Semantic Web holds a great deal of promise but it has many detractors and to an extent has been superseded by other approaches. An analogy would be to think of content on the Semantic web being presented in two formats. One of which is understandable by humans and the other a shadow language which indicates the meaning of the human readable language to machines. The way that microformats manage this is best illustrated with an example:

This is one representation of me:

Dominic Myers
Senior Developer
Arcus Global Limited
dominic@arcusglobal.com
Future Business Centre,
King's Hedges Road
Cambridge,
Cambridgeshire,
CB4 2HY
+44(0)1223 911 841

If I were to put this information on a webpage I would use this markup:

<p>Dominic Myers</p>
<p>Senior Developer</p>
<p>Arcus Global Limited</p>
<p><a href="mailto:dominic@arcusglobal.com">dominic@arcusglobal.com</a></p>
<p>Future Business Centre,</p> 
<p>King's Hedges Road</p>
<p>Cambridge,</p>
<p>Cambridgeshire,</p>
<p>CB4 2HY</p>
<p>+44(0)1223 911 841</p>

This markup would tell the browser to display each of the lines in its own paragraph and the lines would be rendered one after the other on the page. If I were to use a microformat such as h-card (as I did using an online hCard Creator) I would get this markup:

<div id="h-card-Dominic-Richard-Myers" class="h-card">
    <a class="u-url p-name" href="http://dominicmyers.uk">
        <span class="p-given-name">Dominic</span>
        <span class="p-family-name">Myers</span>
    </a>
    <div class="p-org">Arcus Global Limited</div>
    <a class="u-email" href="mailto:dominic@arcusglobal.com">dominic@arcusglobal.com</a>
    <div class="p-adr">
        <div class="p-street-address">Future Business Centre, King's Hedges Road</div>
        <span class="p-locality">Cambridge</span>, 
        <span class="p-region">Cambridgeshire</span>, 
        <span class="p-postal-code">CB4 2HY</span>
        <span class="p-country-name">United Kingdom</span>
    </div>
    <div class="p-tel">+44(0)1223 911 841</div>
    <div>
        <span class="p-role">Senior Developer</span>
    </div>
</div>

In terms of the display of the data in the browser they are nearly identical (and could be made identical with some extra effort) and in terms of the informational content for the human reader they are identical, but the addition of those extra class attributes means that suitable parsers are able to make some sense of the data - would be able to offer to call me on the telephone and address a letter/parcel, might even show the position of my work-place on a map, the possibilities are almost endless. This is a powerful concept and similar to one ideal behind the Semantic Web: of intelligent software agents being able to search the internet for themselves and find data of relevance to their master.

h-resume uses h-card as well as h-event to display richer data about a person looking for employment. Its main properties are:

• p-name - brief name of the resume
• p-summary - overview of qualifications and objectives
• p-contact - current contact info in an h-card
• p-education - an education h-event event, years, embedded h-card of the school, location
• p-experience - a job or other professional experience h-event event, years, embedded h-card of the organization, location, job-title
• p-skill - a skill or ability, optionally including level and/or duration of experience
• p-affiliation - an affiliation with an h-card organization

As such we can see that we markup a standard resume with machine parseable attributes according to 3 specific schemas. It must also be noted that all properties are optional. h-resume, like h-card and h-event, are all parts of the microformat2 specification and h-resume in particular is a draft specification. They are all directly related to microformat specifications as h-resume is an update to hResume, h-card is an update to hCard and h-event is an update of hCalendar.

It has an advantage of not making any demands upon the reader, the display of data can remain the same, extra attributes within the markup tags allow for the parsing by machines. The h-resume specification, along with h-card and h-event specifications, have only optional properties. The structure of a resume can be altered, for instance interspacing education and employment datums, and one would still imagine that parsers would be able to understand and place those datums into suitable arrays. To an extent this might be valuable for those who continue with pursuing educational attainment whilst at work as it would provide a more narrative resume.

JSON Resume

Whilst h-resume has its feet firmly planted within the sphere of XML, making use of markup attributes as it does, JSON Resume has a much more modern feel as it proudly uses JavaScript Object Notation (JSON) to store relevant data. It also seems to have a much more developer rather than Computer Scientist focus - as h-resume seems to do.

It has 10 properties compared to the 7 of h-resume:

• basics - object
• work - array of objects
• volunteer - array of objects
• education - array of objects
• awards - array of objects
• publications - array of objects
• skills - array of objects
• languages - array of objects
• interests - array of objects
• references - array of objects

JSON Resume is a new format and is on Version 0.0.0 with the schema being hosted on GitHub, as such people are free to adapt it to their requirements. Because it uses JSON we should perhaps discuss the data format more. JSON is a data-interchange format which is easily read by both humans and machines and is familiar to developers. It is made up of key/value pairs with the value possibly being an object, array or data primative. In terms of its formatted appearance it is similar to XML, being a nested representation of a collection of datums. In order to demonstrate this we could use the example I used above for my h-card:

{
    "full name": {
        "given name": "Dominic",
        "family name": "Myers"
    },
    "email": "dominic@arcusglobal.com",
    "organisation": {
        "name": "Arcus Global Limited",
        "address": {
            "street address": "Future Business Centre, King's Hedges Road",
            "locality": "Cambridge",
            "region": "Cambridgeshire",
            "postal code": "CB4 2HY",
            "country": "United Kingdom"
        }
    },
    "telephone": "+44(0)1223 911 841",
    "role": "Senior Developer"
}

It must be noted that this is not a representation of JSON Resume but merely an example of JSON. The exact same data is stored in the above JSON as was stored in the h-card and in a similar way in terms of the structure (please note the indentation as it indicated a datums position within a hierarchy of information in both formats). There is a distinct difference in terms of the legibility and the number of characters used (802 for XML and 516 for the JSON) though with JSON being significantly more descriptive and less opaque.

JSON Resume is not a display format though. While it is certainly readable by both humans and machines it is not designed for display in the same way that h-resume is. It is reliant upon a developer putting it through a process in order for a desirable display to be produced. This is both a strength and weakness as it allows for greater control of the display of the information but is reliant upon a certain level of technical knowledge.

Another strength is its use of arrays to hold collections of similar datums. This is perhaps a recognition of and a nod to the people whom JSON Resume is designed for as such a structure is familiar to developers and seems elegant.

Discussion

It is perhaps unfair to characterise r-resume as an XML format but it is understandable in that it uses HTML, which is a subset of XML. It is possible for a well formatted HTML document to be parsed as valid XML… I think we can be justified in calling it XML like at the very least.

While JSON Resume needs to be formatted in order to produce a meaningful display h-resume is already in a form designed for display. In their raw forms the reverse is true with JSON Resume being much more readable. To some extent comparing the two is the equivalent of comparing a chicken with an egg. One has the ability to be the other but the reverse is less true.

Properties

h-resume has 7 main properties whereas JSON Resume has 10:

Format:	h-resume	JSON Resume
Properties:	p-name p-summary p-contact p-education p-experience p-skill p-affiliation	basics work volunteer education awards publications skills languages interests references

There a a number of similar properties and it could be argued that both formats allow for the display of exactly the same information, directly analogous properties are shown in this illustration:

Further, it is possible to tentatively link properties from one to the other:

This is by no means an exhaustive merging of the fields from the two formats as I have simply tried to make the two merge by keeping my own Curriculum Vitae in mind. However p-name from h-resume and references from JSON Resume are left as orphan properties without some near exact equivalent - though, as noted above, it is possible for a person to massage relevant data into both formats without much difficulty.

Conclusion

As formats go I would argue that JSON Resume is perhaps the most flexible, despite it not having a p-name property - a property which is merely designed to provide a unique name for the resume - it offers far greater granularity in terms of the properties h-resume classifies as p-experience. Rather than lumping paid and unpaid work, awards and publications together JSON Resume allows these different areas to be separated. It might be argued that the same could be said for h-resume and that each area could be separated visually but marked up in the same way.

Both h-resume and JSON Resume both make a point of including skills but whereas JSON Resume has a suggested format for these characteristics h-resume proposes a format to include a vocabulary designed to describe a skill. I am not sure how to measure a skill and what metrics to use so the use of such a vocabulary might be worthwhile as it is proposed to include a name, rating and - most importantly - a duration. Someone who has practiced a skill for a greater length of time is likely to be more adept at that skill - just so long as they do not become stuck in their ways. A rating is likely to reference some form of professional qualification and this area is contentious as there are any number of bodies willing to provide certification depending upon the profession involved. JSON Resume counters this problem by having a distinct area for awards so the audience can make their own decision about whether a certification is from a valid professional body.

I have touched upon the fact that JSON Resume is designed to be a data interchange format rather than a display format and this means that to some extent the comparison is unfair. It is feasible for a developer to create a rendering theme which could turn JSON Resume into a perfectly valid h-resume document. This then means I would suggest that storing resume data in JSON Resume format offers the best approach, the format is flexible and parsers are designed to look for particular key/value pairs when displaying data - allowing for the possibility to extend those parsers to include other data which might be of relevance.

Addendum

There are many other Resume formats available with differing levels of support so this is by no means an extensive analysis, please do read about the other formats.