Open davidbarratt opened 2 years ago
To add to this, https://github.com/Jsonldresume exists too, and I'm currently oscillating between maintaining my resume in jsonresume or jsonldresume format. I've not dug much into the most "correct" ways to parse JSON-LD via a schema.org schmea, or JSON via a json-schema.org schema, but I'm pondering writing a converter (though there will be fields that don't map 1:1 so that could be tricky).
I understand that you have previously rejected the idea of using Schema.org's JSON-LD vocabulary.
Would you be willing to host/maintain a custom vocabulary?
This could be as simple as having a URI for
basics
ashttps://jsonresume.org/basics
. That URI doesn't need to even resolve, it just needs to be agreed upon.This would be documented in a JSON-LD context file and hosted at say: https://jsonresume.org/jsonldcontext.jsonld
Then you would add a Link to the context like so:
Doing so would provide an agreed upon machine-readable vocabulary for resume data, which seems to be the goal of this project? If folks want to map the existing properties/types to existing vocabularies, they are free to do that or they can exist in the context I suppose with http://www.w3.org/2004/02/skos/core#exactMatch or https://schema.org/sameAs (see https://www.wikidata.org/wiki/Property:P1628).
Creating your own vocabulary is basically what Wikidata did and I think it's totally fine to do that. Having a custom vocabulary is way better than no vocabulary at all.