resume-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(added a sample publication)
m (Reverted edits by Wwwlampungservicecom (Talk) to last version by GlennJones)
 
(21 intermediate revisions by 12 users not shown)
Line 1: Line 1:
=Resumé Brainstorming=
<h1> Resumé Brainstorming </h1>


This is a space for brainstorming about a microformat for resumes/CVs.
This is a space for brainstorming about a microformat for resumes/CVs based upon the [[resume-examples]] that have been researched, documented, and analyzed, with an eye towards reusing portions of vocabulary from any well adopted [[resume-formats]].


__TOC__
__TOC__
Line 14: Line 14:
* [[resume-examples]]
* [[resume-examples]]
* [[resume-formats]]
* [[resume-formats]]


== Analysis ==
== Analysis ==
Line 40: Line 41:
These are things found in [[resume-examples]], which seem to be outside of the 80/20 of common resume constructs. --[[User:RyanKing|RyanKing]] 14:46, 30 Jan 2006 (PST)
These are things found in [[resume-examples]], which seem to be outside of the 80/20 of common resume constructs. --[[User:RyanKing|RyanKing]] 14:46, 30 Jan 2006 (PST)


* exhibitions - too rare?
* objective - just use summary
* status - just use the 'summary'
* appearances and awards- don't know how to generalize this
* appearances and awards- don't know how to generalize this
* awards - too specific and rare
* awards - too specific and rare
** I'm developing a CV / faculty bio system for NYU. Currently, 116 of 249 (~46.5%) faculty bios (many of which are stubs without all the data) are displaying awards, with the majority of those displaying awards having 3+. --[[User:WizardIsHungry|Jon Williams]] 10:37, 25 Jan 2007 (PST)
* presentations - sure probably be part of one of the above, not sure where it fits in yet
** presentations can be simply lumped in with other citations of publications/work
* patents - too rare
** perhaps citations could be used for patents, since they are published works
* interests - too rare
* interests - too rare
* objective - just use summary
* patents - too rare
* portfolio - too rare?
* portfolio - too rare?
** [http://kilianvalkhof.com/2006/web/rel-for-practical-use/ XPN] seems like it would be a logical addition. --[[User:WizardIsHungry|Jon Williams]] 11:55, 25 Jan 2007 (PST)
* projects - too rare?
* projects - too rare?
* status - just use the 'summary'
* exhibitions - too rare?
* presentations - sure probably be part of one of the above, not sure where it fits in yet
 
===== Additional Metadata =====
* It would be helpful to have the following fields associated with skills: [[User:Robert Merrill|Robert Merrill]] 07:41, 12 Feb 2006 (PST)
** Skill-Level: Beginner, Advanced, Expert
** Years of experience with skill (numeric)
** Last used: either value of "currently used" or years since last-used
* Unfortunately none of these showed up with sufficient frequency (if at all) in the resumes found published in the wild, and based upon the principle of simplicity and 80/20, it makes sense to simply omit these from at least the first version of an [[hresume|hResume]] microformat. - Tantek
* Would it make sense to use [[hreview|hReview]] here? Since this is in a sense a review of a persons skills. --[[User:Ajaswa|Ajaswa]] 18:35, 16 Jun 2007 (PDT)


=== Other Brainstorming ===
=== Other Brainstorming ===
Line 81: Line 94:
* skill
* skill
** experience (job, education, etc)
** experience (job, education, etc)


== Application of current microformats ==
== Application of current microformats ==
Line 129: Line 141:


* "hresume" - root class name
* "hresume" - root class name
** "contact" [[hcard|hCard]] - should use <code><nowiki><address></nowiki></code>. Can be the person who the resume is about OR the proxy/contact in the case of recruiting/hiring services
** "contact" [[hcard|hCard]] - should use <code class="element">&lt;address&gt;</code>. Can be the person who the resume is about OR the proxy/contact in the case of recruiting/hiring services
** "objective" - block of text explaining the objective
** "objective" - block of text explaining the objective
** "job" [[hcalendar|hCalendar]] vevent - for each job in the jobs section:
** "job" [[hcalendar|hCalendar]] vevent - for each job in the jobs section:
Line 136: Line 148:
*** [[hcard|hCard]] for the school with fn==org, address of school, (optionally, url, phone numbers, etc.).
*** [[hcard|hCard]] for the school with fn==org, address of school, (optionally, url, phone numbers, etc.).
** "skill" [[rel-tag]] - for each skill
** "skill" [[rel-tag]] - for each skill
** <code><nowiki><cite></nowiki></code> for each publication
** <code class="element">&lt;cite&gt;</code> for each publication
** rel="reference" + [http://gmpg.org/xfn/ XFN] + [[hcard|hCard]] for references.  rel="reference" makes sense because you are saying this person over here is a reference for the person represented by this resume.
** rel="reference" + [http://gmpg.org/xfn/ XFN] + [[hcard|hCard]] for references.  rel="reference" makes sense because you are saying this person over here is a reference for the person represented by this resume.


Line 177: Line 189:


'''Issue:''' need to check with Brian Suda to see how easy/hard it would be to add this to X2V.  Given that it wasn't too difficult to add the table td "headers" attribute content indirection support, this should be just as easy.
'''Issue:''' need to check with Brian Suda to see how easy/hard it would be to add this to X2V.  Given that it wasn't too difficult to add the table td "headers" attribute content indirection support, this should be just as easy.
'''Status:''' According to Brian Suda: "... it shouldn't be too difficult... you are right it is pretty similar to the AXIS HEADER ID problems."
'''Next Steps:''' Brian will try implementing it in X2V and we'll see how well it works.  If it works, then we'll add it to [[hcard|hCard]], [[hcard-parsing]], and [[hreview|hReview]] 0.3 (as well as [[hresume|hResume]] of course).  Note that the [[hlisting-proposal|hListing proposal]] also has a similar requirement/concept and is currently using a notion of property inheritance from the context that it may be placed in (typically the page context).  This may be an even nicer fallback from an authoring point of view, but may require more implicit parsing than can be relied upon.
'''Implemented:'''Brian Suda: i have managed to roll this into X2V pretty easy, it is only in the beta X2V code, if it proves useful and worth while then we can roll it into the production version.
'''Issue:''' These object elements end up rendering quite horribly in Safari, and <code>display: none</code> doesn't help. The solution is to style the objects with <code>width: 0; height: 0;</code>.


== Strawman Outline ==
== Strawman Outline ==
Line 213: Line 233:


@class~="summary" (like hCalendar, hReview, etc.)
@class~="summary" (like hCalendar, hReview, etc.)
=== Possible additions===
====Salary====
What about including salary (aka wage, payment, earnings) using the proposed [[currency]]] microformat? - Andy Mabbett


== Strawman Draft ==
== Strawman Draft ==
Line 227: Line 252:
* hResume
* hResume
** summary. optional. text.
** summary. optional. text.
** contact info. required. <code>&lt;address&gt;</code> + [[hcard|hCard]].
** contact info. required. <code class="element">&lt;address&gt;</code> + [[hcard|hCard]].
** education. optional. One or more [[hcalendar]] events with the class name '<code>education</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.
** education. optional. One or more [[hcalendar]] events with the class name '<code class="class-name">education</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.
** experience. optional One or more [[hcalendar]] events with the class name '<code>experience</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.
** experience. optional One or more [[hcalendar]] events with the class name '<code class="class-name">experience</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code>skill</code>'.
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code class="class-name">skill</code>'.
** affiliations. optional. @TODO
** affiliations. optional. the class name <code class="class-name">affiliation</code> along with an [[hcard]] of the organization
** publications. optional. One or more citations. Use cite tag.
** publications. optional. One or more citations. Use cite tag.
** references. optional. One or more references.
** references. optional. One or more references.
Line 239: Line 264:


* '''summary''':: This optional field serves as a overview of qualifications and objectives.
* '''summary''':: This optional field serves as a overview of qualifications and objectives.
* '''contact''':: Current contact info. The <code>&lt;address&gt;</code> with [[hCard]].
* '''contact''':: Current contact info. The <code class="element">&lt;address&gt;</code> with [[hCard]].
* '''education''':: the class name '<code>education</code>' is applied to an [[hcalendar]] event.
* '''education''':: the class name '<code class="class-name">education</code>' is applied to an [[hcalendar]] event.
* '''experience''':: the class name '<code>experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].
* '''experience''':: the class name '<code class="class-name">experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].
* '''skills''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code>skill</code>' class name.
* '''skills''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code class="class-name">skill</code>' class name.
* '''affiliations''':: @TODO
* '''affiliations''':: The class name <code="class-name">affiliation</code> is used along with an [[hcard]] of the organization
* '''publications''':: just use <code>&lt;cite&gt;</code>.  When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.
* '''publications''':: just use <code class="element">&lt;cite&gt;</code>.  When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.
* '''rel="reference"'''.  For references, link to the person with rel="reference" and any other [http://gmpg.org/xfn/ XFN] values that apply (e.g. "colleague", "co-worker", "friend", "kin" etc.), and use [[hcard|hCard]] to markup the name of the reference.
* '''rel="reference"'''.  For references, link to the person with rel="reference" and any other [http://gmpg.org/xfn/ XFN] values that apply (e.g. "colleague", "co-worker", "friend", "kin" etc.), and use [[hcard|hCard]] to markup the name of the reference.


Line 265: Line 290:
=== Contact ===
=== Contact ===
<pre><nowiki>
<pre><nowiki>
  <address class="vcard">
<address class="vcard">
    <span class="fn">Joe Smith</span>
  <span class="fn">Pedro Sanchez</span>
    <span class="adr">
  <span class="adr">
      <span class="street-address">123 Fake St.</span>
    <span class="street-address">123 Fake St.</span>
      <span class="locality">Anywhere</span>, <span class="region">CA</span> <span class="postal-code">123456</span>
    <span class="locality">Preston</span>, <span class="region">Idaho</span> <span class="postal-code">83263</span>
    </span>
  </span>
    <span>Email: <a class="email" href="mailto:joe@example.com">joe@example.com</a></span>
  <span>Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a></span>
    <span>Homepage: <a class="url" href="http://example.com/~joe/">example.com/~joe/</a></span>
  <span>Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a></span>
    <span>Phone: <span class="tel">+01.555.123.4567</span></span>
  <span>Phone: <span class="tel">+01.208.555.4567</span></span>
  </address>
</address>
</nowiki></pre>
</nowiki></pre>


=== Education ===
=== Education ===
<pre><nowiki>
<pre><nowiki>
<ol class="education vcalendar">
<ol class="vcalendar">
   <li class="vevent">
   <li class="education vevent">
     <a class="url summary" href="http://example.edu/">Master of Science in Web 2.0</a>,
     <a class="url summary" href="http://example.edu/">Preston High School</a>
     <span class="location">University of the Web</span>  
     (<abbr class="dtstart" title="1995-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)
    (<abbr class="dtstart" title="1995-01-24">January 1995</abbr> - present)
   </li>
   </li>
   ...
   ...
Line 289: Line 313:


=== Experience ===
=== Experience ===
==== Basic ====
A basic experience event:


<pre><nowiki>
<pre><nowiki>
<ol class="experience vcalendar">
<ol class="vcalendar">
   <li class="vevent">
   <li class="experience vevent">
     <span class="summary">Founder</span>,  
     <span class="summary">President</span>,
     <span class="location">Flappr</span>,  
     <span class="location">Preston High School</span>,
     <abbr class="dtstart" title="2005-05-25">May 1999</abbr> - present
     <abbr class="dtstart" title="2004-09-01">May 2005</abbr> - <abbr title="2005-05-25">present</abbr>
   </li>
   </li>
   ...
   ...
</nowiki></pre>
</nowiki></pre>
==== Job Titles ====
To express multiple job titles/positions in the same experience event you should use [[hCard]]s. [[hcard]] requires the <code class="class-name">fn</code> ("formatted name") field, but it isn't reasonable to repeat your name for every job title you mark up in [[hResume]]. So, you may use an <code class="element">&lt;object&gt;</code> with a reference to the <code class="class-name">fn</code> somewhere else on the page.
For example, this [[hCard]] refers to another [[hCard]]
<pre>
<span class="vcard">
  <object data="#j" class="fn n"></object>
  <span class="org">Preston High School</span>
  <span class="title">Class President</span>
</span>
</pre>
Where "<code class="attr-value">j</code>" is the id attribute value of the "<code class="mf-prop">fn n</code>" element of the contact [[hCard]] at the top of the page, e.g. (shown here as a verbose [[hCard]] for purposes of illustration that the reference may be to a subtree, not just a text node):
<pre><nowiki>
<address class="vcard">
  <span class="fn n" id="j">
    <span class="given-name">Pedro</span>
    <span class="family-name">Sanchez</span>
  </span>
</address>
</nowiki></pre>
This method of hCard property indirection via an object element could be generalized to apply to any/all string/text properties in hCard.
Note: the object data attribute MUST be a local ID reference. External references (which would require a consuming application to load an external resource) are currently not supported by this method.


=== Skills ===
=== Skills ===
 
Some sample skills tags:
<pre><nowiki>
<pre><nowiki>
I have skills in <a rel="tag" href="http://wikipedia.org/wiki/ajax">ajax</a>  
I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a>  
and <a rel="tag" href="http://wikipedia.org/wiki/num+chucks">num chucks</a>.
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.
</nowiki></pre>
</nowiki></pre>


=== Affiliations ===
=== Affiliations ===
<pre><nowiki>
<pre><nowiki>
  @TODO
<span class="affiliation vcard"><span class="fn org">National Honor Society</span></span>
</nowiki></pre>
</nowiki></pre>


=== Publications ===
=== Publications ===
<pre><nowiki>
<pre><nowiki>
  <cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.
<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.
</nowiki></pre>
</nowiki></pre>
== Adding qualifications, subject and grades to education ==
I have been marking up a number of CVs with hResume and believe that there is a major piece missing from the specification. Most CVs have some sort of educational history, which will contain information such as institution name, qualifications and grades. Some real life examples:
* 1987-1990, University of Bristol BSc (Hons) Degree in Computer Science
* Mathematics Higher B
* 1992: A levels Mathematics, Further Mathematics, Physics, Chemistry (all grade A)
* 5 O levels (Grades A-C)
* In 1999 I graduated with honours from a 4 year Hons BSc in Artificial Intelligence and Computer Science at the University of Edinburgh, Scotland. This degree is designed to give the student a firm grounding in the subjects of Artificial Intelligence and Computer Science while demonstrating how the two are related and how each can be used to supplement the other.
Currently the education element of hResume is based on hCalendar which is great at dealing with the time elements of education item such as start date, end date and duration. It has also been expanded with an embedded hCard to help indicate the institution name, address etc.
But this combination of hCalendar and hCard only addresses half of the common semantic information communicated about education history. How do we mark-up qualifications, subjects and grades? If I was to design a specification based on real world use and current schemas like HR-XML it would look something like this:
=== Proposed new schema for education item ===
* Education
** Institution (hCard)
** dtstart
** dtend
** duration
** summary
** qualification (<strike>one</strike>zero or more)
*** name
*** subject
*** grade
*** description
*** number
=== Field details ===
The fields of the new education item schema represent the following:
* '''Institution''': ([[hcard|hCard]]) The contact info of the educational institution
* '''dtstart''': The date the individauls education start at the institution
* '''dtend''': The date the individauls education ended at the institution
* '''duration''': The duartion of the education
* '''summary''': A summary of the the education
* '''qualification''' (one or more)
** '''name''': The name of the qualification  i.e. BA(Hons) 
** '''subject''': The main subject of the qualification i.e. Computer Science
** '''grade''': The grade given i.e. 2:1
** '''description''': A description of the qualification 
** '''number''': Used to define a group of qualifications. 
[[User:GlennJones|Glenn Jones]] 5 Aug 2008
* +1 [[User:TobyInk|TobyInk]] : the current hCard+hCalendar event model kinda works for experiences (though if they're intermingled it can be a bit messy), but is insufficient for education. The model above is much simpler to parse and also much easier to author. I'd suggest making "qualification" a "zero or more" property though — some courses are attended simply for education, with no bit of paper at the end. I'd also suggest that "experience" should be similarly rethought.


== Examples in the wild ==
== Examples in the wild ==
Line 329: Line 428:
* [[rel-tag]]
* [[rel-tag]]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
== Related Pages ==
{{hresume-related-pages}}

Latest revision as of 00:39, 6 November 2017

Resumé Brainstorming

This is a space for brainstorming about a microformat for resumes/CVs based upon the resume-examples that have been researched, documented, and analyzed, with an eye towards reusing portions of vocabulary from any well adopted resume-formats.

Contributors

Consequence of


Analysis

Examples Analysis

A first pass at some analysis of the Aggregate analysis on resume-examples. A proposed 80/20:

affiliations a list of affiliations, each with organization name, url and association type
contact info contact info - address, email, url
education a list including organization/school info (name, location), degree/area of study, honors/awards, date (graduation only or range), GPA
employment/professional experience a list including the organization, timeframe, job title and location, accomplishments, description
skills an outline of skills/tools broken down by general categories
publications/presentation a list of writings, each including author(s), title, url and published year
summary/qualifications a list of qualifications and competencies

left off for now

These are things found in resume-examples, which seem to be outside of the 80/20 of common resume constructs. --RyanKing 14:46, 30 Jan 2006 (PST)

  • objective - just use summary
  • status - just use the 'summary'
  • appearances and awards- don't know how to generalize this
  • awards - too specific and rare
    • I'm developing a CV / faculty bio system for NYU. Currently, 116 of 249 (~46.5%) faculty bios (many of which are stubs without all the data) are displaying awards, with the majority of those displaying awards having 3+. --Jon Williams 10:37, 25 Jan 2007 (PST)
  • presentations - sure probably be part of one of the above, not sure where it fits in yet
    • presentations can be simply lumped in with other citations of publications/work
  • patents - too rare
    • perhaps citations could be used for patents, since they are published works
  • interests - too rare
  • portfolio - too rare?
    • XPN seems like it would be a logical addition. --Jon Williams 11:55, 25 Jan 2007 (PST)
  • projects - too rare?
  • exhibitions - too rare?
Additional Metadata
  • It would be helpful to have the following fields associated with skills: Robert Merrill 07:41, 12 Feb 2006 (PST)
    • Skill-Level: Beginner, Advanced, Expert
    • Years of experience with skill (numeric)
    • Last used: either value of "currently used" or years since last-used
  • Unfortunately none of these showed up with sufficient frequency (if at all) in the resumes found published in the wild, and based upon the principle of simplicity and 80/20, it makes sense to simply omit these from at least the first version of an hResume microformat. - Tantek
  • Would it make sense to use hReview here? Since this is in a sense a review of a persons skills. --Ajaswa 18:35, 16 Jun 2007 (PDT)

Other Brainstorming

The following is the result of some brainstorming between some guys from Technorati and SimplyHired.

Minimal Set

According to the SimplyHired guys, who see a lot of resumes, a typical resume consists of these sections:

  • Contact Info
  • Education
  • Work Experience
  • Skills

Optionally

Again, according to SimplyHired, these sections are less common:

  • Objective
  • interests
  • references (could be tied to a specific job)

Functional

Some people publish functional resumes, which are a somewhat inverted form of the traditional.

  • Contact
  • Work Experience
    • Company
      • Project
  • skill
    • experience (job, education, etc)

Application of current microformats

See resume-formats for a description of common résumé elements. It seems that some of these constructs could easily be represented with existing microformats.

Contact

The contact info block of a résumé could be expressed with an hcard.

Education

Educational experience could be expressed as a list of hcalendars. The rationale is that education can be viewed as a long-running event- it would be easy to reuse the vocabulary from hcalendar for describing events.

Work Experience

Just like Education, work experience could be expressed as a list of hcalendars.

Additionally, within a particular work experience, the list of job titles could be expressed as hcards. The only issue here is with having to repeat the FN for each of these hcards.

It might also be useful to extend xfn for marking up links to employers and clients.

Skills

Skills could be expressed as tags, using relTag. As with all rel-tag uses, a number of tagspaces would be appropriate.

Publications

Any publications, presentations, or other works could be represented by a citation microformat.

References

References could be expressed as a list of hcards, though web-based résumés tend to be light on using references.

In our initial brainstorming, we talked about doing references in resumes. However, after doing the resume-examples research it doesn't seem that references are published on the web very often.

endorsements

LinkedIn allows users to endorse others' resumes. This functionality could be capture with vote-links.

Like the previous, this doesn't get used on the open web much, so I (Ryan King) think it should be left out, at least initially.

Brainstorming Session 2005-11-10

Contributors

  • Tantek Çelik
  • Ryan King
  • James Levine

Photo From Brainstorming Session

87059139_88bb16e1b4.jpg

Writeup of Brainstorming Session

  • "hresume" - root class name
    • "contact" hCard - should use <address>. Can be the person who the resume is about OR the proxy/contact in the case of recruiting/hiring services
    • "objective" - block of text explaining the objective
    • "job" hCalendar vevent - for each job in the jobs section:
      • hCard for title, org, address of company, (optionally, work phone numbers, etc.). For "fn" use indirection by referencing "contact" hCard above with an object tag as explained below.
    • "education" hCalendar vevent - for each school attended in the education section:
      • hCard for the school with fn==org, address of school, (optionally, url, phone numbers, etc.).
    • "skill" rel-tag - for each skill
    • <cite> for each publication
    • rel="reference" + XFN + hCard for references. rel="reference" makes sense because you are saying this person over here is a reference for the person represented by this resume.

The lists of jobs, education, skills, references should all use XOXO.

hCard reference via object

In typical resumes, each job listed also states the job title that the person had, as well as the name of the company, often the address (or at least city/state) of the company, and other information pertaining to the company.

This is effectively an hCard for the person while they were (are) working at that job, thus it makes sense to markup all that information as an hCard.

The only catch is, rarely do such hCards for each job include the person's name, visibly. Nor do we want to encourage people to replicate their name into those hCards (thus violating DRY) in invisible span elements. Thus the following code is proposed for a field (or several) in an hCard to reference another element in the document (likely the same field(s) in another hCard) and parse that other element as if it was inline in the hCard.

<span class="vcard">
 <object data="#j" class="fn n"></object>
 <span class="org">SimplyHired</span>
 <span class="title">Microformat Brainstormer</span>
</span>

Where "j" is the id attribute value of the "fn n" element of the contact hCard at the top of the page, e.g. (shown here as a verbose hCard for purposes of illustration that the reference may be to a subtree, not just a text node):

<span class="vcard">
 <span class="fn n" id="j">
  <span class="given-name">
   James
  </span>
  <span class="family-name">
   Levine
  </span>
 </span>
</span>

This method of hCard property indirection via an object element could be generalized to apply to any/all string/text properties in hCard.

Note: the object data attribute MUST be a local ID reference. External references (which would require a consuming application to load an external resource) are currently not supported by this method.

Issue: need to check with Brian Suda to see how easy/hard it would be to add this to X2V. Given that it wasn't too difficult to add the table td "headers" attribute content indirection support, this should be just as easy.

Status: According to Brian Suda: "... it shouldn't be too difficult... you are right it is pretty similar to the AXIS HEADER ID problems."

Next Steps: Brian will try implementing it in X2V and we'll see how well it works. If it works, then we'll add it to hCard, hcard-parsing, and hReview 0.3 (as well as hResume of course). Note that the hListing proposal also has a similar requirement/concept and is currently using a notion of property inheritance from the context that it may be placed in (typically the page context). This may be an even nicer fallback from an authoring point of view, but may require more implicit parsing than can be relied upon.

Implemented:Brian Suda: i have managed to roll this into X2V pretty easy, it is only in the beta X2V code, if it proves useful and worth while then we can roll it into the production version.

Issue: These object elements end up rendering quite horribly in Safari, and display: none doesn't help. The solution is to style the objects with width: 0; height: 0;.

Strawman Outline

Here's an outline of a strawman proposal.

proposal

affiliations

Two Suggestions:

  1. class~="affiliation" + hcard -- use classname 'affiliation' + an hcard for the organization of which the user is a member
  2. a rel or rev value for membership/affiliation (this doesn't capture the name of the organization or any other information, but could be useful outside resumes)

contact info

Simple, an hcard for the person in an <address>.

education

A list of hCalendar events, one for each education experience. We can either define a mapping of the terms, or just let loose and let conventions develop naturally.

employment/professional experience

A list of hCalendar events (one for each work experience). Optionally use hCards for describing job titles, organizational units, etc. We'll likely have a bit of a problem with not wanting to repeat FN for each hCard.

skills

Most resumes analyzed in the resume-examples page had a section for skills and/or qualifications. I think this usage can be best covered by using rel-tag, and not require a specific section for these tags. Perhaps add a 'skill' classname.

publications/presentation

Defer this problem to the citation work.

summary/qualifications

@class~="summary" (like hCalendar, hReview, etc.)

Possible additions

Salary

What about including salary (aka wage, payment, earnings) using the proposed currency] microformat? - Andy Mabbett

Strawman Draft

Just some space work working the draft schema out...

Format

In General

The hResume format is based on a set of fields common to numerous resumes published today on the web. Where possible field names have been chosen and reused from preexisting microformats.

Schema

The hResume schema consists of the following:

  • hResume
    • summary. optional. text.
    • contact info. required. <address> + hCard.
    • education. optional. One or more hcalendar events with the class name 'education', with an embedded hCard indicating the job title, name of company, address of company etc.
    • experience. optional One or more hcalendar events with the class name 'experience', with an embedded hCard indicating the name of school, address of school etc.
    • skills. optional. phrases or keywords using the rel-tag microformat with the class name 'skill'.
    • affiliations. optional. the class name affiliation along with an hcard of the organization
    • publications. optional. One or more citations. Use cite tag.
    • references. optional. One or more references.

Field details

The fields of the hReview schema represent the following:

  • summary:: This optional field serves as a overview of qualifications and objectives.
  • contact:: Current contact info. The <address> with hCard.
  • education:: the class name 'education' is applied to an hcalendar event.
  • experience:: the class name 'experience' is applied to an hcalendar event. Job titles/positions should use an hCard.
  • skills:: An hResume may be tagged using the rel-tag microformat and the 'skill' class name.
  • affiliations:: The class name <code="class-name">affiliation is used along with an hcard of the organization
  • publications:: just use <cite>. When there is a citation microformat, then that can be used in combination with the cite element to further markup the components of the citation.
  • rel="reference". For references, link to the person with rel="reference" and any other XFN values that apply (e.g. "colleague", "co-worker", "friend", "kin" etc.), and use hCard to markup the name of the reference.

Notes

This section is informative.

  • ...

Examples

Summary

An example summary:

<p class="summary">
  I have 10 years experience with all Web 2.0 technologies– I've been working with Ajax since 1996, 
  designing with pastels while others will still using tiled background images and frames...
</p>

Contact

<address class="vcard">
  <span class="fn">Pedro Sanchez</span>
  <span class="adr">
    <span class="street-address">123 Fake St.</span>
    <span class="locality">Preston</span>, <span class="region">Idaho</span> <span class="postal-code">83263</span>
  </span>
  <span>Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a></span>
  <span>Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a></span>
  <span>Phone: <span class="tel">+01.208.555.4567</span></span>
</address>

Education

<ol class="vcalendar">
  <li class="education vevent">
    <a class="url summary" href="http://example.edu/">Preston High School</a>
    (<abbr class="dtstart" title="1995-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)
  </li>
  ...

Experience

Basic

A basic experience event:

<ol class="vcalendar">
  <li class="experience vevent">
    <span class="summary">President</span>,
    <span class="location">Preston High School</span>,
    <abbr class="dtstart" title="2004-09-01">May 2005</abbr> - <abbr title="2005-05-25">present</abbr>
  </li>
  ...

Job Titles

To express multiple job titles/positions in the same experience event you should use hCards. hcard requires the fn ("formatted name") field, but it isn't reasonable to repeat your name for every job title you mark up in hResume. So, you may use an <object> with a reference to the fn somewhere else on the page.

For example, this hCard refers to another hCard

<span class="vcard">
  <object data="#j" class="fn n"></object>
  <span class="org">Preston High School</span>
  <span class="title">Class President</span>
</span>

Where "j" is the id attribute value of the "fn n" element of the contact hCard at the top of the page, e.g. (shown here as a verbose hCard for purposes of illustration that the reference may be to a subtree, not just a text node):

<address class="vcard">
  <span class="fn n" id="j">
    <span class="given-name">Pedro</span>
    <span class="family-name">Sanchez</span>
  </span>
</address>

This method of hCard property indirection via an object element could be generalized to apply to any/all string/text properties in hCard. Note: the object data attribute MUST be a local ID reference. External references (which would require a consuming application to load an external resource) are currently not supported by this method.

Skills

Some sample skills tags:

I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a> 
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.

Affiliations

<span class="affiliation vcard"><span class="fn org">National Honor Society</span></span>

Publications

<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.

Adding qualifications, subject and grades to education

I have been marking up a number of CVs with hResume and believe that there is a major piece missing from the specification. Most CVs have some sort of educational history, which will contain information such as institution name, qualifications and grades. Some real life examples:

  • 1987-1990, University of Bristol BSc (Hons) Degree in Computer Science
  • Mathematics Higher B
  • 1992: A levels Mathematics, Further Mathematics, Physics, Chemistry (all grade A)
  • 5 O levels (Grades A-C)
  • In 1999 I graduated with honours from a 4 year Hons BSc in Artificial Intelligence and Computer Science at the University of Edinburgh, Scotland. This degree is designed to give the student a firm grounding in the subjects of Artificial Intelligence and Computer Science while demonstrating how the two are related and how each can be used to supplement the other.

Currently the education element of hResume is based on hCalendar which is great at dealing with the time elements of education item such as start date, end date and duration. It has also been expanded with an embedded hCard to help indicate the institution name, address etc.

But this combination of hCalendar and hCard only addresses half of the common semantic information communicated about education history. How do we mark-up qualifications, subjects and grades? If I was to design a specification based on real world use and current schemas like HR-XML it would look something like this:

Proposed new schema for education item

  • Education
    • Institution (hCard)
    • dtstart
    • dtend
    • duration
    • summary
    • qualification (onezero or more)
      • name
      • subject
      • grade
      • description
      • number

Field details

The fields of the new education item schema represent the following:

  • Institution: (hCard) The contact info of the educational institution
  • dtstart: The date the individauls education start at the institution
  • dtend: The date the individauls education ended at the institution
  • duration: The duartion of the education
  • summary: A summary of the the education
  • qualification (one or more)
    • name: The name of the qualification i.e. BA(Hons)
    • subject: The main subject of the qualification i.e. Computer Science
    • grade: The grade given i.e. 2:1
    • description: A description of the qualification
    • number: Used to define a group of qualifications.

Glenn Jones 5 Aug 2008

  • +1 TobyInk : the current hCard+hCalendar event model kinda works for experiences (though if they're intermingled it can be a bit messy), but is insufficient for education. The model above is much simpler to parse and also much easier to author. I'd suggest making "qualification" a "zero or more" property though — some courses are attended simply for education, with no bit of paper at the end. I'd also suggest that "experience" should be similarly rethought.

Examples in the wild

Implementations

References

Normative

Related Pages

Research

Previously

hResume is the classic microformats predecessor for h-resume. Work on hResume is documented at the following for historical purposes. Much of the general discussion and research likely still applies.

The hResume 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.