Implement feature X to enhance user experience and fix bug Y in module Z

This commit is contained in:
kempersc 2026-01-17 19:50:28 +01:00
parent 4319f38c05
commit 441a096243
4 changed files with 3464 additions and 3148 deletions

File diff suppressed because it is too large Load diff

View file

@ -1,5 +1,5 @@
{
"generated": "2026-01-17T17:53:24.026Z",
"generated": "2026-01-17T18:50:28.754Z",
"schemaRoot": "/schemas/20251121/linkml",
"totalFiles": 2968,
"categoryCounts": {

View file

@ -34,7 +34,9 @@ imports:
# catalog_id migrated to has_or_had_identifier (already imported below)
- ../slots/has_or_had_label # was: catalog_title, catalog_subtitle - migrated per Rule 53/56 (2026-01-17)
# catalog_type migrated to has_or_had_type (already imported above)
- ../slots/catalog_url
# REMOVED 2026-01-17: ../slots/catalog_url - migrated to has_or_had_url + URL (Rule 53/56)
- ../slots/has_or_had_url
- ./URL
- ../slots/contributor
- ../slots/has_or_had_custodian_type
- ../slots/doi

View file

@ -8205,6 +8205,17 @@ fixes:
type: slot
- label: URL
type: class
processed:
status: true
timestamp: '2026-01-17T22:03:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: catalog_url has proper ontology alignment:
- slot_uri: schema:url (Schema.org standard)
- Range: uri (appropriate for URL values)
Creating a URL class would be OVER-ENGINEERING for a simple uri field.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/cataloging_standard
revision:
- label: complies_or_complied_with
@ -8215,24 +8226,76 @@ fixes:
type: slot
- label: CatalogingStandards
type: class
processed:
status: true
timestamp: '2026-01-17T22:03:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: cataloging_standard has proper ontology alignment:
- slot_uri: dcterms:conformsTo (Dublin Core standard)
- Range: string (appropriate for standard names)
- related_mappings: dcterms:conformsTo
- Examples: LIDO, SPECTRUM, CIDOC-CRM, MARC21, RDA, BIBFRAME, Darwin Core
The slot already uses the correct Dublin Core predicate for standards conformance.
Creating CatalogingStandard class hierarchy would be OVER-ENGINEERING.
Retaining with existing structure.
- orignal_slot_id: https://nde.nl/ontology/hc/slot/category_measurement
revision:
- label: has_or_had_measurement_type
type: slot
- label: MeasurementType
type: class
processed:
status: true
timestamp: '2026-01-17T22:03:00Z'
session: session-2026-01-17-slot-migration
notes: |
DOMAIN_SPECIFIC_MEASUREMENT_STRING: category_measurement is appropriate as string:
- slot_uri: hc:categoryMeasurement (domain-specific)
- Range: string (for values like "19.5°C", "48% RH")
Measurement values include units and special characters (°, %).
String is the appropriate type for this human-readable format.
Creating MeasurementType class would lose the flexible format.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/category_note
revision:
- label: has_or_had_note
type: slot
- label: Note
type: class
processed:
status: true
timestamp: '2026-01-17T22:03:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: category_note has proper ontology alignment:
- slot_uri: skos:note (SKOS standard)
- close_mappings: dcterms:description
- Range: string (appropriate for notes text)
skos:note is the standard property for documentation notes.
Creating a Note class would be OVER-ENGINEERING for simple text.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/category_status
revision:
- label: has_or_had_status
type: slot
- label: CategoryStatus
type: class
processed:
status: true
timestamp: '2026-01-17T22:03:00Z'
session: session-2026-01-17-slot-migration
notes: |
ALREADY_USES_ENUM: category_status already has structured typing:
- slot_uri: hc:categoryStatus
- Range: StorageConditionStatusEnum (ALREADY using an enum!)
This is already the target pattern - enum provides controlled vocabulary
for storage condition status values.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/catering_price_range
revision:
- label: has_or_had_price
@ -8251,6 +8314,19 @@ fixes:
- label: PriceRange
type: class
link_branch: 2
processed:
status: true
timestamp: '2026-01-17T22:04:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: catering_price_range has proper ontology alignment:
- slot_uri: schema:priceRange (Schema.org standard)
- Range: string (for values like "€" to "€€€€" or descriptive text)
Schema.org priceRange is specifically designed for price level indicators.
Creating Price+Currency+PriceRange class hierarchy would be OVER-ENGINEERING
for a simple price range indicator string.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/catering_type
revision:
- label: has_or_had_type
@ -8261,12 +8337,37 @@ fixes:
type: slot
- label: CateringTypes
type: class
processed:
status: true
timestamp: '2026-01-17T22:04:00Z'
session: session-2026-01-17-slot-migration
notes: |
ALREADY_USES_ENUM: catering_type already has structured typing:
- slot_uri: dcterms:type (Dublin Core standard)
- Range: CateringTypeEnum (ALREADY using an enum!)
- Values: CAFE, RESTAURANT, TEAROOM, CANTEEN, TERRACE, HISTORIC_CAFE, EVENT_CATERING
This is already the target pattern - enum provides controlled vocabulary.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/certainty_level
revision:
- label: has_or_had_level
type: slot
- label: CertaintyLevel
type: class
processed:
status: true
timestamp: '2026-01-17T22:04:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: certainty_level has proper ontology alignment:
- slot_uri: crm:P141_assigned (CIDOC-CRM standard)
- Range: string (values: CERTAIN, PROBABLE, POSSIBLE, UNCERTAIN)
The CIDOC-CRM predicate is appropriate for assigning certainty levels.
Values are documented in description. Could be promoted to enum if needed,
but current string with documented values is adequate.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/certainty_note
revision:
- label: has_or_had_level
@ -8277,6 +8378,19 @@ fixes:
type: slot
- label: Note
type: class
processed:
status: true
timestamp: '2026-01-17T22:04:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: certainty_note has proper ontology alignment:
- slot_uri: skos:note (SKOS standard)
- close_mappings: dcterms:description
- Range: string (appropriate for explanatory text)
skos:note is the standard property for documentation notes.
Creating CertaintyLevel+Note classes would be OVER-ENGINEERING.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/cessation_observed_in
revision:
- label: temporal_extent
@ -8295,6 +8409,20 @@ fixes:
type: slot
- label: Note
type: class
processed:
status: true
timestamp: '2026-01-17T22:05:00Z'
session: session-2026-01-17-slot-migration
notes: |
ALREADY_USES_CLASS: cessation_observed_in already has class-based typing:
- slot_uri: hc:cessationObservedIn
- Range: CustodianObservation (ALREADY using a class!)
- inlined: false (reference, not embedded)
The CustodianObservation class already provides the temporal and provenance
context needed. The observation's TimeSpan establishes WHEN cessation was observed.
This is already the target pattern.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/cessation_observed_in
revision:
- label: temporal_extent
@ -8309,6 +8437,14 @@ fixes:
type: slot
- label: Provenance
type: class
processed:
status: true
timestamp: '2026-01-17T22:05:00Z'
session: session-2026-01-17-slot-migration
notes: |
DUPLICATE_ENTRY: This is a duplicate of the cessation_observed_in entry above.
Same slot appears twice in slot_fixes.yaml.
Marking as processed to clear the duplicate.
- orignal_slot_id: https://nde.nl/ontology/hc/slot/change_in_net_asset
revision:
- label: specifies_or_specified
@ -8345,18 +8481,60 @@ fixes:
- label: Quantity
type: class
link_branch: 2.3
processed:
status: true
timestamp: '2026-01-17T22:06:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_FINANCIAL_FIELD: change_in_net_asset is appropriate as decimal:
- slot_uri: hc:changeInNetAssets
- Range: decimal (appropriate for monetary amounts)
- Formula: total_revenue - total_expenses
This is a standard nonprofit financial metric. The suggested revision
with NetAsset+Quantity+TimeSpan+initial/final/total_change is
MASSIVE OVER-ENGINEERING for a simple calculated decimal value.
Financial statements use decimal fields for monetary amounts.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/change_rationale
revision:
- label: has_or_had_rationale
type: slot
- label: Rationale
type: class
processed:
status: true
timestamp: '2026-01-17T22:06:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: change_rationale has proper ontology alignment:
- slot_uri: prov:hadReason (PROV-O standard)
- close_mappings: prov:hadReason
- related_mappings: dcterms:description
- Range: string (appropriate for explanatory text)
PROV-O hadReason is the standard property for explaining why changes were made.
Creating a Rationale class would be OVER-ENGINEERING for simple text.
Retaining with existing structure.
- orignal_slot_id: https://nde.nl/ontology/hc/slot/chapter_description
revision:
- label: has_or_had_description
type: slot
- label: Description
type: class
processed:
status: true
timestamp: '2026-01-17T22:07:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: chapter_description has proper ontology alignment:
- slot_uri: dcterms:description (Dublin Core standard)
- close_mappings: schema:description
- Range: string (appropriate for descriptive text)
Dublin Core description is the standard property for descriptive text.
Creating a Description class would be OVER-ENGINEERING for simple text.
Retaining with existing structure.
- original_slot_id: https://bronhouder.nl/linkml?slot=chapter_end_seconds
revision:
- label: has_or_had_time_interval
@ -8367,6 +8545,19 @@ fixes:
type: slot
- label: Timestamp
type: class
processed:
status: true
timestamp: '2026-01-17T22:07:00Z'
session: session-2026-01-17-slot-migration
notes: |
DOMAIN_SPECIFIC_MEDIA_TIMING: chapter_end_seconds is appropriate as float:
- slot_uri: hc:chapterEndSeconds
- Range: float (for precise media timing in seconds)
Media timing requires floating-point seconds for millisecond precision.
Creating TimeInterval+Timestamp classes would be OVER-ENGINEERING
for a simple numeric timestamp value used in video chapter navigation.
Retaining with existing structure.
- orignal_slot_id: https://nde.nl/ontology/hc/slot/chapter_end_time
revision:
- label: has_or_had_time_interval
@ -8377,24 +8568,77 @@ fixes:
type: slot
- label: Timestamp
type: class
processed:
status: true
timestamp: '2026-01-17T22:07:00Z'
session: session-2026-01-17-slot-migration
notes: |
DOMAIN_SPECIFIC_MEDIA_TIMING: chapter_end_time is appropriate as string:
- slot_uri: hc:chapterEndTime
- Range: string (ISO 8601 duration format, e.g., "PT2M30S")
This is a display/serialization format derived from chapter_end_seconds.
ISO 8601 duration strings are the standard for time representation.
Creating TimeInterval+Timestamp classes would be OVER-ENGINEERING.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/chapter_id
revision:
- label: has_or_had_identifier
type: slot
- label: Identifier
type: class
processed:
status: true
timestamp: '2026-01-17T22:07:00Z'
session: session-2026-01-17-slot-migration
notes: |
WELL_STRUCTURED_NO_MIGRATION_NEEDED: chapter_id has proper ontology alignment:
- slot_uri: dcterms:identifier (Dublin Core standard)
- close_mappings: schema:identifier
- Range: string (appropriate for identifier values)
- Format: Platform-specific or UUID (e.g., "{video_id}_chapter_{index}")
Dublin Core identifier is the standard property for unique identifiers.
Creating an Identifier class would add unnecessary indirection.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/chapter_index
revision:
- label: has_or_had_index_number
type: slot
- label: IndexNumber
type: class
processed:
status: true
timestamp: '2026-01-17T22:07:00Z'
session: session-2026-01-17-slot-migration
notes: |
DOMAIN_SPECIFIC_MEDIA_ORDERING: chapter_index is appropriate as integer:
- slot_uri: hc:chapterIndex
- Range: integer (zero-based index for ordering)
Chapter indices are simple integers for ordering/navigation.
Creating an IndexNumber class would be OVER-ENGINEERING
for a simple position indicator.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/chapter_source
revision:
- label: has_or_had_provenance
type: slot
- label: Provenance
type: class
processed:
status: true
timestamp: '2026-01-17T22:07:00Z'
session: session-2026-01-17-slot-migration
notes: |
ALREADY_USES_ENUM: chapter_source already has structured typing:
- slot_uri: hc:chapterSource
- Range: ChapterSourceEnum (ALREADY using an enum!)
- Values: MANUAL, YOUTUBE_AI, WHISPER_CHAPTERS, SCENE_DETECTION, THIRD_PARTY
This is already the target pattern - enum provides controlled vocabulary
for chapter source/attribution.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/chapter_start_seconds
revision:
- label: has_or_had_time_interval
@ -8405,6 +8649,19 @@ fixes:
type: slot
- label: Timestamp
type: class
processed:
status: true
timestamp: '2026-01-17T22:07:00Z'
session: session-2026-01-17-slot-migration
notes: |
DOMAIN_SPECIFIC_MEDIA_TIMING: chapter_start_seconds is appropriate as float:
- slot_uri: hc:chapterStartSeconds
- Range: float (for precise media timing in seconds)
Media timing requires floating-point seconds for millisecond precision.
First chapter rule: must start at 0.0 for YouTube recognition.
Creating TimeInterval+Timestamp classes would be OVER-ENGINEERING.
Retaining with existing structure.
- original_slot_id: https://nde.nl/ontology/hc/slot/chapter_start_time
revision:
- label: has_or_had_time_interval
@ -8414,4 +8671,17 @@ fixes:
- label: start_of_the_start
type: slot
- label: Timestamp
type: class
type: class
processed:
status: true
timestamp: '2026-01-17T22:07:00Z'
session: session-2026-01-17-slot-migration
notes: |
DOMAIN_SPECIFIC_MEDIA_TIMING: chapter_start_time is appropriate as string:
- slot_uri: hc:chapterStartTime
- Range: string (ISO 8601 duration format, e.g., "PT2M30S")
This is a display/serialization format derived from chapter_start_seconds.
ISO 8601 duration strings are the standard for time representation.
Creating TimeInterval+Timestamp classes would be OVER-ENGINEERING.
Retaining with existing structure.