Generate structured CV from standardly formatted json data structure

[DanNBullock]

Suggestion overview

While the current CV format/Page is certainly sufficient and gets the job done, it may be possible to improve the structure and aesthetics of the page while also streamlining the process of updating this page. Specifically, there may be value in developing a standardized format for CVs (i.e., json based) and an associated CV page style and formatting script.

As an example of what can be achieved with this, folks can take a look at what I've tinkered up for my CV:

Foreseen Task Breakdown and Challenges

I fully recognize that it is highly unlikely that a single standard would meet all needs. I tried to find an existing CV/resume format or standard that could fulfill this role (e.g., something that works with USAjobs.gov) but nothing seemed viable. To that end I developed what I felt was a fairly generalized and extensible json framework (example here) and a corresponding html template to make use of this content.

Although the examples I provided may prove to be of use as a starting point, I don't expect them to be what the majority of the community here needs. To that end, I suspect there will need to be some coordinated process of developing an acceptable generalized and extensible framework for both the data structure and the css/html layout.

Admittedly, the use of a intermediary json data structure may not be to many user's liking and so it may be warranted to have a failover condition that presents the conventionally produced and structured markdown-based CV in the event that no appropriate json CV data structure is found.

Closing

If I can be of assistance with this process just let me know--I've greatly appreciated the resource that this repo/page has provided and I would be quite pleased if I could contribute back.

[rjzupkoii]

@DanNBullock we recently got a PR from @chenyuan99 with a JSON formatted data structure, does this work?

[DanNBullock]

Looking at @chenyuan99 's code I feel like it's a good starting point, but it kind of makes a number of assumptions about the format of the markdown CV document (e.g., here and more generally in the subsection parsing functions themselves).

In a general sense, I feel that something like this is a good first step, insofar as introducing the functionality of digesting the markdown CV into a json intermediary is concerned. Initially I was worried that this would break compatibility or introduce some extreme brittleness, but it appears that chenyuan99 has adopted a good prototyping approach by having a separate (potentially unlisted?) page for the json-based cv content.

In short: it doesn't appear to break any backwards-compatibility or introduce any meaningful brittleness (assuming that the json cv production script fails non-disruptively) so, it seems like a good starting point for exploring this functionality/capability.

Next steps:

There are a couple of capabilities / functionalities I would think are worth exploring next...

1. Alternative json source file behavior: In the event that a user prefers to directly generate their json-based cv (rather than have it digested)--for example if they natively generate their cv in a json format--it could be worthwhile to have the script check for a provided (as opposed to generated) json file (named something like "manual-json-cv" for example) and default to that if it is present.
2. Stand-alone standard usage / referencing: I think some modularization of the parsing python script could be in order. The script, as it is currently written, presumes a number of things about the standard fields that are pertinent to each of the relevant subsections. In the long run, I'm not sure that's something that one would want baked in to the parsing script. Yes, I recognize that the regex-parsing is going to have to make some assumptions and is going to have to pipe that content to some field of the data structure, however I don't know that the script needs to be populating place-holder fields here. Instead, I think a more robust approach would be to develop some standardized schemas for the subsections (like the linkML standard, but perhaps not that intensive), have those stored elsewhere and have them serve as the default template from which the resultant json is composed.
3. Styles & Themes: I'm not sure how this ought to be implemented, but the existence of this json standard opens the door to a potential proliferation of themes and layouts for the cv page. chenyan99's example is one of these, as is my current framework. Over time there may be a number of such alternatives which could be mixed and matched, however some planning will need to be done for how these ought to be stored in the academicpages directory structure and how the user will choose and compose the options.
4. User preference expression: relatedly, there may come a point where users may want more granular control of how the page is constructed. For example, I've opted to have skills be associated with particular work experiences, but chenyaun99's version has a compiled list (I did this as well in a previous version of my page). This behavior could be switched between these options with the right interface components. Sure, a user could go into the css/html page itself and change things around, but perhaps there are other ways to enable this.

[rjzupkoii]

@DanNBullock That's some good feedback but my concern is that a lot of this strikes me as a separate project compared to Academic Pages (partially since, other than the occasional PR from others, I'm the only one supporting Academic Pages) and there's still a bit of work needed to get PR #2901 well integrated into Academic Pages.

So from my perspective the core functionality is there since there is now a way of converting JSON into a CV page; however, I also recognize that there's a lot of situations that are not included in the JSON that will need to be added over time. So I'm actually considering spinning the JSON parser part into a separate repository - although realistically the odds of it having a large enough network effect to catch on are pretty slim. However, I also don't want this project to lose sight of the fact that ultimately it's intended to a lightweight template that can be used for academic and project based websites.

[DanNBullock]

Seems reasonable to me

[chenyuan99]

The way that i apprach this feature is treating the current markdown and yaml files as the "record of truth", the json data would be kind of an tentative state, parsed from the ground truth but also allow user to add/edit. the html would be the expression of the json addon to that. so if user want to use their own html template, they can simply replace it. also if you want, you can contribute your cv html template to the upstream.