Ability to tag resumes for varying jobs

[KOLANICH]

@chrisdotcode said

I think jsonresume, while having 'resume' in the title, should also process CVs. In which, such things like performing, charity outreaches, etc. are notable.
I personally have my CV, and my resume, which is a proper subset of my CV that I modify for different companies, depending on the job. The CV never gets changed, and only gets added to as time goes on.

Let's discuss how to implement this. My idea is to allow adding a "tag" property to any object, which will act like a namespace. The tool must ignore objects with tags not listed in the list of tags provided through cli/config/etc when run. The default list of tags should be provided in property "tagList" of resume json file, if it is not provided, it is set to ["resume"].

P.s. the idea is bad, because it doesn't allow to create diferrent versions of fields for different namespaces. Here is the another one. We could use prefixes for properties, but it wiould not allow to describe schema. We could allow to create objects with separate jsonresume documents (in this case there would be no default namespace, every namespace must be defined explicitly, and default ns list would be ["default","resume"]),

{
"default":{
//jsonresume doc
},
"resume":{
//jsonresume doc
},
"cv":{
//jsonresume doc
}
}

but it is a bit ugly.

[stp-ip]

My idea was to use labels. The best solution would be that each item has a label object, but that would be too complex. Therefore I moved to labels being available on sections and subsections to make it possible to label single events, activities, achievements.

The labels can then be used as in the previous version as public labels "passion" or as private labels "_recruiter" for filtering.

The actual filtering can be specified in the meta-data section via shown/hidden subsections: https://github.com/jsonresume/resume-schema/pull/193/files#diff-76d5ffeac090c76ed5f4c581f02f3c53R884

Not sure if public labels are actually needed and we could move the labels to hidden and non frontend usage only.
The other question is where do we use them? Ideally on every small bit of data, which is not a logical block. Aka a gender should be available to be labeled and so should a single publication, but a work.project.url should not.

I dislike the namespace bit as it seems a bit duplication and less structure could creep in.

[chrisdotcode]

All of this feels far too complex. I don't see anything wrong with having a master CV, and adjusting it per job, by using a theme catered to that job.

There's no way to tell which job will desire which particular skill(s), so making different variations for all possible cases is impossible to begin with.

I believe my current solution: a master CV.json with all of your information on it, and generating different resumes with different themes/a modified CV is the way to go.

[mudassir0909]

Maybe we can tag the resume.json? Imagine I have 3 copies of resume.json, one is a master json other is for job1 & job2

While publishing I could publish the resume as

$ resume publish #this makes the published json the master copy

you can publish other copies as follows

$ resume publish --identifier=job1 #I couldn't think of a better word for "identifier"

Now one can access this version of resume using query params as follows,
http://registry.jsonresume.org/mudassirali?identifier=job1

This also helps with the i18n of resumes, you can have your copies of resume in english, french & so on. Themes can only i18n the section headers/labels but not the resume content. With this approach you can update both

http://registry.jsonresume.org/mudassirali?identifier=lang_fr loads the resume in french

Any thoughts?

[chrisdotcode]

Beautiful.

[mudassir0909]

Also if we are feeling lucky & want to keep things DRY, we can let a copy inherit from other copies(maybe the default copy).

Imagine the default copy has all the attributes needed, child copies can only have the attributes that you wish to override.

Say I had published default copy as follows

{
  "basics": {
    "name": "Batman",
    ....
}

And I wish to publish a new copy for my personal use & wish to override only the name attribute then I could do

{
  "basics": {
    "name": "Bruce Wayne"
  }
}

I can then do

resume publish --identifier=personal --extends=default 

This would internally do _.extend(default_copy, new_copy) & create the new copy

[chrisdotcode]

I'm not opposed to that - but that's a discussion for resume-cli, not resume-schema.

I think this particular issue is resolve in the schema by adding a tag, stating what job this resume identifies.

[mudassir0909]

Agreed

[stp-ip]

So we would go the data duplication route, where each user keeps his master CV and a few job specific ones up to date, instead of having a master CV with labels/tags to identify the structure and info for each job.
I disapprove of data duplication, but I can see, that labels might be too heavy.

Inheritating stuff makes tooling much more complex and I would probably say that's too heavy in itself especially as one usually doesn't extend his master CV, but actually reduces it per job. But as already said, that's a cli discussion.

[chrisdotcode]

As stated above, labels require an entire re-write of the schema, for any (and all?) possible resume permutations.

The easiest solution is the current one: themes selectively take information from a cv.json, based on whatever job(s) that theme supports.

For example, a carpentry theme can search a CV for certain words, and only grab and render relevant entries.

As a practical example, when I was doing this myself, I removed stuff like volunteer work that tech shops wouldn't necessarily care about. It would be easy for me to write a theme omitting said information, so it would be possible for me to keep only one CV.

[stp-ip]

Labels would make userdefined hidden information possible. A complete rewrite is not needed. Just tag the things you wanna hide or tell the theme via meta-data or a cli flag to only show tag X. For example one could easily say via meta-data or cli flag show everything except "volunteer, non-tech" for example.

Having the filter logic in the theme reduces the amount of generic themes and complicates themes and doesn't make the data for a specific job available.

[chrisdotcode]

This is isomorphic to adding additional fields talked about in #41.

Ideally, there should only be one meta object, that can contain arbitrary key/value pairs, including this sort of label information, such that we wouldn't need to make the schema needlessly complex, and themes can use the meta information specified there.

For non-tech friendliness, we can even name this field "notes" or something, where it can either be a string, or a key/value pairset.

P.S.: Themes, by nature don't have to be generic, and can instead cater to specific to jobs. The data in the cv.json is generic, and the themes specialize.

[stp-ip]

The argument in #41 is mainly, if we should try to have a default view on what might be useful or if we just add the most minimal data schema possible. Standards should in my opinion cater to the 90% case and therefore sometime include more than necessary for say 40% of the others.

The meta object is a nice to have to analytics etc. I agree, that we don't have to force that into the schema, but having the ground work, aka a key value store defined is necessary.

The label information would not reside in the meta object, only filtering data (as an idea). The labels are actually inside each object and have the best connection with the data inside the schema to be more useful than duplication and even non-generic themes.

The most generic cv.json we can get is include the most data possible, without adding useless data for 90% of the users. In my opinion additional personal fields would add that value as discussed in #41 as would a label or tag system.

[chrisdotcode]

Can you give an example schema of your label suggestion(s), @stp-ip, because @KOLANICH's initial suggestion is a bit complex.

However, a single "arbitrary meta data" key/value pairset is easy to both understand and implement.

As far as adding personal fields, I'm on board with them too (it's just that we need to flesh out which ones we'll choose, that's why I've remained silent on that).

[stp-ip]

basics: {
  ...,
  labels: {"full", "tech", "non-tech"},
  additionalInfo: {
    ...,
    labels: {"europe"}
    }
  }
...
work: [{
    name: "hooters",
    ...,
    labels: {"non-tech"}
  },
  {
    name: "microsoft",
    ...,
    labels: {"tech"}
    projects [{
      name: "azure",
      ...,
      labels: {"cloud", "infrastructure"}
      }]
  }]

One could then use meta-data filter data or if we don't want such data in cv.json via cli flags.
One could then say: ... publish --include:"tech" --exclude:"cloud", europe
Or perhaps only: ... publish --include-only:"full"

As an example.

[chrisdotcode]

Oh, I see what you're saying.

Okay, so instead of labels, let's re-use the already existing interests.keywords fields , and add it to the other big sections (work, projects, events).

[stp-ip]

I dislike the meaning of keywords. They make the data they provide sound quite public. If we use tags, they are probably hidden 99% of the time. If we use labels and split it up into public and hidden ones, keywords would still fall behind with it's meaning in my opinion.

As interests always seemed more like categories as in "web development" and the keywords would be technology things such as "python", "html", "COBOL" etc. moving or using them as labels/tags seems perhaps misleading.

Only when we use labels with a split meaning "public", "_private/hidden" I would agree, that we could merge these at least to be consistent with the naming.

[stp-ip]

That being said. So many public label options could be a headache for theme creators.

[chrisdotcode]

I dislike the meaning of keywords. They make the data they provide sound quite public. If we use tags, they are probably hidden 99% of the time. If we use labels and split it up into public and hidden ones, keywords would still fall behind with it's meaning in my opinion.

This complicates things ...a lot. And not only for theme creators. The easier solution is just adding keywords to the work, project and event elements.

I don't see a point of making information private on a resume. Much less only the label fields. Additional metadata on what should be shown or not can go in the metadata fields.

@stp-ip, it seems you're most against the usage of keywords as the word we choose. But category, or any other word has pretty much the same meaning, and since keywords is already used in the schema, it makes most sense to just keep on using it.

[stp-ip]

The thing with having the data on what should be shown in the meta-data field removes the connection of categorisation and data. Labels as subressources would add the categorization within the data and make it possible to thoroughly structure the data.

To not complicate things, we could just name them tags and make them helpers for structuring the data inline.

It's only structure information and therefore it would be strange to have that public.

Ok then we keep keywords, but I think we don't need them for anything else than for interests. Work, education etc. already have achievements to push special things. Keywords would make things much more chaotic in these sections.

[chrisdotcode]

I disagree, @stp-ip.

Adding that many labels for pretty much all of the fields makes things very complicated, whereas just adding a single keywords field to each work section solves the problem, and is a lot more simple.

While achievements might list some of your notable achievements, if you worked with a particular technology you don't have a major achievement for, but still used, it can go in the keywords field.

[stp-ip]

OK let's leave the label idea for now.

I would say that keywords are not needed there. As it just clutters the resume. If you worked on a particular technology either it's an achievement or it's a skill and therefore can be added to the skills section with a keyword.

For the label issue we need some more feedback from others I think. We just circle the disagreement :P

[chrisdotcode]

@stp-ip and I have miscommunicated.

Keywords (what he calls labels) will be added to each item of work, projects, events, etc. respectively, similar to what exists already in interests.

[stp-ip]

The only thing not yet clear is to how much keywords are being added. We agree that it should be at least the sections and subsections, but could not yet agree, if it makes sense for having keywords under exams, courses and non global achievements etc.

[chrisdotcode]

I honestly would have to see an example schema of keywords in the other fields you are talking about, @stp-ip .

[stp-ip]

@chrisdotcode I try to cook something up. Where keywords would be good in my view and where we could draw the line.
In addition I will be looking at the suggestions of using the metadata part for filtering data. (used by resumes to only use parts of the data filtered via keywords + filtering information)

filtering information: keywords "science", "art", "pro-bono" should be hidden for flag "tech".

[stp-ip]

Ok instead of having tags on every little detail, I think having tags on the main attributes such as work.project, projects.project, education, info etc. should be enough.

For filtering purposes I propose to use metadata.filters. They can use keywords and define attributes to show/hide.

Filter information example:

metadata.filter = [{
  "volunteering": {
    "keywords": [
      "pro-bono"
      ],
     "attributes": [
       "work['greenpeace'].project['saving whales'].role",
     ]
  }}, {
  "social": {
    "keywords": [
      "volunteering",
      "pro-bono"
      ],
    "attributes": [
      "projects['volunteering party organization']",
      "events['demonstration 123'].talks['saving cats']"
      ]
  }}, {
  "remote": {
    "keywords": [
      "remote",
      "abroad"
    ],
    "attributes": [
      "work['buffer'].project['redesign']",
      "work['automattic']"
    ]
    }}, {
  "verbose": {
    "keywords": [
      "verbose"
      ],
    "attributes": [
      "work['buffer'].project['redesign'].url",
      "work['automattic'].url",
      "work['facebook'].url",
      "education['MIT'].exams",
      "education['pre-schooling']",
      "events['demonstration 123'].talks['saving cats'].slides",
      "events['demonstration 123'].talks['saving cats'].recordings"
      ]
    }
  }]

CLI usage example:

resume export --format=pdf --show-filter=volunteering [fileName] # shows only items referenced in selected remote filter
resume export --format=pdf --show-filter=volunteering,social [fileName] # shows only items referenced in selected remote filters
resume export --format=pdf --hide-filter=verbose [fileName] # hides items referenced in selected remote filter
resume export --format=pdf --hide-filter=volunteering,social --show-filter=remote [fileName] # shows only items referenced in selected remote filters and hides 

Why? With filtering options you have one source of truth for your data instead of various resumes for different jobs, opportunities, public website etc..
One can simply add specific filters to be able to create a field specific resume or remove verbose data. One could create job specific resumes via a job specific filter and use a reduced generic resume/filter for generic applications. In addition one could remove deeply personal information from a public resume, but still have the data available for other resumes.
Country specific resumes could be possible too.
Having the filters in the dataset is in my opinion not really mixing frontend and data, but controlling the data at the source. I would not like detailed private information be available on a webpage, which is just hidden for plain view, but available in the sourcecode.

[chrisdotcode]

Since filters are in the metadata, and metadata can contain any values, that's a perfectly acceptable solution.

[stp-ip]

@chrisdotcode I would still love to get it into the standard. Without that it would just be some hacky solution most likely not included in anything than personal scripts.

[phumke]

+1 for the metadata solution. This seems better than creating multiple top level versions of the CV.

I can see the hiring committee actually getting the resume master and then having powerful filtering tools on their end to filter out the things they don't want to see. This reduces the work on the resume creator to have to "guess" at what a particular job is most interested in.

[pke]

So whats the progress here? I came here cause I was missing tags on work and projects that I can use to flag the work and tech used in this work. Themes could easily aggregate all tags from work/project items and generate a tag cloud automatically.

I am also for a single source of truth. And I strongly favour a dead simple filter mechanism. Keywords, tags, labels I really don't have an opinion on the naming but I would not fine grain it too much down to the properties. That's what a query language like jq is there for. Similar to XML and XPath. Don't reinvent the wheel. Use some existing query language for JSON either in the metadata or pipe it with the CLI.

[stp-ip]

Within JSON resume tags are only on a few sections unfortunately.
Also the notion of tags vs keywords got mixed.
In Resumic we tried to go with keywords being user facing and thought about an additional tag method that is done via tools and therefore lives in the meta section. This keeps the overall resume data clean and readable, while enabling filtering through tagging.
The exact mechanism we haven't implemented, but I like the idea of using a more standard json query language to tag sections etc.
resumic/schema#10 (comment)
Based on these tags one could then generate specific filtered resumes.

[pke]

jq has a horrible syntax but there are alternatives ;)
Something like this: https://github.com/koajs/json-filter or more sophisticated https://github.com/nemtsov/json-mask would be a pretty good start I guess.

One could then pre-define filters in the meta object that the CLI can select from:
resume --only="c++"

But since I believe in single purpose idea of UNIX this could all not really matter for the resume CLI but handled by other programs like jq or a CLI version of json-mask.

[stp-ip]

I also like the path syntax from https://github.com/tidwall/gjson#path-syntax

[thomasdavis]

As a bunch of this issues I'm closing, I really did think about the utility of the suggestions.

tags and notes are great but most people won't bother to do that if all they want is to render their resume.

I'd suggest that if some system found utility in having tags then they should likely just run an analysis (ML) over the data and tag it themselves.