Extending JSON Resume for Company Specific Data

[mboudreau]

Hey everyone,

We're in the process of using JSON Resume for out base standard data model for our web application. It's a great way to reuse a lot of nifty tools and themes out there, while keeping the documentation a lot easier before of the schema. However, we do have more data than is currently possible within json schema that is specific for our company.

We are going to create our own schema that enhances JSON Schema. The point would be that JSON schema tools can still be used, while we have extra data points in there for our own purposes.

What would be the proposed way to move forward for us? Since I don't want to impede on what could be the future of JSON Schema, I wouldn't want to create a root property that might be used in the future of the schema, breaking our compatibility. Could it be as simple as having an 'extra' property at the root level, which then adds custom properties under that? Would adding custom extendibility be a feature of the schema moving forward? I'd be happy if this was the case.

Either way, I would like to get opinions on what would be the best way to move forward. Thanks.

[stp-ip]

First we have to differentiate between actual data and meta data. For meta data, such as categorization, filtering etc. the meta section is proposed. For additional data, there was discussion about a custom data section, which was at least for now declined as we wanted to make it harder to break out of the standard. So instead of breaking out of the standard, discussion would flow upstream and the schema could progress.

I definitely see the idea behind it, but I think that a stricter standard forces the schema to progress faster.

If you have a specific use case, please provide it so we can evaluate the situation further.

[mboudreau]

Our use is that we have a recruit software product and would like to use
JSON resume as our data standard. Every candidate in the system is a
resume in itself, but there's other data that we need to add to the model
for it to work within our system, like an ID, flags that the recruiter
might of added, talent pools they've been added to, applications they've
submitted, etc.

I know a lot of this is outside the scope of the schema, but I'm not asking
for you to make this available for the schema, I'm asking what's the best
way to proceed to add these extra bits of information? Should I just add
it to the root model or should they be under a particular 'custom'
property? The point is that the model is just adding extra data and that
it should still comply to the schema standard.

On Thu, Mar 10, 2016 at 10:23 PM Michael Grosser notifications@github.com
wrote:

First we have to differentiate between actual data and meta data. For meta
data, such as categorization, filtering etc. the meta section is
proposed. For additional data, there was discussion about a custom data
section, which was at least for now declined as we wanted to make it harder
to break out of the standard. So instead of breaking out of the standard,
discussion would flow upstream and the schema could progress.

I definitely see the idea behind it, but I think that a stricter standard
forces the schema to progress faster.

If you have a specific use case, please provide it so we can evaluate the
situation further.

—
Reply to this email directly or view it on GitHub
#231 (comment)
.

[stp-ip]

So this data is not data relevant for the CV/Resume itself. It's not about the data of the user, but data added by your systems to add meta data to the specific user, such as talent pools, userID, recruiter flags.

As far as I can see this should be possible with v1 and the proposed meta section.

The proposal is available here: #204
In short you could use it like this:
Assuming your software is called: AwesomeCV
meta.awesomecv.ID
meta.awesomecv.flags (array or what makes sense for you)
meta.awesomecv.pools

This data section is available for data added in addition to the resume data, mostly inserted by tools and scripts and not the user itself. Mixing it into the schema itself would be the wrong approach in my opinion.

[olivif]

@mboudreau great to see interest in JSON resume!

I agree with @stp-ip, the current proposed solution for your requirements is to use the meta field where you can insert pretty much anything that is custom to your scenario. While I also agree that making this info explicit in the schema is the wrong approach, I also want us to think about the fact that we are trying to build a standard and we should make it easy for recruitment companies to use us as the format. This might be extra tooling or some schema addons, but just putting it out there for us to think about 😄

What I would also add is that as you start transitioning to JSON resume, it would be very valuable for us to get your input on the existing schema and any ideas for improvement.

[mboudreau]

Great, thanks everyone. After talking to the team, we've decided to add all extra data under the 'meta' property. One question that I have however, when is version 1 going to be released?

My team was also curious about how do we decipher between schema versions (v0 vs v1 vs v2) and how we can tackle that in the future. Maybe have the version specified somewhere?

[stp-ip]

@mboudreau v1 is currently in the pre-implementation phase. So you and your team could still get valuable suggestions into the various schema discussions.
It's hard to say the exact time for v1. It could still be 2 months till we have a beta version, which might already be usable for you.
The version will be noted in the schema from v1 onward. Currently it would look like: meta.basics.version.
For an overview of the v1 sections see #227.

[chrisdotcode]

@mboudreau said:

Great, thanks everyone.

Sounds good, guys.