- From: Sarven Capadisli <info@csarven.ca>
- Date: Mon, 24 Aug 2015 14:15:42 +0200
- To: public-cv2@w3.org
On 2015-08-24 04:23, Sanja Bonic wrote: > 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 <http://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 <mailto: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 <http://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 <http://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 > <http://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 <http://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 > <http://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 <mailto: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 > <http://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 <http://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 > <http://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. What you propose in something along the lines of .cv2 is not "text" per se, but XML (i.e., a tree structure for CVs). It requires an XML Schema and some mappings to HTML, RDF, or HTML+RDFa if that's to be employed later. It is not really "human-readable" and actually requires additional layers/tools to make it so. HTML+RDFa is machine-processable (i.e., a graph structure for CVa) and can already be viewed out of the box in a web browser. The point is that, people don't want to code to manage their data, even if it seems dead obvious. We create interfaces to help with that. XML and what it entails will be far more costly in the data pipeline than HTML+RDFa. The graph representation in the HTML+RDFa is disjoint to its presentation, i.e., you can have any CV e.g., http://csarven.ca/cv and process the underlying data as you want to. -Sarven http://csarven.ca/#i
Received on Monday, 24 August 2015 12:16:23 UTC