The CDIF Concept Scheme profile ** (cdifConceptScheme) describes a **SKOS concept scheme — a controlled vocabulary of concepts used in CDIF metadata. A typical concept scheme is a community glossary or thesaurus that supplies shared definitions and terms: the concepts used to name variables, classify resources, or qualify measurements in other CDIF profiles.
Related profile. A code list is a concept scheme whose members are controlled values carrying machine notation codes (skos:notation). Code lists are published as the separate profile-codelist profile. Use Concept Scheme for a general vocabulary of meanings; use Codelist when each concept must carry a code.
A conforming concept scheme is typed as a skos:ConceptScheme and declares conformance to the Concept Scheme profile identifier:
{
"@context": { "skos": "http://www.w3.org/2004/02/skos/core#" },
"@id": "https://example.org/vocab/myscheme",
"@type": ["skos:ConceptScheme"],
"skos:prefLabel": {"@value": "My Vocabulary", "@language": "en"},
"skos:definition": {"@value": "...", "@language": "en"},
"skos:hasTopConcept": [ { "@id": "https://example.org/vocab/myscheme/top" } ]
}
Required elements for the Concept Scheme:
@id — the scheme’s IRI;@type — must include skos:ConceptScheme;skos:prefLabel — preferred label (string or language-tagged value; at most one per language);skos:definition — what the scheme is for;skos:hasTopConcept — at least one top-level concept, defining the vocabulary’s entry points.Top concepts (and their narrower concepts) are skos:Concept nodes, given inline or by @id reference. Each concept carries skos:prefLabel and skos:definition. Optional properties include skos:note, skos:inScheme, and the hierarchy relations skos:broader / skos:narrower (themselves inline concepts or @id references).
cdifConceptSchemeStructuredSchema.json (Draft 2020-12), generated from the source register.conceptSchemeRules.shacl, which targets skos:ConceptScheme and checks that a scheme has an IRI identifier, at least one skos:prefLabel (with sh:uniqueLang), and at least one skos:hasTopConcept.python FrameAndValidate.py examples/exampleSkosConceptScheme.json --validate
FrameAndValidate.py frames the document with cdifConceptScheme-frame.jsonld, array-wraps the multi-valued SKOS properties, then validates against the JSON Schema. Validation is open-world: properties beyond the profile are permitted.
skos:ConceptScheme.skos:broader within this scheme. The JSON-LD hierarchy is rooted here — all child concepts are reached by traversing skos:narrower from these top concepts.dcterms:identifier.Description: Date when the concept scheme was last modified. Takes precedence over dcterms:modified.
dcterms:license.en, fr, de, sv).
{"@value": "Sampled Feature Type vocabulary", "@language": "en"}
@id, used for linking to concepts or schemes defined elsewhere in the graph or externally.
{"@id": "https://w3id.org/isample/vocabulary/sampledfeature/anysampledfeature"}
schema:PropertyValue:{
"@type": ["schema:PropertyValue"],
"schema:propertyID": "https://registry.identifiers.org/registry/doi",
"schema:value": "10.5683/SP2/TTJNIU",
"schema:url": "https://doi.org/10.5683/SP2/TTJNIU"
}
'missing'.{"@id": "scheme-uri"}.skos:narrower on another concept must declare skos:broader pointing back. See Bidirectional hierarchy below. Each item is {"@id": "parent-concept-uri"}.skos:broader pointing back to this concept. Items can be full inline concept objects (for building the JSON tree) or {"@id": "child-uri"} references.skos:Concept.sh:uniqueLang).CDIF guidelines require concept hierarchies to be expressed in both directions:
skos:narrower is needed because the JSON-LD tree is rooted at skos:hasTopConcept. Without skos:narrower, child concepts cannot be reached by traversing the JSON document from the root.
skos:broader is needed for upward navigation and for display trees in vocabulary browsers.
Any concept that appears as a value of skos:narrower must also declare skos:broader pointing back to its parent. Top concepts (those in skos:hasTopConcept) should not have skos:broader within the scheme.
{
"@id": "sf:anysampledfeature",
"@type": ["skos:Concept"],
"skos:prefLabel": "Any sampled feature",
"skos:definition": "Top concept",
"skos:inScheme": {"@id": "sf:sampledfeaturevocabulary"},
"skos:narrower": [
{
"@id": "sf:earthmaterial",
"@type": ["skos:Concept"],
"skos:prefLabel": "Natural Solid Material",
"skos:definition": "A naturally occurring solid material.",
"skos:inScheme": {"@id": "sf:sampledfeaturevocabulary"},
"skos:broader": [{"@id": "sf:anysampledfeature"}]
}
]
}
Unlike other CDIF profiles, the skos profile does not require repeatable properties to always be serialized as arrays. This recognizes standard SKOS practice that allows either a single string or an array for literal values. For example, both of these are valid:
"skos:prefLabel": "Material"
"skos:prefLabel": [
{"@value": "Material", "@language": "en"},
{"@value": "Matériau", "@language": "fr"}
]
Consumers of CDIF concept scheme documents should test whether a value is a string or an array before iterating.
Generated from the canonical metadataBuildingBlocks register:
cdifConceptSchemeStructuredSchema.json ← tools/resolve_schema.py cdifConceptSchemeconceptSchemeRules.shacl ← byte-copy of _sources/skosProperties/skosConceptScheme/rules.shaclThe profile schema (_sources/profiles/cdifProfile/cdifConceptScheme/schema.yaml) is self-contained — it inlines the SKOS Concept and language-tagged-value definitions rather than referencing the skosConceptScheme building block — so the SHACL shapes are taken directly from the SKOS concept-scheme building block rather than produced by validate_shacl.py --emit-shapes. Re-sync these artifacts whenever the source register changes.