Re: Proposal: General Workflow and Filename Extension [via CV 2.0 - Global Resume Community Group]

Hi Sarven,

thanks for your input! I'll try to answer every question/comment on
important points from my point of research.

-------------------------------------------------
advantages of the initial proposal?
-------------------------------------------------
(-) less convoluted
(-) input data once, output in several formats
(-) bulk import by recruiters possible, therefore enhancing filtering
options and then visualization options in bulk
(-) manually writeable (it's easy to write/correct the tags yourself when
you just see a list whereas using any of the existing formats requires
additional knowledge non-tech-savvy users just don't have and don't want or
need to learn
(-) legible without conversion

Using schema.org directly (when I started researching resumes this was my
first approach) would mean we end up with an HTML file that is
unnecessarily big and convoluted. Here is an example of only very basic
personal data based on the Person type:

<div itemscope itemtype="http://schema.org/Person">
<a itemprop="url" href="https://www.w3.org/community/cv2/"><div
itemprop="name"><strong>Scrooge McDuck</strong></div>
</a>
<div itemscope itemtype="http://schema.org/Organization"><span
itemprop="name">CV 2.0 Community Group</span></div><div
itemprop="jobtitle">Participant</div>
<div itemprop="description">some description</div>
<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress
">
<div itemprop="streetAddress">W3C Headquarters</div>
<div>P.O. Box: <span itemprop="postOfficeBoxNumber">1337</div>
<div><span itemprop="addressLocality">London</span>, <span
itemprop="addressRegion">London</span></div><div
itemprop="postalCode">1111</div>
<div itemprop="addressCountry">UK</div>
</div>
<div itemprop="email">public-cv2@w3.org</div>
<div itemprop="telephone">0123-3456-789</div>
<div><meta itemprop="birthDate" content="2015-08-10">DOB: 08/10/2015</div>
</div>

Nobody wants to read that and it is easy to make mistakes. Just creating an
authoring tool like schema creator is ok, but does not seem like it needs a
whole W3C group. We can of course still work on it, I am not opposed to
anything you wrote in your e-mail and I think your points make a lot of
sense. I did not favour a new file extension in the beginning either but I
could not think around a better solution that encompasses all benefits. I
would be glad if you could reply to this e-mail again with your thoughts
and maybe the others have something to say as well?

--------------------------------------------------------------------------------------------------
problems solved that can't be accomplished using existing formats?
--------------------------------------------------------------------------------------------------
Existing formats that create semantic data are mostly microformats and
schema.org. The CV 2.0 is not only about semantics, though. It is above all
about a new form of resume that incorporates visualizations which can
improve information processing in the long run. The semantics are mostly
for filtering and automation purposes. schema.org cannot be properly used
in SVG and we want something that enables people to have an easier time.
Nowadays a lot of companies require you to fill out a form - every time you
have a mostly badly programmed form to fill out so the company has an
easier time filtering your data. This is not ideal. The problem we solve is
that we create a complete approach to the next-generation CV2 and following
up on it we need to make it popular and known. We do not really care
whether John Doe has created a CV website using schema.org. We care about
applicants who have to fill in their data in 20 separate forms and then
still attach their own CV and we care about recruiters having more quality
time finding the right person by making all CVs appear the way the
recruiter wants. The applicant could for example have a .cv2 file and then
export to different templates for each job and if the information in the
SVG is correct (according to our specification) the recruiter can use this
SVG to 1. see how the applicant designed it but most of all they could 2.
choose their own preferred visualization for hundreds of CVs which makes it
much easier to process lots of data.

--------------------------------------
documented & quantified?
--------------------------------------
I am not aware of any research that has quantified whether it is better to
create a file format or build upon and work around something existing for a
specific case.

-------------------------------------------------
back to source format for updates
-------------------------------------------------
You need to do that anyway - if you have a CV now, you need to go back and
update that with every new information you have. Except now I have a base
.HTML file that I export into PDF and if I want the visual option then I
have to update both my .html, then export it to .pdf, and at the same time
keep track of my updates in my .svg and all the profiles I have in various
companies I applied for. The latter we cannot solve but we can solve the
hassle of having to go back to several formats and update those. Instead we
could update one .cv2 and use an open source authoring tool to convert it
into several formats at once. This is the whole reason to have a .cv2 from
my point of view. Keep in mind I do NOT try to force a new file format -
quite the contrary. I know it means it needs more maintenance for us as a
group and it needs a wide adoption before it takes off - but if you
consider that most people have never even heard of microformats or
schema.org, I think we are quite capable of balancing those costs. For
adoption purposes, it is much easier for a company to say "oh hey, send us
your .cv2 file" than "send us an archive that includes everything and is
semantically correct".

--------------------------------------------------
what content would the .cv2 have?
--------------------------------------------------
First, we would work on tags. Tags that are close to schema.org types,
except that we use the properties as tags and cut out all the additional
bulk. Instead of the above schema.org-injected HTML we would have
<person>
  <name>Scrooge McDuck
  <streetAddress>W3C Headquarters

<organization>
  <name>CV 2.0 Community Group
  <jobtitle>Participant
  <description>


<div>P.O. Box: <span itemprop="">1337</div>
<div><span itemprop="addressLocality">London</span>, <span
itemprop="addressRegion">London</span></div><div
itemprop="postalCode">1111</div>
<div itemprop="addressCountry">UK</div>
</div>
<div itemprop="email">public-cv2@w3.org</div>
<div itemprop="telephone">0123-3456-789</div>
<div><meta itemprop="birthDate" content="2015-08-10">DOB: 08/10/2015</div>
</div>



Now to your suggestions:
1. A CV/Resume vocabulary extension for schema.org (or at least RDF based).
2. Authoring tools to construct infovis-like resumes using
HTML+RDFa+SVG+CSS+JS.

ad 1. I very much agree with the schema.org extension suggestion and would
like to post this as a new proposal so that we can start a decision process
again. I don't think it contradicts the initial proposal in any way and I'd
like to work on the schema.org extension in addition to that.
ad 2. Authoring tools and snippets are the plan once we agree on the basis
of our work. In my opinion focusing on HTML+RDFa+SVG+CSS+JS takes away a
lot of options and does not do anything else than creating yet another
template engine. It is not a problem to do that but then you'd have to send
your CV to the recruiter in an archive to include all the images and THAT
creates complexity. The idea is that recruiters request a .cv2 and can then
use a tool to display that .cv2 in their own visualization rather than
using the applicant's. The export into SVG, HTML, or other formats is for
the benefit of the applicant so they can output several formats without
having to input the same data several times. I did not see any other way
than creating a new text format.




On Sun, Aug 23, 2015 at 4:41 PM, Sarven Capadisli <info@csarven.ca> wrote:

> -1
>
> There are high costs associated to taking a yet-another-format route.
>
> What are the advantages to doing so to the alternatives? What problems is
> the new format solving which can't be accomplished using existing formats
> and available toolchain? Is any of this documented or can be quantified?
>
> Having the source format different than the target format also requires
> one one to go back to the source format for all updates. One would have to
> essentially deal with (e.g., publish, convert/export..) multiple states and
> files along the way.
>
> Is there a clear mapping from the source to the target(s), i.e., is all
> the content, presentation, and behavioural level information expected to be
> outlined in the CV2 format and then converted to the SVG and so on? What
> tools are available or expected to be created from this?
>
> Taking the proposed CV2 text format is too complex and will face severe
> challenges for adoption in my opinion.
>
> I strongly suggest to work with HTML+RDFa+SVG+CSS+JS for the primary
> authoring toolbox. If SVG is the desired "view" for it, work on authoring
> tools to achieve that better.
>
> From my POV, I think what this CG should focus on:
>
> * A CV/Resume vocabulary extension for schema.org (or at least RDF based).
> * Authoring tools to construct infovis-like resumes using
> HTML+RDFa+SVG+CSS+JS.
>
> Just my two cents.
>
> -Sarven
> http://csarven.ca/#i
>
>