Vocabularies and classification: choose what the list means

Four lists can require four different models

Harbour Court has an inspection, a report version and a surveyor. The report may refer to an inspection outcome, be indexed under a subject taxonomy and have administrative metadata. These lists can look alike in a spreadsheet while answering different questions. A drop-down control is evidence of an interface choice, not evidence that all its entries are the same kind of thing.

Ask what each member identifies, who owns its meaning and what warrants completeness. Record the scope, owner, version and scheme role: Closed, OpenEnded or Classification. Without evidence of closure, choose the conservative open-ended disposition. A three-row sample does not establish that a fourth value is impossible. Classification describes editorial or policy use; it is not an additional ontological kind. These are the distinctions in ODR-0048 and ODR-0049.

A closed outcome set needs both meaning and an allowed list

For this fictional teaching profile, reviewers stipulate exactly two recorded outcomes for completed inspection attempts: the agreed scope was completed, or access limited completion. This is a deliberately narrow exercise, not a claim that real inspections have only two outcomes. Surveying and Valuation is the proposed semantic owner; the exercise calls the reviewed cut OutcomeProfile1. A cancelled attempt lies outside its stated scope and must be referred back to that owner, not squeezed into a convenient value.

The vocabulary gives both values stable identities, scheme membership, labels and definitions. Each is a skos:Concept and an instance of model:InspectionOutcome: ordinary RDF multi-typing, not punning. The value class is not the inspection event class. ODR-0039 and ODR-0040 select this pattern instead of owl:oneOf.

@prefix model: <https://example.org/property-model/> .
@prefix outcome: <https://example.org/vocabulary/inspection-outcome/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

model:InspectionOutcome a owl:Class .
outcome:scheme a skos:ConceptScheme ;
    skos:prefLabel "Inspection outcomes — teaching profile 1"@en ;
    skos:hasTopConcept outcome:Completed, outcome:Limited .

outcome:Completed a skos:Concept, model:InspectionOutcome ;
    skos:inScheme outcome:scheme ;
    skos:topConceptOf outcome:scheme ;
    skos:prefLabel "Completed within agreed scope"@en ;
    skos:altLabel "Scope completed"@en ;
    skos:notation "C" ;
    skos:definition "All activities in the agreed inspection scope were completed."@en ;
    skos:scopeNote "Says nothing about whether the inspected subject has defects."@en .

outcome:Limited a skos:Concept, model:InspectionOutcome ;
    skos:inScheme outcome:scheme ;
    skos:topConceptOf outcome:scheme ;
    skos:prefLabel "Limited by access"@en ;
    skos:notation "L" ;
    skos:definition "Access prevented completion of at least one agreed inspection activity."@en .

The receiving constraint is a separate statement about permitted data. These snippets use example.org IRIs and the ordinary Turtle/SHACL Core subset shown here; they are not a complete ontology, the full SHACL 1.2 authoring profile or an expansion of Property Pack 0.1's implemented features. Property declarations, ownership metadata and other applicable package requirements are omitted from the snippets, not waived.

@prefix model: <https://example.org/property-model/> .
@prefix outcome: <https://example.org/vocabulary/inspection-outcome/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

model:OutcomeProfile1 a sh:NodeShape ;
    sh:targetClass model:Inspection ;
    sh:property [ a sh:PropertyShape ;
        sh:path model:outcome ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:in (outcome:Completed outcome:Limited) ;
        sh:severity sh:Violation
    ] .

Do not routinely add sh:class to repeat the closure check. It would express an additional type requirement, not make sh:in more closed. Validate the vocabulary's dual typing separately; add a receiving type constraint only when a separately justified requirement calls for it.

A new surveyor is not a new outcome

Two surveyors in a sample are two identified resources, not a complete directory. The illustrative reference shape below requires each linked resource to be a Surveyor. Its expected results assume the type statements are present in the supplied graph; it relies on no external lookup or undeclared inference. Another surveyor with that asserted type can be referenced without changing the shape. An untyped reference fails this check even if a person knows the individual is a surveyor.

The subject taxonomy has a different job: indexing what a report discusses. Roof condition is a more specific concept than Building fabric. Neither concept is an inspection outcome or a class of surveyor, and no domain enumeration type is invented for it.

@prefix ex: <https://example.org/harbour-court/> .
@prefix model: <https://example.org/property-model/> .
@prefix subject: <https://example.org/vocabulary/subject/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:surveyor-a a model:Surveyor .
ex:surveyor-b a model:Surveyor .
model:SurveyorReferenceShape a sh:NodeShape ;
    sh:targetClass model:Inspection ;
    sh:property [ a sh:PropertyShape ;
        sh:path model:performedBy ; sh:minCount 1 ;
        sh:class model:Surveyor
    ] .

subject:scheme a skos:ConceptScheme ;
    skos:prefLabel "Inspection subjects — open teaching taxonomy"@en ;
    skos:hasTopConcept subject:BuildingFabric .
subject:BuildingFabric a skos:Concept ;
    skos:inScheme subject:scheme ; skos:topConceptOf subject:scheme ;
    skos:prefLabel "Building fabric"@en ;
    skos:definition "Subject matter concerning the physical fabric of a building."@en .
subject:RoofCondition a skos:Concept ;
    skos:inScheme subject:scheme ;
    skos:prefLabel "Roof condition"@en ;
    skos:definition "Subject matter concerning the condition of a roof."@en ;
    skos:broader subject:BuildingFabric .

This taxonomy remains open. Its chosen vocabulary profile still checks labels, definitions, membership and appropriate top/broader relationships; openness is not permission for malformed concepts. Reversing the last triple would say that Building fabric is the narrower topic. It would not express where a roof is physically located, and skos:broader must not be read as rdfs:subClassOf.

Maintain identity, wording and closure deliberately

A preferred label names a concept. skos:altLabel preserves a recognised alternative, skos:notation preserves its code, skos:definition establishes meaning and skos:scopeNote explains use or exclusions. An extracted phrase is only a proposed definition until reviewed. Renaming “Limited by access” must not mint a replacement identity merely to change what a page displays.

Flat enumeration members are top concepts. Assert taxonomy skos:broader child-to-parent; ancestry may use the selected skos:broaderTransitive relationship without claiming that broader itself is transitive. A source folder is not automatically a skos:Collection; that curation construct needs a purpose. The W3C SKOS Reference on semantic relations defines those relationships; the local ODRs select how this method uses them.

Extending a Closed scheme requires a reviewed decision amendment. Update the value definitions and corresponding sh:in list together, with a new version and ordinary/adverse cases. A deliberately narrower receiving profile can retain a subset, but must name and explain that subset. OpenEnded schemes grow through their ordinary stewardship procedure; neither kind of change should silently rewrite historical report values.

Separate a domain outcome from missing knowledge

“Unknown”, “NotSet”, “Undefined” and an empty field ordinarily describe what was not recorded. They do not say the inspection was completed or limited. Exclude such technical sentinels from the domain scheme and express requiredness or optionality through the chosen profile. Do not infer a default outcome from a selected form option.

A genuinely defined absence concept is possible, but needs semantic justification. “No applicable regulatory obligations”, for example, can be an explicitly governed facet value following qualified review; it cannot mean “nobody checked”. Ask the domain reviewer when absence itself is the business conclusion. For a bitfield source, preserve the meanings of primitive flags, not every composite implementation combination as a new concept.

Classify the model element without changing its identity

ODR-0036 supplies seven independent questions. The illustrative ReportVersion class can answer all seven while remaining owned by Surveying and Valuation. It does not become the building it describes or transfer ownership when another context uses it. The facet values below are descriptions of required decisions, not approved OPDA vocabulary members.

Use governed annotation properties with values in the correct SKOS schemes. Do not manufacture a domain OWL class for each infrastructure facet value: that would recursively create another class requiring classification. A value from the lifecycle scheme cannot satisfy a subject-area requirement merely because it is a skos:Concept. Check exact scheme membership and record any applicability exception.

Human assignment is separate from advisory extraction. A module or folder called “finance” cannot decide intrinsic subject area. Nor can a generated default establish regulatory relevance or governance tier. Confidentiality is not an eighth facet: sensitivity belongs to Category 11. A role or phase retains the meaning explained in roles and phases, regardless of its classifications.

The same metadata can meet one profile and miss another

Assume the fictional ReportVersion class has reviewed, correct-scheme values for the first six facets, a single English title, creators and valid issued/modified dates. It has no value-chain position. Hold that metadata constant while changing the claimed profile:

The stricter claims do not silently change the base optionality. Conversely, citing the base pattern cannot weaken a stricter claim. Under ODR-0049, an incomplete generated class stays in draft with the finding in the review queue. Do not lower severity because a machine authored it. Review the missing meaning and record the repair before claiming completeness.

Describe the record as well as its classifications

The bounded Dublin Core layer in ODR-0055 describes the classification record. A title is not a subject-area assignment, and a creator is not a governance tier. Use canonical http://purl.org/dc/terms/ IRIs without owl:imports; the local profile, not the entire vocabulary, supplies these requirements.

For example, "Harbour Court report-version model"@en can illustrate the required title. An untagged string misses its language requirement. With all seven facets and a proper title present, removing the creator produces the stated Warning, not an invented structural Violation. Review findings by severity; do not hide them or present every omission as a blocking error.

dct:subject is conditional: add it only on explicit modeller request, pointing to the SKOS ConceptScheme backing the subject-area facet. It does not replace the facet's concept value. Other Dublin Core terms need an amendment for this profile. This adoption neither requires a catalogue nor adopts DCAT or a data-product ontology.

Review four incoming lists

A contributor brings an outcome drop-down, a directory of two surveyors, a topic tree and seven metadata columns. They propose copying all four as closed lists, retaining “Unknown” as an outcome and making Building fabric narrower than Roof condition. What should change?

1. Ask for closure evidence. The reviewed narrow outcome profile can warrant a closed set; the drop-down alone cannot. Preserve the scope question about cancelled attempts for the owner.
2. Keep the population open. Surveyors are individually identified resources. Adding a third valid surveyor changes neither the closed outcome profile nor any separately governed report-status profile.
3. Repair conceptual direction. Roof condition is the child and Building fabric the broader parent. The roof's physical containment belongs in domain relationships, not this taxonomy.
4. Remove the unjustified sentinel. Unknown is missing knowledge here. Let the selected shape report absence; ask a domain reviewer before adding any genuinely defined absence concept.
5. Review metadata independently. Check each facet's exact scheme and the declared completeness profile. Missing regulatory review cannot be repaired by automatically inserting “none”.

The answer is not one universal list recipe. It is a justified representation, an explicit completeness claim, named ownership and visible unresolved questions.

Source contract

Required method: ODR-0036 for base facets; ODR-0039 and ODR-0040 for SKOS enumerations and open populations; ODR-0048 for evidence, hierarchy and exclusions; ODR-0049 for classification stewardship and stricter completeness; ODR-0055 for the bounded administrative profile.

Adoption provenance: upstream revision 67174057e6384b79d0b28b7736fe70a66e112895, 5 September 2026. See standards and decisions. All domain terms, values and review outcomes above are fictional teaching illustrations, not approved OPDA vocabulary or candidate conformance claims.