An Introduction to RDF

The Resource Description Framework is a simple way to write down facts so that data from different organizations fits together on its own. Here is how it works, and why it matters for connecting workers, employers and educators.

Organizations, people and .example addresses here are fictional.

A fact has three parts

Every statement in RDF is a triple: a subject, a predicate and an object. The subject is the thing being described, the predicate is the relationship, and the object is what it points to.

One name for one thing

An employer, a college, an apprenticeship program and a worker can all describe the same skill in different words. People see the connection; software sees unrelated text.

RDF names things with Internationalized Resource Identifiers (IRIs), web addresses such as https://skills.riverbend.example/skill/plc-programming. When everyone points to the same address, a match is no longer a guess.

Data that merges

Because names are shared, combining datasets is seamless: their triples simply go into one graph. Below, an employer, a college and a worker each publish their own data. Nobody agreed on a database schema, only on the names.

When the graphs merge, nodes with the same IRI become one node, and new paths appear. The blue lines in the merged graph trace Maria’s credential to the skills it certifies, and on to every job that asks for them. None of the three publishers held that information alone.

Why it matters

Much of the friction in the labor market is about information. Employers can’t easily tell what a credential certifies, while workers struggle to prove skills learned on the job or in an apprenticeship. Education and training providers get signals about changing demand too slowly, and connecting all of these systems together is difficult and expensive.

The integration explosion

Suppose every organization in a region exchanges data with every other one, and each describes its data in its own way. Then every pair needs its own crosswalk: a custom mapping between their two formats. That is the assumption behind the left-hand picture below, and it is why the cost grows with the square of the number of participants.

With shared vocabularies and identifiers, each organization maps its data once, to a shared vocabulary, and can then exchange data with everyone else who did the same. The number of mappings grows in step with the number of participants.

Fewer missed matches

Most matching today compares words. A job posting asks for “Ladder logic”; a college credential certifies “PLC Programming”. To a person they are the same skill. To software comparing text, they are not.

With RDF, each organization still uses its own words, but also links each skill to an IRI in a shared skills framework. Software can then compare the IRIs instead of the words. Below, Maria’s record is checked against the Automation Technician posting both ways.

Nothing about the people changed, only how the data names things. The same idea lets a college check its courses against live demand, lets an apprenticeship count as evidence alongside a degree, and lets each organization map its data once, to a shared vocabulary, instead of once per partner.

Writing it down

RDF is a data model, not a file format. The same graph can be written in several standard syntaxes. Three common formats are: Turtle, which is compact and easy to read; JSON-LD, which is ordinary JSON with a little context added; and N-Triples, which writes one triple per line with every name spelled out in full.

The examples below are small pieces of the data used above: a job posting, a worker’s record and a skill. Each shows a small graph, then the same triples written all three ways. In Turtle, prefixes such as schema: are shorthand for long web addresses, declared once at the top.

A job posting

Acme Robotics is hiring an Automation Technician at $68,000. The job requires two skills, named by IRIs from a shared skills framework.

@prefix schema: <https://schema.org/> .
@prefix sk:     <https://skills.riverbend.example/skill/> .
@prefix acme:   <https://jobs.acme-robotics.example/> .

acme:job-automation-technician
    a schema:JobPosting ;
    schema:title "Automation Technician" ;
    schema:hiringOrganization acme:org ;
    schema:baseSalary 68000 ;
    schema:salaryCurrency "USD" ;
    schema:skills sk:plc-programming, sk:robot-operation .

@prefix schema: <https://schema.org/> .
@prefix sk:     <https://skills.riverbend.example/skill/> .
@prefix acme:   <https://jobs.acme-robotics.example/> .

acme:job-automation-technician
    a schema:JobPosting ;
    schema:title "Automation Technician" ;
    schema:hiringOrganization acme:org ;
    schema:baseSalary 68000 ;
    schema:salaryCurrency "USD" ;
    schema:skills sk:plc-programming, sk:robot-operation .

{
  "@context": {
    "schema": "https://schema.org/",
    "sk": "https://skills.riverbend.example/skill/",
    "acme": "https://jobs.acme-robotics.example/"
  },
  "@id": "acme:job-automation-technician",
  "@type": "schema:JobPosting",
  "schema:title": "Automation Technician",
  "schema:hiringOrganization": { "@id": "acme:org" },
  "schema:baseSalary": 68000,
  "schema:salaryCurrency": "USD",
  "schema:skills": [
    { "@id": "sk:plc-programming" },
    { "@id": "sk:robot-operation" }
  ]
}

<https://jobs.acme-robotics.example/job-automation-technician> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/JobPosting> .
<https://jobs.acme-robotics.example/job-automation-technician> <https://schema.org/title> "Automation Technician" .
<https://jobs.acme-robotics.example/job-automation-technician> <https://schema.org/hiringOrganization> <https://jobs.acme-robotics.example/org> .
<https://jobs.acme-robotics.example/job-automation-technician> <https://schema.org/baseSalary> "68000"^^<http://www.w3.org/2001/XMLSchema#integer> .
<https://jobs.acme-robotics.example/job-automation-technician> <https://schema.org/salaryCurrency> "USD" .
<https://jobs.acme-robotics.example/job-automation-technician> <https://schema.org/skills> <https://skills.riverbend.example/skill/plc-programming> .
<https://jobs.acme-robotics.example/job-automation-technician> <https://schema.org/skills> <https://skills.riverbend.example/skill/robot-operation> .

In Turtle, ; means “same subject, next predicate” and , means “same predicate, next object”, so a description reads almost like a sentence. In JSON-LD, the @context says which keys are vocabulary terms, and @id gives the thing its name.

N-Triples drops all of the shorthand. It is verbose, but it shows most plainly what an RDF graph is: a list of triples, each a subject, a predicate and an object, and nearly all of them IRIs. Only plain values such as names and salaries are not.

A worker’s record

Maria holds a credential recognized by Riverbend Community College. The credential describes the skills it certifies, using the same skill IRIs as the job posting.

@prefix schema: <https://schema.org/> .
@prefix sk:     <https://skills.riverbend.example/skill/> .
@prefix rcc:    <https://catalog.riverbend-cc.example/> .
@prefix wallet: <https://wallet.example/> .

wallet:maria
    a schema:Person ;
    schema:name "Maria Alvarez" ;
    schema:hasCredential rcc:credential-aas-mechatronics .

rcc:credential-aas-mechatronics
    a schema:EducationalOccupationalCredential ;
    schema:name "Associate of Applied Science in Mechatronics" ;
    schema:recognizedBy rcc:org ;
    schema:competencyRequired sk:plc-programming, sk:robot-operation .

@prefix schema: <https://schema.org/> .
@prefix sk:     <https://skills.riverbend.example/skill/> .
@prefix rcc:    <https://catalog.riverbend-cc.example/> .
@prefix wallet: <https://wallet.example/> .

wallet:maria
    a schema:Person ;
    schema:name "Maria Alvarez" ;
    schema:hasCredential rcc:credential-aas-mechatronics .

rcc:credential-aas-mechatronics
    a schema:EducationalOccupationalCredential ;
    schema:name "Associate of Applied Science in Mechatronics" ;
    schema:recognizedBy rcc:org ;
    schema:competencyRequired sk:plc-programming, sk:robot-operation .

{
  "@context": {
    "@vocab": "https://schema.org/",
    "sk": "https://skills.riverbend.example/skill/",
    "rcc": "https://catalog.riverbend-cc.example/",
    "wallet": "https://wallet.example/",
    "recognizedBy": { "@type": "@id" },
    "competencyRequired": { "@type": "@id" }
  },
  "@id": "wallet:maria",
  "@type": "Person",
  "name": "Maria Alvarez",
  "hasCredential": {
    "@id": "rcc:credential-aas-mechatronics",
    "@type": "EducationalOccupationalCredential",
    "name": "Associate of Applied Science in Mechatronics",
    "recognizedBy": "rcc:org",
    "competencyRequired": ["sk:plc-programming", "sk:robot-operation"]
  }
}

<https://wallet.example/maria> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/Person> .
<https://wallet.example/maria> <https://schema.org/name> "Maria Alvarez" .
<https://wallet.example/maria> <https://schema.org/hasCredential> <https://catalog.riverbend-cc.example/credential-aas-mechatronics> .
<https://catalog.riverbend-cc.example/credential-aas-mechatronics> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/EducationalOccupationalCredential> .
<https://catalog.riverbend-cc.example/credential-aas-mechatronics> <https://schema.org/name> "Associate of Applied Science in Mechatronics" .
<https://catalog.riverbend-cc.example/credential-aas-mechatronics> <https://schema.org/recognizedBy> <https://catalog.riverbend-cc.example/org> .
<https://catalog.riverbend-cc.example/credential-aas-mechatronics> <https://schema.org/competencyRequired> <https://skills.riverbend.example/skill/plc-programming> .
<https://catalog.riverbend-cc.example/credential-aas-mechatronics> <https://schema.org/competencyRequired> <https://skills.riverbend.example/skill/robot-operation> .

JSON-LD can nest one thing inside another, which is how most APIs already shape their data. Setting "@vocab" to schema.org lets plain keys like name stand for full vocabulary terms. That is often all it takes to turn an existing JSON API into linked data.

A skill with its synonyms

The skills framework defines PLC Programming once, lists the other ways people say it, and places it under a broader category.

@prefix skos:   <http://www.w3.org/2004/02/skos/core#> .
@prefix schema: <https://schema.org/> .
@prefix sk:     <https://skills.riverbend.example/skill/> .

sk:plc-programming
    a skos:Concept, schema:DefinedTerm ;
    skos:prefLabel "PLC Programming"@en ;
    skos:altLabel "ladder logic"@en, "programmable logic controllers"@en, "PLCs"@en ;
    skos:broader sk:industrial-automation .

@prefix skos:   <http://www.w3.org/2004/02/skos/core#> .
@prefix schema: <https://schema.org/> .
@prefix sk:     <https://skills.riverbend.example/skill/> .

sk:plc-programming
    a skos:Concept, schema:DefinedTerm ;
    skos:prefLabel "PLC Programming"@en ;
    skos:altLabel "ladder logic"@en, "programmable logic controllers"@en, "PLCs"@en ;
    skos:broader sk:industrial-automation .

{
  "@context": {
    "skos": "http://www.w3.org/2004/02/skos/core#",
    "schema": "https://schema.org/",
    "sk": "https://skills.riverbend.example/skill/",
    "prefLabel": { "@id": "skos:prefLabel", "@language": "en" },
    "altLabel": { "@id": "skos:altLabel", "@language": "en" },
    "broader": { "@id": "skos:broader", "@type": "@id" }
  },
  "@id": "sk:plc-programming",
  "@type": ["skos:Concept", "schema:DefinedTerm"],
  "prefLabel": "PLC Programming",
  "altLabel": ["ladder logic", "programmable logic controllers", "PLCs"],
  "broader": "sk:industrial-automation"
}

<https://skills.riverbend.example/skill/plc-programming> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept> .
<https://skills.riverbend.example/skill/plc-programming> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://schema.org/DefinedTerm> .
<https://skills.riverbend.example/skill/plc-programming> <http://www.w3.org/2004/02/skos/core#prefLabel> "PLC Programming"@en .
<https://skills.riverbend.example/skill/plc-programming> <http://www.w3.org/2004/02/skos/core#altLabel> "ladder logic"@en .
<https://skills.riverbend.example/skill/plc-programming> <http://www.w3.org/2004/02/skos/core#altLabel> "programmable logic controllers"@en .
<https://skills.riverbend.example/skill/plc-programming> <http://www.w3.org/2004/02/skos/core#altLabel> "PLCs"@en .
<https://skills.riverbend.example/skill/plc-programming> <http://www.w3.org/2004/02/skos/core#broader> <https://skills.riverbend.example/skill/industrial-automation> .

This is what makes the four phrasings above line up: a skills framework publishes one IRI per skill, with its preferred label and its alternatives, using the SKOS vocabulary.

Where to start

The standards for this already exist. Some are RDF vocabularies from the start; others publish JSON-LD or map cleanly to RDF.

Jobs and skills

schema.org for job postings, and SKOS, the W3C standard for publishing taxonomies, for skill frameworks such as ESCO.

Credentials and competencies

CTDL, the Credential Transparency Description Language, for credentials, competencies and pathways, and CASE, Competencies and Academic Standards Exchange, for competency frameworks and academic standards.

Learner records

Open Badges 3.0 for individual achievements and the Comprehensive Learner Record for full transcripts, both built on W3C Verifiable Credentials.

Education data

CEDS, the Common Education Data Standards, a shared vocabulary for education and workforce data that is also published as an RDF ontology.

For most organizations the first step is small: publish the data they already have as JSON-LD, with an @context that maps their keys to one of these vocabularies, as in the examples above.