What may be changed on an existing concept?¶
A concept in Voc4Cat can be improved after it has been accepted: definitions get sharper, wrong parents get corrected, mappings get added. What cannot change is the meaning its identifier carries. This page states which changes fall on which side, and from when on.
The rule¶
Important
Once a concept is in Voc4Cat, the meaning its IRI carries is fixed. Everything else stays improvable.
Voc4Cat is a terminology, not an ontology or a knowledge graph. What it offers is the concept with an identifier, a label, and an agreed definition. The hierarchy, the collections and the mappings organize those concepts so they can be found; they are curation rather than axioms that annotated data inherits.
This drives the rules for changing concept labels vs. relations:
Change what a concept denotes, and every dataset annotated with it silently becomes wrong. Nothing warns anyone, because the IRI did not change.
Move a concept to a better parent, and no dataset becomes wrong. Hierarchical queries return something different, which is the point of the correction.
To test your change request, you can ask:
Would data that someone has already annotated with this IRI still be about the same thing after my change?
If yes, it is an improvement and allowed. If no, you are giving an existing identifier a new meaning: deprecate the concept and add a new one instead.
What may be changed, and when¶
A concept is in Voc4Cat as soon as the pull request that introduced it has been merged. From that moment it is part of the development version and it may appear in any later release.
Change class |
Where you edit it |
New in your pull request |
Already in Voc4Cat |
|---|---|---|---|
Identity (what the IRI denotes) |
Concepts: Preferred Label, Definition |
free |
not allowed; deprecate it and add a new concept |
Wording (same meaning, better phrasing) |
Concepts: Preferred Label, Definition |
free |
allowed via PR |
Parent relations (placement in the hierarchy) |
Concepts: Parent IRIs |
free |
allowed via PR |
External mappings |
Mappings: Related, Close, Exact, Narrower, Broader Matches |
free |
allowed via PR |
Collection membership |
Concepts: Member of collection(s), Member of ordered collection # position |
free |
allowed via PR |
Collection nesting |
Collections: Parent Collection IRIs |
free |
allowed via PR |
Collection identity (what a collection IRI denotes) |
Collections: Preferred Label, Definition |
free |
not allowed; same rule as for concepts |
Additive (more labels, translations, notes) |
Concepts: Alternate Labels, Change Note, Editorial Note; one row per language |
free |
allowed via PR |
Deprecation |
Concepts: Obsoletion reason, dct:isReplacedBy |
not needed; correct it instead |
allowed via PR |
Deletion (removing the row) |
— |
free |
not allowed; rejected automatically |
What the three verdicts mean:
free: Change it in the pull request you are working on. The concept has not been published yet, so nobody can be relying on it.
allowed via PR: Submit the change like any other contribution, in its own pull request. A curator reviews it.
not allowed: The change will be rejected. The table names what to do instead.
Note
A release does not lock or unlock anything; the rules above apply from the merge onwards. With Voc4Cat consumers can pick their own trade-off between stability and being up to date: pin to a dated release, to the latest release or to the development version.
What counts as the same meaning¶
The Preferred Label is not frozen; the concept behind it is.
Change |
Allowed? |
Why |
|---|---|---|
Fixing a spelling, or promoting the more common term for the same thing to Preferred Label |
yes |
Same concept, better wording. |
Rewriting a vague definition so that it says the same thing more precisely |
yes |
The set of things covered does not move. |
Narrowing a definition so that cases it used to cover are now excluded |
no |
Data annotated under the wider reading becomes wrong unnoticed. |
Relabelling external standard concentration as internal standard concentration |
no |
A different substance, and therefore a different concept. |
The last row is a real request (issue #280): leave the existing concept alone and add a new one if the new meaning is needed.
Correcting a parent¶
Correcting a wrong parent is allowed at every stage, and it is expected.
Changing skos:broader does not change what the IRI denotes; it changes where the concept sits.
In Voc4Cat skos:broader expresses IS-A relations and nothing else.
A quick test whenever you set a parent: is my concept a kind of its parent, or a property of its parent?
If it is a property, the parent is wrong.
The full reasoning, including how to express HAS-A and PART-OF instead, is in Hierarchies, Relations, and Collections.
Deprecating a concept¶
Concepts are never deleted once they are in Voc4Cat, because the IRI has to keep resolving for everyone who has used it. A concept that should no longer be used is deprecated: it stays in the vocabulary, marked as obsolete, and points at a replacement where there is one.
On the concept’s row in the Concepts sheet, Obsoletion reason is a dropdown offering six choices:
The concept is not clearly defined and usage has been inconsistent.
This concept was added in error.
More specific concepts were created.
This concept was converted to a collection.
The meaning of the concept is ambiguous.
Lack of evidence that this function/process/component exists.
Example: deprecating a duplicate
voc4cat:0009001 turns out to duplicate the older voc4cat:0009002 (IRIs invented for the example). On its row:
Column |
Value |
|---|---|
Obsoletion reason |
This concept was added in error. |
dct:isReplacedBy |
|
The pipeline sets owl:deprecated to true and records the reason as a skos:historyNote.
The concept keeps its IRI and stays resolvable; consumers see that it is obsolete and where to go instead.
voc4cat:0008124 is a concept deprecated this way, replaced by voc4cat:0007795.
Collections are deprecated in the same way, using the Obsoletion reason and dct:isReplacedBy columns of the Collections sheet.
Converting a concept to a collection¶
One of the obsoletion reasons is This concept was converted to a collection. It applies to a concept that turns out to be a grouping rather than a thing; the question to ask yourself is in Concept or Collection?.
The conversion does not imply a change of the type of an existing IRI. Once merged, an IRI in Voc4Cat keeps the meaning and type it was given. The steps are:
Deprecate the concept with the obsoletion reason This concept was converted to a collection.
Create a collection with a new IRI and give it the members.
Leave dct:isReplacedBy empty. It must never point to the new collection, because a consumer of the concept cannot substitute a set of concepts for the concept their data were annotated with.
Data that is already annotated with the deprecated concept has no automatic replacement. Only the data owner can decide which member of the new collection each annotation should use.
The mirror case works the same way: a collection that should have been a concept is deprecated with This collection was converted to a concept, and a new concept IRI is created.