RiC-O 1.1 conformance audit — openric/spec

✅ STATUS — REMEDIATION COMPLETE (v0.37.0, 2026-04-25)

All five remediation phases (A → E) below have been applied. The original audit found 110 of 168 distinct rico:* tokens were not in RiC-O 1.1; after remediation, zero genuine emit-context uses of unsupported rico:* terms remain. The 7-10 rico:* mentions that still appear in a repo-wide token scan are exclusively inside “MUST NOT emit X” documentation prose — correct text, not violations.

The body of this document below is preserved for forensic / audit-history purposes — it is the complete record of what was found, what was decided per term, and how each phase was applied. New readers should focus on the ✅ phase-status markers in §Migration plan; the 478-canonical-vs-110-missing numbers reflect the pre-remediation state, not current.

Generated: 2026-04-24 · Remediation completed: 2026-04-25 · Catalyst: ICA-EGAD reviewer feedback (April 2026) · Canonical ontology: RiC-O 1.1, 2025-05-22 — 102 classes, 316 object properties, 60 datatype properties, 23 annotation properties.

Method

1. Fetched canonical RiC-O 1.1 RDF from ICA-EGAD/RiC-O (master branch, ontology/current-version/RiC-O_1-1.rdf).
2. Extracted every term declared via owl:(Class|ObjectProperty|DatatypeProperty|AnnotationProperty|NamedIndividual) rdf:about="...#X" → 478 canonical terms. Cross-verified against the Fuseki-loaded copy (same count).
3. Scanned every .md .ttl .json .jsonld .html .yml .xml file in the openric/spec repo for rico:[A-Za-z_][A-Za-z0-9_]* tokens → 168 distinct terms used.
4. Set-diff: 58 exist in RiC-O 1.1, 110 do not.
5. For every missing term, proposed a disposition with confidence flag. Every RENAME target was cross-checked against the canonical set to catch false targets — 13 of my first-pass suggestions were wrong (proposed targets that don’t exist in 1.1) and were corrected before this document was written.

Summary

• DROP: 2
• RENAME: 36
• REMODEL: 25
• EXTENSION: 46
• REVIEW: 1
• Total missing: 110
• Total OK (kept as-is): 58

Extension namespace proposal

@prefix openricx: <https://openric.org/ns/ext/v1#> .

Versioned from day one (/v1#) so we can evolve without breaking implementers — same pattern RiC-O itself uses. Ontology stub lives at /ns/ext/v1.ttl with human docs under /ns/ext/v1/.

Full disposition table

Things I am explicitly NOT 100% sure of

Every row with confidence low or medium in the table. Specifically:

• hasPlace — appears in many call sites with different meanings (birth place, place of origin, associated place, tookPlaceAt). Each use site needs individual review before rename.
• hasAgentName / hasPlaceName — the name classes exist in 1.1, but no direct linking property. May need an agentName_role / RDF-star reification approach.
• Production / Accumulation — should remodel to Activity + hasActivityType, but the expected activity-type vocabulary needs alignment with RiC-AG.
• hasOrHadPlaceOfOrigin — used in 289 triples of the live reference data but not declared in RiC-O 1.1. Either a historical property that was removed, or the reference data was generated against a non-conformant mapping. Needs confirmation from the reviewer.
• description — RiC-O 1.1 does not define rico:description. Use dcterms:description or mint openricx:description? Both are defensible.
• textualValue — my first extraction flagged it missing; the second (strict) found it IS in RiC-O 1.1. The audit numbers above assume textualValue is missing, so the true counts may be marginally better than reported.

Upstream proposals (for ICA-EGAD)

Candidates for GitHub issues against ICA-EGAD/RiC-O:

• hasFindingAid — link a RecordResource to its finding aid document.
• hasAppraisalInformation — capture appraisal rationale.
• containsPersonalData — privacy-compliance flag.
• ContactPoint class + address fields — first-class contact modelling.

Migration plan

Phased so each PR is small enough to review:

1. A — version strings. ✅ Shipped 2026-04-24 (commit 47c6581). Every ‘RiC-O v1.0’ → ‘v1.1’ and every 1.0 link → 1.1. Zero semantic change.
2. B — HIGH-confidence RENAMEs / DROPs / cross-namespace. ✅ Applied 2026-04-25 (uncommitted). 20 pure renames + 3 cross-namespace (Vocabulary→skos:ConceptScheme, hasBroaderConcept→skos:broader, conformsTo→dcterms:conformsTo) + 2 DROPs (isOrWasXxxOf, someInternalMarker) across 38 files, 129 occurrences. Held back: rico:hasSource (4 hits all in Rule attribution context, not rico:Relation source — needs Phase D semantic decision, likely dcterms:source); rico:isOrWasFollowedBy (medium-confidence in audit table — defer to Phase D). Result: 110 → 86 missing rico:* terms.
3. C — extension namespace. ✅ Applied 2026-04-25 (uncommitted). openricx: <https://openric.org/ns/ext/v1#> declared in mapping.md, 5 SHACL shape files, and 14 JSON-LD fixture @context blocks. All 46 EXTENSION rows renamed (rico:X → openricx:X), 244 occurrences. For the OR cases (description 25 uses, hasMimeType 11 uses), the openricx: option was taken; the dcterms:description / dcterms:format substitution can be revisited as Phase D refinement. Three response-shape fixtures (relations-for-place, record-list, revision-list) carry openricx: CURIEs as plain string values (not real JSON-LD with @context); they need a broader response-envelope cleanup in Phase D. Result: 86 → 39 missing rico:* terms.
4. D — REMODEL rows + held RENAMEs + ICA-EGAD-confirmed tweaks. ✅ Applied 2026-04-25 (uncommitted). Sub-phases:
   • D.1 — additional mechanical RENAMEs against verified canonical 1.1 targets: hasAgentName→hasOrHadAgentName, hasPlaceName→hasOrHadPlaceName, isOrWasFollowedBy→followsInTime, precedes→precedesInTime, succeeds→followsInTime, hasCarrier→hasCarrierType, hasMandate→authorizingMandate, hasRecordPart→includesOrIncluded, isContainedIn→isOrWasIncludedIn, dateOfEstablishment→hasBeginningDate, tookPlaceAt→isAssociatedWithPlace, predicate→rdf:predicate. 12 terms, 59 occurrences. (Audit had marked hasAgentName/hasPlaceName as REMODEL low-conf; re-verification against canonical-strict.txt found hasOrHadAgentName/hasOrHadPlaceName ARE in 1.1.)
   • D.2 — Holder/Location family: heldBy→hasOrHadHolder, isOrWasHeldBy→hasOrHadHolder, isOrHasCurrentCustodian→hasOrHadHolder, hasHolding→isOrWasHolderOf (inverse property to preserve direction), isOrWasLocatedAt→hasOrHadLocation. 5 terms, 19 occurrences. No data flips needed — RDF inspection confirmed canonical directions match OpenRiC’s existing usage; audit’s “inverse direction” warning was overcautious.
   • D.3 — Activity+hasActivityType remodel. RiC-O 1.1 has no concrete rico:Production / rico:Accumulation / rico:CustodyEvent / rico:Transfer / rico:ProductionActivity classes (audit’s most-cited gap). Replaced 5 class assertions in 3 fixtures with @type: rico:Activity + rico:hasActivityType IRIs from new <https://openric.org/vocab/activity-type/{production,accumulation,custody,transfer,publication,reproduction}> vocabulary. SHACL targetClass declarations rewritten as sh:SPARQLTarget filtering on Activity + hasActivityType IRI (6 targets across 3 shape files). Mapping spec §6.5 fully rewritten. Provenance-event and Authority & Context profile docs rewritten to reflect single-class model. ICA-EGAD endorsement: Florence Clavaud (RiC user group thread #27 on digitisation) explicitly recommends this exact pattern: rico:Activity + hasActivityType + ActivityType with rico:isOrWasPerformedBy + rico:Mechanism.
   • D.4 — Rule-regulation property remodel: hasAccessRestriction/hasAccessRule/hasSecurityClassification → rico:isOrWasRegulatedBy. Mapping spec §9 rewritten with new SKOS rule-type vocabulary at <https://openric.org/vocab/rule-type/>. (No actual class assertions of AccessRestriction / SecurityClassification existed in fixtures, so no fixture rewrite needed.)
   • D.5 — Provenance: hasAcquisitionProvenance (2) and wasAcquiredFrom (1) both → rico:hasOrganicProvenance. Direction verified against canonical RDF — both source properties had Record→Agent direction matching hasOrganicProvenance.
   • D.6 — Function class + per-call-site reviews: rico:Function (23) → openricx:Function (interim, with §6.4 documenting canonical alternatives per Florence/Garance review §10.7); rico:hasPlace (5) → rico:isAssociatedWithPlace (canonical Thing→Place, works for Agent via Thing superclass); openricx:hasFindingAid (3) → rico:isOrWasDescribedBy with rico:hasDocumentaryFormType <…#FindingAid> per Florence Clavaud KM Q&A #1 (FindingAid is a DocumentaryFormType SKOS individual, not a separate property).
   • D.7 — rico:hasSource (held from B; 4 uses, all in Rule citation context) → dcterms:source. Standard Dublin Core attribution.
   • D.8 — spec/mapping.md §6.2 (Actor → Agent) extended with mechanism → rico:Mechanism. New §10 (“Systems, APIs, and Mechanisms”) explains the API-surface vs application-concept vs canonical-RiC-entity distinction, the rico:Mechanism pattern for software systems / importers / OCR / AI / migration scripts, and provides a worked Turtle example. Endorsed by both Florence Clavaud (KM #27 — “scanner or digital camera”) and the Garance review document §10.8 (importer / OCR / AI / migration → Mechanism).
   • Result: 39 → 10 distinct missing tokens. Of the 10, 6 are intentional documentation prose (Production, Accumulation, CustodyEvent, Transfer, Function, hasActivity — appear only in “MUST NOT emit X” warnings explaining removed terms). The remaining 4 genuine Phase E candidates are hasOccupation (audit: REMODEL OccupationType+relation, low-conf), hasReasonForExecution (REMODEL low-conf), isOrWasControlledBy (REMODEL medium-conf, AgentControlRelation+role), and value (REVIEW too generic).
5. E — REVIEW rows + remaining low-confidence remodels. ✅ Applied 2026-04-25 (uncommitted).
   • E.1 — rico:hasOccupation (2 uses) → openricx:hasOccupation shortcut to a SKOS OccupationType Concept. Per Aaron+Florence KM Q&A #20, occupations are SKOS individuals of rico:OccupationType (an ActivityType subclass). Mapping spec §5.2.5 row updated; agent.schema.json field renamed.
   • E.2 — rico:hasReasonForExecution (1 use, provenance-event.md Optional list) → replaced with rico:authorizingMandate → rico:Mandate (canonical 1.1, used for the legal/policy basis of an event).
   • E.3 — rico:isOrWasControlledBy (1 use, mapping.md §8 relations table) → rico:hasOrHadController (canonical 1.1, Agent → Agent, same direction). Mapping note added that rico:AgentControlRelation reification is available for date-scoping.
   • E.4 — rico:value (1 use, hypothetical example for openricx:Checksum in digital-object-linkage.md Q2 rationale) → openricx:checksumValue (extension property since the entire Checksum class is an OpenRiC extension).
   • Result: 10 → 7 remaining tokens. All 7 are now confirmed intentional documentation prose in “MUST NOT emit X” / “X is not in 1.1” warnings explaining the remediation: rico:Production, rico:Accumulation, rico:CustodyEvent, rico:Transfer, rico:Function, rico:hasActivity, rico:hasReasonForExecution. Zero genuine emitted-context uses of unsupported rico:* terms remain.
6. F — upstream proposals. Issues against ICA-EGAD/RiC-O. Candidates from audit:
   • hasFindingAid — withdrawn, resolved via canonical pattern in D.6 (isOrWasDescribedBy + hasDocumentaryFormType <…#FindingAid>).
   • hasAppraisalInformation — open candidate (currently openricx:hasAppraisalInformation).
   • containsPersonalData — open candidate (currently openricx:containsPersonalData); privacy-compliance flag.
   • ContactPoint class + address fields — open candidate (currently openricx:ContactPoint).
   • SKOS publication of OpenRiC vocabularies (activity-type/, rule-type/, function-type/) at the https://openric.org/vocab/ namespace, plus dereferenceable https://openric.org/ns/ext/v1# ontology stub for openricx:. These close the audit’s v1.0 reviewer-checklist row “Extension namespace exists — dereferences to human and machine documentation.”

Source data

Working files under /tmp/ric-o-audit/ on the build host:

• ric-o-1.1.rdf — canonical ontology (1.7 MB)
• canonical-strict.txt — 478 canonical terms
• repo-rico-terms.txt — 168 terms used in this repo
• MISSING-strict.txt — the 110 missing
• OK-strict.txt — the 58 present
• MISSING-usage.tsv — per-term file list and occurrence count