Schema.org Vocabulary

[smizell]

This may have been suggested already, but any thoughts on using Schema.org vocabulary?

http://schema.org/docs/full.html

[bollwyvl]

👍
schema.org is probably the best set of terms to use for publishing linked data that will integrate into the rest of the web's data: there are a lot of ontologies out there, but this one already has large-scale, in-the-wild implementations by major players (MS, Google), and would give the best ROI on search engines, mail integration, etc.

The big challenge is that a lot of schema.org, and linked data in general, is about giving and then referring to Things by their URIs (or in JSON-LD parlance, @ids). You'd get one for free (the user's http://registry.jsonresume.org/richardhendriks), but the rest are a little more tenuous: it would be hard for a search engine to dereference Pied Piper, while http://piedpiper.com is much stronger... this might be an issue for another day, but this is

There are already strong nouns for a lot of the concepts involved:

• Person
• OrganizationRole
• Organization
• CreativeWork
• Review

Perhaps the easiest way to get started would be to have registry serve a JSON-LD context, out-of-band, for the existing spec, when requested:

GET /richardhendriks.jsonld HTTP/1.1
Host: registry.jsonresume.org
Accept: application/ld+json,application/json,*/*;q=0.1

====================================

HTTP/1.1 200 OK
...
Content-Type: application/json
Link: <http://registry.jsonresume.org>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"

Some real gotchas, though:

• bio complicates things. If the URI of the document is http://registry.jsonresume.org/richardhendriks, all of the properties of the document should be about that URI... these are not properties of the CV itself.
• the {<arbitrary important datum>: <important thing>} pattern is pretty opaque to JSON-LD: this is part of the reason that a a truly useful, graph-like piece of a JavaScript package.json, dependencies cannot be easily understood (yet) by JSON-LD, as it maps to a much more complicated set of relationships.

Here is an example of how many of the terms in the current spec (except for the bio thing) could be mapped into schema.org terms:

{
  "@context": {
    "sdo": "http://schema.org/",
    "title": "sdo:name",
    "firstName": "sdo:givenName",
    "lastName": "sdo:familyName",
    "email": {
      "@container": "@index",
      "@id": "sdo:email"
    },
    "phone": {
      "@container": "@index",
      "@id": "sdo:telephone"
    },
    "summary": "sdo:description",
    "website": "sdo:url",
    "websites": {
      "@container": "@index",
      "@id": "sdo:url"
    },
    "position": "sdo:namedPosition",
    "startDate": "sdo:startDate",
    "endDate": "sdo:endDate",
    "location": {
      "@reverse": "sdo:homeLocation"
    },
    "work": {
      "@reverse": "sdo:member"
    },
    "awards": {
      "@reverse": "sdo:winner"
    },
    "publications": {
      "@reverse": "sdo:contributor"
    },
    "references": {
      "@reverse": "sdo:reviewedBy"
    }
  }
}

[smizell]

Great comment and reference to JSON-LD! Thanks for this. I was pointing to Schema.org to use directly in the document body, but the out-of-band data like this works, too.

To give a self-promotion, I've been working on a mult-purpose hypermedia format called Verbose. Here is how you could describe some of the semantics for a resume JSON file. It can map to more complex structures.

{
  "verbose": {
    "prefixes": [
      {
        "prefix": "sdo",
        "href": "http://schema.org"
      }
    ],
    "semantics": [
      {
        "name": "firstName",
        "type": "string",
        "typeOf": "sdo:givenName",
        "mapsTo": "#/properties.bio.firstName",
        "title": "First Name"
      },
      {
        "name": "lastName",
        "type": "string",
        "typeOf": "sdo:familyName",
        "mapsTo": "#/properties.bio.lastName",
        "title": "Last Name"
      },
      {
        "name": "work",
        "type": "array",
        "mapsTo": "#/properties.bio.work",
        "title": "Work Experience"
      },
      {
        "name": "position",
        "type": "string",
        "typeOf": "sdo:namedPosition",
        "mapsTo": "#/properties.bio.work[].position",
        "title": "Position"
      },
      {
        "name": "startDate",
        "type": "string",
        "typeOf": "sdo:startDate",
        "mapsTo": "#/properties.bio.work[].startDate",
        "title": "Start Date"
      },
      {
        "name": "endDate",
        "type": "string",
        "typeOf": "sdo:endDate",
        "mapsTo": "#/properties.bio.work[].endDate",
        "title": "End Date"
      }
    ]
  }
}

[thomasdavis]

@smizell Might need you to jump on IRC and run me through some of this (Y) #jsonresume

[jinky32]

definitely +1 for json-ld! Makes so much sense for resumes. Also the use of FOAF.

[danbri]

JSON-LD would be a good step towards basic interoperability with the approach we're taking at schema.org (and FOAF).

Also you probably want to avoid firstName/lastName for I18N reasons - those concepts aren't very general. See http://www.w3.org/International/questions/qa-personal-names

[danja]

+1 to using JSON-LD plus terms from schema.org & FOAF where suitable. There's also the fairly extensive BIO schema at http://vocab.org/bio/0.1/.html - note that the JSON version there precedes JSON-LD, though data expressed using BIO (& FOAF & rdfs.schema.org) can easily be serialized as JSON-LD.
One big advantage in going the JSON-LD route is that with the model it has a clearly defined, fully-compatible, machine-processable mechanism for extending the schema for anyone that wants it, see http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/#section-vocabulary

[seralf]

+1 for me too for json-ld! :-)
In order to avoid verbosity, the @context for json-ld (as well as some extra data for assign rdf:type for example) can be exposed on a distinct json-ld file elsewere, and merged "on-the-fly" when providing the json resume.
This could be a nice feature for the registry API, as @bollwyvl said before, as it separates the mapping part from the data itselves, making them more simpler, and at the same times provides a way to see the structured data as a graph at (almost) no cost.
my 2 cents

[elf-pavlik]

I also work on simple codebase for online proifles, it uses JSON-LD, RDFa and whenever possible Schema.org terms, very early demo at my homepage: http://wwelves.org/perpetual-tripper/ you can copy its source and check out embedded graph by pasting it into http://rdfa.info/play

JSON-LD with data: https://github.com/elf-pavlik/webprofiled/blob/master/test/fixtures/perpetual-tripper/index.json

Handlebars template which renders RDFa from it: https://github.com/elf-pavlik/webprofiled/blob/master/views/profile.hbs

Soon I plan to switch from handlebars to special JSON-LD to RDFa templating, possibly extracted from http://viejs.org

Happy to help with JSON-LD, Schema.org etc. Also glad to see many experienced people already commented on this thread 🎯

[bollwyvl]

Haven't heard anything back from the project leadership: lots of things going on out there, but I'll go out on a limb: I think the task here is to build up the "so what" of making resume data available in terms of:

• WHY present resumes with a structured data vocabulary?
• WHAT vocabulary will give the most impact?
• HOW should the data be presented?

Here's my stab at an answer:

• WHY: Better SEO. If a user is putting their personal data up on a public website (protected resumes are another story), they want it to be discovered.
• WHAT: schema.org was built by the search engines to improve the quality of search rankings; as such there is unlikely to be a better vocabulary for achieving this end.
  • Indeed, other, important vocabularies, like FOAF, are providing their own mappings to schema.org
• HOW: schema.org is presently supporting microdata, RDFa and JSON-LD. Since this is already a JSON-based format, and likely nothing will have to change to support it, JSON-LD makes the most sense.
  • Downstream templates that chose to be aware of the context would be able to provide microdata/RDFa much more easily.

If the above holds, a reasonable starting point, if only to see how it would work, would be:

• PR to this repo: resume.jsonld mapping as much as possible of the current spec to schema.org terms
• PR to registry-server:
  • offers the context as a Link header when http://registry.jsonresume.org/richardhendriks.json is requested with
  • serves the context itself
    • schema.org, for example, offers theirs from / when it is requested with Accept: application/ld+json
  • serves a resume from http://registry.jsonresume.org/richardhendriks.jsonld with Content-Type application/ld+json from resumeToJsonLd...
• a resumeToJsonLd repo, based on resumeToHtml
  • resumeToJsonLd method itself to generate the "canonical' linked data format
    • inline @context?
    • could be very simple...
      • a light wrapper around a jsonld .compact or .frame?
    • ...or more involved
      • injection of @types throughout?
      • i18n expansion (Internationalization #35)?

Thoughts?

[bollwyvl]

Re: above:

• [wip] adding jsonld context #83
• [wip] adding jsonld context, .jsonld format registry-server#15
• https://github.com/bollwyvl/resumeToJSONLD

These will likely all need to evolve before any of them can be adopted.

Actually works pretty well already. The context on #83 is by far the weakest and most important part... any additional insight welcome on how to get closer to a thorough representation with schema.org items without requiring lots of after-the-fact processing in resumeToJSONLD... would framing help? Also, crucially, how might one test the "coverage" of the context in capturing the schema?

[thomasdavis]

Hey @bollwyvl, think you could hop on #jsonresume freenode at some stage. Will need a hand digesting everything. Had to finish a bunch of the tooling, but tonight shall be dedicated to the schema and docs.

[bollwyvl]

@thomasdavis: it will be later in the day before I can jump online, but am happy to help!

[thomasdavis]

aahh I will be asleep for the next 9 hours, damn timezones

On Thu, Jul 10, 2014 at 11:02 PM, bollwyvl [email protected] wrote:

@thomasdavis https://github.com/thomasdavis: it will be later in the
day before I can jump online, but am happy to help!

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

Thomas Davis
http://thomasdav.is

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

[elf-pavlik]

we work lately on few decoupled components for generating profiles (expressed with schema.org terms) and adding them to various directories, check out:

https://github.com/elf-pavlik/plp-generator
https://github.com/elf-pavlik/opendir - to connect with http://directory.open-steps.org/
i also plan to work on that with folks doing https://github.com/codeforamerica/cfapi
codeforamerica/cfapi#118
and we already collaborate with open-app team https://github.com/open-app/core/blob/master/roadmap.md
@thomasdavis what time (UTC) you tend to stay on IRC ?

[bollwyvl]

Shill piece on why resume-as-linked-data is important:
http://www.wired.com/2014/11/graph-databases-recruiting/

[elf-pavlik]

also Mozilla Open Badges now start adopting JSON-LD and participate in W3C Credentials CG http://lists.w3.org/Archives/Public/public-linked-json/2014Oct/0021.html

[olivif]

seems like a new feature to me and a massive change. also no updates in more than a year. Is this still relevant?

[stp-ip]

Definitely a bigger change and most likely something for the fine tuning stage? If we know what data goes into the next release, changing the wording/vocabulary etc. is easier than trying to incorporate that right now. At least that's my feeling.

[StevenBlack]

Suggestion to focus conversation: the Person schema from schema.org ought to be supported In toto here.

If you scroll that Person page, you come to this fascinating table. Preview below. It's especially the On Types column that's interesting.

• resume-schema needs to support CreativeWork for authors and collaborators and many of such types (some highlighted yellow below).
• resume-schema needs to support Event and Action pretty soon for those who have been organizer or participant or competitor or candidate or winner or recipient and performer of things.

See how vocab focuses discourse?

Just knowing the lexicon-space clarifies that resume-schema needs to support drastically more diverse Types beyond Work, Education, Skills...

(This shows half the list)

[chrisdotcode]

Let's revisit this post-v1.0.0.

[thomasdavis]

Have read all your comments, thought about it and read my previous comments. JSON Resume will remain a simple implementation, converting anything to a format on schema.org will just copy what it can.