Does the schema allow for meta or display information?

[colindean]

I have a lot of positions and a lot of volunteer work, but there are only certain ones that I'd want to show for certain aspects of my life. E.g., if I'm applying to a tech job, then I probably only want my tech jobs to show up on the resume. If I'm applying to a non-profit, then they probably only really care about my non-profit work and perhaps whatever it is I'm doing right now full-time.

What I think I'd like to do is be able to add a meta section of some kind, e.g.:

"work": [
    {
      "company": "Tech Company X",
      "position": "CEO/President",
      "startDate": "2013-12-01",
      "_meta": {
        "groups": ["tech", "current"]
      }
    },
    {
      "company": "Non-Profit Y",
      "position": "President",
      "startDate": "2012-12-01",
      "_meta": {
        "groups": ["non-profit"]
      }
    },
    {
      "company": "Non-Profit Y",
      "position": "Secretary",
      "startDate": "2011-12-01",
      "endDate": "2012-12-01",
      "_meta": {
        "groups": ["non-profit"]
      }
    },
   {
      "company": "Inconsequential Non-Profit Z",
      "position": "Inconsequential position",
      "startDate": "2010-12-01",
      "endDate": "2011-12-01",
      "_meta": {
        "groups": ["non-profit"],
        "display":"only-on-complete-history",
      }
     },
     {
      "company": "Tech Company B",
      "position": "Doer of Great Things",
      "startDate": "2011-12-01",
      "endDate": "2013-12-01",
      "_meta": {
        "groups": ["tech"]
      }
    }
     {
      "company": "Prominent Non-Profit Y",
      "position": "Doer of Great Things",
      "startDate": "2006-12-01",
      "endDate": "2009-12-01",
      "_meta": {
        "groups": ["non-profit"]
      }
    }
  ],

I think my example makes sense. Essentially, I have many aspects of my life, and I'd like for a standards-compliant way to group them. Because my grouping may be arbitrary, or have other logic, it might be nice to throw it into a _meta bucket that acts as a bit of a namespaced area.

Or this proposed solution may not be the best way to proceed in a JSON Schema fashion. In an XML resume format, I'd expect to be able to do something like <meta:groups><meta:group>tech</meta:group><meta:group>non-profit</meta:group></meta:groups>, but I don't know how best to reflect that in a JSON Schema world.

[thomasdavis]

Hey Colin, We've had a few people reach out for this idea already. My idea so far is to have maps or access control list at the bottom of your json file.

acl: {
  recruiters: {
    include: "all",
    exclude: "volunters"
  }
}

That is super rough draft but just an example of making a mapping instead of putting meta tags on the properties themselves. Not sure which is better yet.

On Sun, Aug 3, 2014 at 1:14 PM, Colin Dean notifications@github.com wrote:

I have a lot of positions and a lot of volunteer work, but there are only certain ones that I'd want to show for certain aspects of my life. E.g., if I'm applying to a tech job, then I probably only want my tech jobs to show up on the resume. If I'm applying to a non-profit, then they probably only really care about my non-profit work and perhaps whatever it is I'm doing right now full-time.

What I think I'd like to do is be able to add a meta section of some kind, e.g.:

"work": [ { "company": "Tech Company X", "position": "CEO/President", "startDate": "2013-12-01", "_meta": { "groups": ["tech", "current"] } }, { "company": "Non-Profit Y", "position": "President", "startDate": "2012-12-01", "_meta": { "groups": ["non-profit"] } }, { "company": "Non-Profit Y", "position": "Secretary", "startDate": "2011-12-01", "endDate": "2012-12-01", "_meta": { "groups": ["non-profit"] } }, { "company": "Inconsequential Non-Profit Z", "position": "Inconsequential position", "startDate": "2010-12-01", "endDate": "2011-12-01", "_meta": { "groups": ["non-profit"] } }, { "company": "Tech Company B", "position": "Doer of Great Things", "startDate": "2011-12-01", "endDate": "2013-12-01", "_meta": { "groups": ["tech"] } } { "company": "Prominent Non-Profit Y", "position": "Doer of Great Things", "startDate": "2006-12-01", "endDate": "2009-12-01", "_meta": { "groups": ["non-profit"] } } ],

I think my example makes sense. Essentially, I have many aspects of my life, and I'd like for a standards-compliant way to group them. Because my grouping may be arbitrary, or have other logic, it might be nice to throw it into a _meta bucket that acts as a bit of a namespaced area.

Or this proposed solution may not be the best way to proceed in a JSON Schema fashion. In an XML resume format, I'd expect to be able to do something like meta:groupsmeta:grouptech/meta:groupmeta:groupnon-profit/meta:group/meta:groups, but I don't know how best to reflect that in a JSON Schema world.

— Reply to this email directly or view it on GitHub https://github.com/jsonresume/resume-schema/issues/133.

Thomas Davis http://thomasdav.is

VP of Tech - Earbits - http://earbits.com Co-founder - Cdnjs - http://cdnjs.com Founder - Backbone Tutorials - http://backbonetutorials.com

[ocram]

I'd prefer your draft, @thomasdavis

[wdoekes]

Note that the OPs example problem is not tackled by the ACL example.

How would we "exclude", say, the 5th element of work[]?

[ocram]

@wdoekes The OP's example is certainly more fine-grained, but you always have to balance detail against complexity.

Of course, you could extend @thomasdavis's example so that it can define paths in the JSON or may list the index of a child if the parent is an array. But then, the question is really if the OP's example isn't becoming simpler.

[DonDebonair]

I think 'ACL' gives a false sense of security. Anyone who has access to your jsonresume, has access to all data on it. The only thing the ACL does, is restrict output of the tools that generate actual representations of the resumes. I think another name would be better, but I have no idea yet what that name should be.

[ocram]

@DandyDev Good point, and another reason why the OP's example may be a better solution after all.

[DonDebonair]

For that reason, I'm indeed in favor of the OP's solution, or something like that. We could also call them "tags" instead of "groups", and tools can do whatever they like with them :)

[erming]

If anyone could explain to me:

When would this be feature be used? And by what tool? And how is this not already solved by using two different exports of your resume?

[ocram]

@erming The OP wants to have one version of their CV and generate varying exports without touching the CV's JSON source again. Otherwise, you would have to go through your CV and delete sections that you don't want to appear in your current export.

[DonDebonair]

Exactly. It keeps you from having to maintain two resumes.

[thomasdavis]

So I've been brainstorming an encryption layer, where each acl key has a pass phrase. Something along those lines...

On Mon, Aug 4, 2014 at 11:48 PM, Daan Debie notifications@github.com wrote:

Exactly. It keeps you from having to maintain two resumes.

— Reply to this email directly or view it on GitHub https://github.com/jsonresume/resume-schema/issues/133#issuecomment-51061809 .

Thomas Davis http://thomasdav.is

VP of Tech - Earbits - http://earbits.com Co-founder - Cdnjs - http://cdnjs.com Founder - Backbone Tutorials - http://backbonetutorials.com

[DonDebonair]

But what use is that? A Resume is public information by definition. No need to encrypt that :) If anything, you could cryptographically sign it, but I think that is overengineering IMHO.

[thomasdavis]

A resume is not necessarily public, we already have pass phrase encrypted resume support on the registry.

On Mon, Aug 4, 2014 at 11:55 PM, Daan Debie notifications@github.com wrote:

But what use is that? A Resume is public information by definition. No need to encrypt that :) If anything, you could cryptographically sign it, but I think that is overengineering IMHO.

— Reply to this email directly or view it on GitHub https://github.com/jsonresume/resume-schema/issues/133#issuecomment-51062609 .

Thomas Davis http://thomasdav.is

VP of Tech - Earbits - http://earbits.com Co-founder - Cdnjs - http://cdnjs.com Founder - Backbone Tutorials - http://backbonetutorials.com

[erming]

@mwaclawek and @DandyDev: Yeah, I get that. Nice to keep one file instead of two.

But here's why I don't like this feature:

1. The schema becomes cluttered with more features, this time with a more advanced/niche one
2. Tools must be updated, and future tools must implement this
3. It's presentation only. This featured is only actually useful when exported by a tool
4. The feature is probably only useful for a minority of the users
5. You still have to manually export these different versions of your resume
6. The "issue" this feature would solve, actually have a solution today

And don't get me wrong, I understand the reason behind this feature. But in practice, I think that the "KISS"-approach is a better feature to have.

[DonDebonair]

@thomasdavis Is it pass phrase restricted or pass phrase encrypted?

In any case, I think it's the job of the tooling to deal with encryption if necessary. It should not be part of the jsonresume spec. And @erming has some valid points not to include tags/groups at all, and I'm inclined to agree with him there.

[thomasdavis]

Yeah, definitely keep it in tooling. But not a bad place to discuss implementation in the meantime

On Tue, Aug 5, 2014 at 12:08 AM, Daan Debie notifications@github.com wrote:

@thomasdavis https://github.com/thomasdavis Is it pass phrase restricted or pass phrase encrypted?

In any case, I think it's the job of the tooling to deal with encryption if necessary. It should not be part of the jsonresume spec. And @erming https://github.com/erming has some valid points not to include tags/groups at all, and I'm inclined to agree with him there.

— Reply to this email directly or view it on GitHub https://github.com/jsonresume/resume-schema/issues/133#issuecomment-51064356 .

Thomas Davis http://thomasdav.is

VP of Tech - Earbits - http://earbits.com Co-founder - Cdnjs - http://cdnjs.com Founder - Backbone Tutorials - http://backbonetutorials.com

[wdoekes]

Pointing to #35. It describes a similar problem, but for a different purpose.

For certain solutions (for starters, allowing blocks to be reused by multiple languages) you could have a workaround for the OPs problem: create a bogus en_TECH and a en_NONPROFIT language to export two different versions of the same container-resume.

Of course I'm not advocating that we create workarounds at the design stage. But we might relax the purpose of #35 to allow both features to be possible...

[ocram]

@erming 100% agreed! Personally, I would not add this feature. Adding ACLs and an encryption layer, defining group access for single sections, and still not having a solution for the OP's original example (which needs more fine-grained controls) -- this is definitely not KISS.

I'm sure that, for the minority of users that need this, simply managing two versions of a resume.json is much easier.

[colindean]

Wow, this got a whole lot more attention than I thought it would :+1:

While having ACLs on the document itself would be nice, that's not really what I desire here.

My motivation, my core objective, is to convey that there are multiple aspects of my professional life by grouping jobs together using some kind of common label.

My proposed solution is to add a _meta section where metadata not necessarily needed for display are associated to an object in the schema. The user is free to put whatever they'd want in _meta. If it's determined by the JSON Resume standards folks that a lot of people are putting something into _meta that might belong outside of it, then a discussion about standardizing that thing can be held.

I realize that not everyone has a resume that could be as complex as mine can be, which is why I want the freedom of an open area of the schema that maybe only I care about, so that I can use my resume.json on tools that support the standard while building my own tools that respect certain fields in the _meta section. If other tools end up supporting certain _meta keys, great. If not, well then, I can at least use my resume.json wherever and have a tool that lets me do something like resume generate pdf --exclude work/_meta/groups~=non-profit tech-resume.pdf and just script the build process.

Discussion about ACLs, encryption, i18n, etc. should be reticked if issues about those don't already exist.

@erming:

The "issue" this feature would solve, actually have a solution today

What is the recommended method that already exists to address this use case?

[colindean]

Another consideration I had today was using this for priority assignment and other metadata on fields that normally just have a string value. Those fields can be a string OR be an object with a _meta.

E.g.

{
      "company": "Prominent Non-Profit Y",
      "position": "Doer of Great Things",
      "startDate": "2006-12-01",
      "endDate": "2009-12-01",
      "highlights": [
        "Did something great",
        {
          "value":"Did something else great, but less important",
          "_meta": {
            "priority": 10
          }
        }
     ],
      "_meta": {
        "groups": ["non-profit"]
      }
    }

But I'm not sold on that idea, and it's probably worth discussing in another issue thread if the idea of _meta in general is acceptable.

[ocram]

@colindean If that's really all you want, then just start using your custom _meta attributes today! @thomasdavis has recently changed additionalProperties to true for all levels but the root. This means you can add any custom attributes that you want and still have a valid JSON Resume. The official tools will just ignore these attributes and your own tools can make use of them.

[colindean]

Excellent. That addresses the short term solution.

Now, perhaps there can be some extended discussion on if groups or aspects should be added as an object-level key to work and any other top-level items...

I dislike tags, because that lends itself to meta-tagging, e.g.

"tags":["json","though-leadering","aspect-tech"]

Still feels more appropriate for the _meta section...

[mchelen]

Needing different resumes for different job applications is a frequent use-case, so any way to accomplish that from 1 source .json would be a great feature.

[stp-ip]

I would say the easiest way would be to use labels. They are already in use with some other parts. One could easily define that there can be hidden labels such as "_hidden_label". This would not introduce a new idea, but enable public labels and hidden ones for more fine grained control. what the specific tools make out of that, should not be a data storage design discussion as far as my opinion goes.

[olivif]

+1 for having one json master and being able to export different versions based on metadata

So I take it this is possible today? Could someone please summarize the possible ways to achieve this?

[stp-ip]

Not possible today, but hopefully possible with the introduction of more keywords and some metadata info. Still being discussed in how many areas keywords are added and what the format for metadata for hiding and showing based on different areas will be.

[stp-ip]

I think we agreed on having meta data within a metadata section described here: #204.

This could be used for tagging, export rules and display information.

Closing for now. If one disagrees about the closing of this issues, please reopen.

[marc-bouvier]

I think a way to do today might be to have a main resume.json that somehow includes some custom metadata.

We can "fork" several new json resumes by applying some filtering based on those metadata from the resume.json file. I believe this kind of filtering can be done in a few lines with tools like jq.

Then, we may publish (publicly of privately) both "forked" resume.json files. Then, we can generate some html for both of them.

flowchart TD

    resume.json["resume.json (single source of truth)"]
    resume.json-- transform with some script--> volunteer/resume.json
    volunteer/resume.json -- generate --> volunteer/resume.html

    subgraph public [Public repository]
        volunteer/resume.json
        volunteer/resume.html
    end

    resume.json -- transform with some script --> professional/resume.json
    professional/resume.json -- generate --> professional/resume.html

    subgraph private [Private repository]
        professional/resume.json
        professional/resume.html
    end   

Edit: It seems to have already been done by someone.

• see https://github.com/jsonresume/resume-schema/issues/35#issuecomment-411894821
• the implementation https://gist.github.com/MarcoIeni/685292e779a61faf01f28972ff80d40f