W3C Resumes Work on the Profiles Vocabulary

W3C's Dataset Exchange Working Group published a new Working Draft of the Profiles Vocabulary on November 4, formally moving the document back onto the Recommendation track after it had sat as a Working Group Note since December 2019. The move was previewed in the working group's April 2026 charter, which listed republishing the Note as a Recommendation-track specification among its tentative deliverables, and was reported separately by industry outlet The Drop Times. For anyone maintaining a mid-level suite like CCO alongside domain extensions and application profiles, this is the spec that is supposed to make those layers machine-describable.
What the Profiles Vocabulary actually does
PROF, as the vocabulary is commonly abbreviated, gives a standard way to describe a "profile" of a specification — a constrained or extended version of a base standard, such as a domain extension of CCO, a SHACL shapes package validating against it, or a JSON Schema serialization aimed at a specific application. A profile description in PROF links together the base resource, its related artifacts (guidance documents, validators, schemas, example data), and the roles those artifacts play, all in RDF that a client can query before deciding which version of a specification it actually needs. The current draft is a substantive rewrite of the 2019 Note rather than a cosmetic republish: the working group's changelog lists updates across the introduction, definitions, namespace declarations, and the core vocabulary terms themselves.
Why a profiles-description spec matters for ontology-heavy data stacks
Mid-level ontologies like CCO are deliberately built to be extended, not used in isolation: a government agency's CCO-based data model and a logistics company's CCO-based data model are both "CCO," but each has its own domain extension, its own validation shapes, and its own constraints on which classes are actually in scope. Right now, documenting that relationship — this extension profiles that base ontology, this SHACL package validates against this profile, this JSON-LD context serializes that profile for a REST API — is mostly done in prose on a wiki page or a README, which means a new engineer or an external integrator has to read documentation to reconstruct a graph of relationships that could instead be queried directly. A standardized PROF description makes that graph machine-readable: a data catalog, a governance tool, or an internal API gateway can resolve "give me the validator for the version of this ontology my dataset claims to conform to" without a human in the loop.
That queryable layer only pays off once it is wired into the systems that actually serve the data — the catalog UI, the content-negotiation logic that hands a client the right profile-specific representation, the API that resolves a profile URI to its artifacts. Standing that up well is less an ontology-authoring task than an application-engineering one, and it is the kind of scoped integration work that YuSMP's web development team picks up for organizations whose semantic layer has outgrown what a documentation wiki can describe.
What to watch next
The document remains a Working Draft, not a Candidate Recommendation, and the working group has not published a target date for the next transition. The practical thing to track is adoption on the producing side: whether ontology registries, data catalog platforms (DCAT implementations in particular, since DXWG also owns that specification), and governance tooling vendors start exposing PROF descriptions for the specifications they host, since a vocabulary is only useful once something is actually publishing profile metadata in it.

