library(readr)
library(dplyr)
library(tibble)
library(purrr)
library(stringr)
library(jsonlite)
package_names <- c(
"onet2r",
"cmapr",
"huggingfaceR",
"foundryR"
)
package_versions <- package_names |>
set_names(package_names) |>
map_chr(\(package) {
as.character(
utils::packageVersion(package)
)
})
locked_packages <- fromJSON(
"renv.lock",
simplifyVector = FALSE
)$Packages
package_commits <- package_names |>
set_names(package_names) |>
map_chr(\(package) {
locked_packages[[package]]$RemoteSha
})
version_table <- tibble(
package = names(package_versions),
version = unname(package_versions),
commit = unname(package_commits)
)Examining provider schemas and provenance
Examine schema, units, provenance, and rights before combining records
training data
data providers
workforce research
Use onet2r, cmapr, and huggingfaceR fixtures to examine what an outside source records and what it cannot establish.
Selecting two uncertain sentences for labeling did not expand the Riverton Workforce Lab’s source material. It still has 28 fictional local text units. Those units provide practice material, not descriptions of a labor market. They cannot tell workers about options beyond those notices.
The team examines occupation tasks from the O*NET database and career transitions from CMap. It also examines a catalog of machine-learning dataset tasks from the Hugging Face Hub.
A training data provider supplies data or access to data. Providers are not necessarily neutral authorities. Before combining records, find their creator, purpose, source population, license, and row meaning.
This lesson examines small example files that the lesson author wrote for R packages. The files illustrate fields, row meanings, and rights questions. They cannot establish the quality, completeness, or accuracy of O*NET, CMap, or Hugging Face datasets. This lesson makes no such claims.
Note
Riverton Workforce Lab is fictional. The package fixtures are executable examples, not necessarily authenticated extracts from the providers named in their schemas. The lesson states each fixture’s status below.
TipWhat you will learn
By the end of this lesson, you will be able to:
- distinguish a package from the data source it helps access.
- examine versioned O*NET task records with onet2r.
- load CMap example transitions with cmapr.
- examine Hugging Face task names with huggingfaceR.
- examine whether two sources share a unit and a join key.
- say what an unauthenticated example file cannot establish.
Record the software versions
The teaching site’s author also wrote the R packages. The underlying data comes from separate providers with separate documentation and licenses. The next chunk loads table, file, JSON, repetition, and text helpers. It then records package versions. Provider calls include their package names.
| Package | Version | Git commit |
|---|---|---|
| onet2r | 0.5.0.9000 | b21c1d7430e6 |
| cmapr | 0.0.0.9000 | eb2d0b3810e0 |
| huggingfaceR | 2.1.0 | 56b2c416ff81 |
| foundryR | 0.1.0 | bdeccd40b211 |
The project lockfile also records the Git commit for packages installed from GitHub. A version number alone is not enough when development code can change.
Examine O*NET task statements
The onet2r package includes a miniature archive for examples. The parser receives release 30.3 and a release date as arguments. Those arguments describe the fixture to the function. They do not independently authenticate the bytes as an official O*NET database extract.
onet_archive <- system.file(
"extdata",
"onet-mini",
"db_30_3_text",
package = "onet2r"
)
onet_tasks <- onet2r::onet_archive_read(
version = "30.3",
table = "Task Statements",
path = onet_archive,
release_date = "2026-05-01"
)
onet_display <- onet_tasks |>
select(
task_id,
onet_soc_code,
title,
task,
release_version,
source_date
)| Task ID | O*NET-SOC code | Occupation | Task statement | Release | Source date |
|---|---|---|---|---|---|
| 1001 | 15-1252.00 | Software Developers | Analyze user needs and software requirements. | 30.3 | 2025-07-01 |
| 1002 | 15-1252.00 | Software Developers | Prepare reports on software testing status. | 30.3 | 2025-07-01 |
| 2001 | 29-1141.00 | Registered Nurses | Monitor patient health and record signs. | 30.3 | 2025-08-01 |
One row describes one occupation task. Each row retains the occupation code, supplied release label, and source date. The supplied release date differs from the source dates in individual rows. The three-row fixture demonstrates the onet2r schema. It cannot establish facts about occupations or the full O*NET database.
Task statements could inform a study of work or skills. They do not establish whether a particular Riverton notice offers training or evening classes.
Examine CMap career transitions
The cmapr package includes ten example transitions. Each row links one job title to a later title within a sector and region. The teaching fixture lacks upstream record identifiers. This lesson therefore cannot authenticate it as an exact CMap subset.
cmap_path <- cmapr::cmap_example_data()
cmap_transitions <- read_csv(
cmap_path,
col_types = cols(
sector = col_character(),
region = col_character(),
job_title_from = col_character(),
job_title_to = col_character(),
transition_weighted_count = col_double(),
si_from = col_double(),
si_to = col_double()
)
)| Sector | Region | Earlier title | Later title |
|---|---|---|---|
| Technology | North America | Software Engineer | Senior Software Engineer |
| Technology | North America | Senior Software Engineer | Engineering Manager |
| Technology | Europe | Data Analyst | Data Scientist |
| Healthcare | North America | Registered Nurse | Nurse Manager |
| Healthcare | Europe | Medical Assistant | Registered Nurse |
| Finance | North America | Financial Analyst | Senior Financial Analyst |
| Finance | Asia | Accountant | Finance Manager |
| Technology | Asia | Junior Developer | Software Engineer |
| Healthcare | North America | Physician Assistant | Medical Director |
| Finance | Europe | Investment Analyst | Portfolio Manager |
These rows demonstrate title-transition columns, not occupation task statements. A title change does not prove a promotion, wage gain, or improvement in job quality. The full CMap documentation distinguishes validated and model-inferred transitions. The fixture lacks that status and cannot provide population estimates.
Examine the Hugging Face task vocabulary
Hugging Face hosts many independently contributed datasets. huggingfaceR contains a local list of task names for Hub searches. Filtering that list does not download a dataset or establish whether a dataset card is accurate.
classification_tasks <- huggingfaceR::hf_list_tasks(
pattern = "classification"
)
classification_tasks[1] "text-classification" "token-classification"
[3] "zero-shot-classification" "image-classification"
[5] "audio-classification" The list shows the vocabulary bundled with this version of huggingfaceR, not a live statement about the Hub. A researcher still needs to examine each candidate dataset’s card, license, languages, collection method, labels, and known limits. Being searchable on a platform is not evidence that a dataset is suitable.
huggingfaceR can also build a zero-shot classification payload. This prepares a request body for inspection only. It does not choose a model or contact a provider.
zero_shot_payload <- huggingfaceR::hf_zero_shot_classification_payload(
"Paid training is provided.",
candidate_labels = c(
"training",
"requirement",
"schedule",
"skill",
"other"
),
multi_label = FALSE
)
str(zero_shot_payload)List of 2
$ inputs : chr "Paid training is provided."
$ parameters:List of 2
..$ candidate_labels: chr [1:5] "training" "requirement" "schedule" "skill" ...
..$ multi_label : logi FALSEDo not join unlike rows
The three resources use different units:
provider_units <- tibble(
resource = c(
"O*NET teaching archive",
"CMap teaching fixture",
"Hugging Face task vocabulary"
),
row_or_item = c(
"occupation task statement",
"job-title transition",
"platform task name"
),
records_seen = c(
nrow(onet_display),
nrow(cmap_transitions),
length(classification_tasks)
)
)| Resource | What one item means | Items examined |
|---|---|---|
| O*NET teaching archive | occupation task statement | 3 |
| CMap teaching fixture | job-title transition | 10 |
| Hugging Face task vocabulary | platform task name | 5 |
A shared topic is not a shared unit of analysis. A title-transition row cannot establish whether a posting offers evening classes. Combining a task statement with a local sentence requires a documented relationship. The team first needs a research question and a documented crosswalk between occupation codes, titles, or tasks. A crosswalk records relationships between different classifications.
Examine the join before using it
The code reports whether the tables have shared column names, matching titles, or common occupation codes. These checks find possible join keys.
onet_titles <- unique(onet_display$title)
cmap_titles <- unique(
c(
cmap_transitions$job_title_from,
cmap_transitions$job_title_to
)
)
shared_column_names <- intersect(
names(onet_display),
names(cmap_transitions)
)
exact_title_matches <- intersect(onet_titles, cmap_titles)
loosen <- function(titles) {
titles |>
str_to_lower() |>
str_remove("s$") |>
str_squish()
}
loose_title_matches <- intersect(
loosen(onet_titles),
loosen(cmap_titles)
)
join_report <- tibble(
test = c(
"shared column names",
"titles that match exactly",
"titles that match after lowercasing and dropping a final s",
"occupation codes present on both sides"
),
result = c(
length(shared_column_names),
length(exact_title_matches),
length(loose_title_matches),
as.integer(
"onet_soc_code" %in% names(cmap_transitions)
)
)
)| Test | Count |
|---|---|
| shared column names | 0 |
| titles that match exactly | 0 |
| titles that match after lowercasing and dropping a final s | 1 |
| occupation codes present on both sides | 0 |
The tables share no column names or exact title matches. One pair matches after lowercasing and removal of a final s. That pair is O*NET’s Registered Nurses and CMap’s Registered Nurse.
That string match does not establish a valid join. Each O*NET row describes an occupation task. The code 29-1141.00 identifies the occupation, and the task field identifies one activity. Each CMap row describes a transition between job titles without an occupation code.
Equal strings do not establish equal units. Joining the modified strings would link task statements to title transitions solely because removal of a letter produced a match.
A valid link needs a documented crosswalk from titles to occupation codes. The classification authority must publish the crosswalk with rules for many-to-many cases. String similarity alone does not establish those relationships.
Questions for any provider
The team records what it can establish and leaves unsupported fields as unknown.
| Resource examined | What supplied it | Unit shown | Coverage represented here | License and rights note | Status of teaching fixture |
|---|---|---|---|---|---|
| onet2r miniature archive | Installed onet2r package | Occupation task statement | 3 rows with U.S. occupation codes | O*NET database material requires CC BY 4.0 attribution. This lesson does not compare the fixture with an official archive. | Schema demonstration. This lesson does not authenticate the exact upstream extraction. |
| cmapr example transitions | Installed cmapr package | Job-title transition | 10 stylized rows across sectors and regions | Full CMap record is CC BY 4.0. The license does not resolve consent questions about underlying source records. | Package example. Its exact relationship to the full dataset is unknown here. |
| huggingfaceR task vocabulary | Installed huggingfaceR package | Platform task name | 5 locally bundled classification names | Package code is MIT. Each Hub dataset has contributor-declared terms. Underlying rights still need checks. | Local software vocabulary. The code downloads no dataset. |
- Who collected or generated the data?
- What population, language, place, and time does it cover?
- What does one row represent?
- Which records did the provider exclude or suppress?
- Which labels come from human decisions, and which come from model inference?
- Which version and taxonomy did the provider use?
- What license and attribution requirements apply? What activities does the license prohibit?
- Can the provider change or remove records later?
- Does the dataset contain personal or sensitive information?
An open license does not establish that the people represented in source data consented to every later application. A contributor-declared license also does not by itself prove that the contributor had every necessary right.
This page includes information from the O*NET Resource Center by the U.S. Department of Labor, Employment and Training Administration (USDOL/ETA). Used under the CC BY 4.0 license. O*NET® is a trademark of USDOL/ETA. The onet2r teaching fixture and this lesson may modify or add information. USDOL/ETA did not approve, endorse, or test those modifications.
What to remember
- A package is a tool, not the authority that created the data.
- Preserve provider, version, date, license, and row meaning.
- Small teaching fixtures demonstrate structure, not population results.
- An example file cannot establish the quality of the source it imitates.
- Platform availability does not establish quality or permission.
- Examine a join before using it. Investigate whether string matches reflect the intended relationship.
- Reconcile units and taxonomies before combining sources.
The inspections produced three schemas, three units, three rights notes, and no combined table. Demonstration files cannot establish a ranking of these sources. A comparison of actual provider data would require authenticated extracts and a stated research question. It would also require an independent evaluation criterion.
The local label table presents another comparability problem. Three reviewers may interpret the same requirement differently. Their answers remain separate for the following agreement analysis.