# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-02T15:37:55Z", "synthesisSha256": "1a5797bf3e8265c50a38dfe229c372d0bd450702740ff94a6e9835e2ce53c9ee", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-KNW-006", "registryId": "vr.wm-knw-006", "name": "Concept / Term", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "entity", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.KNW.CON" ], "tags": [ "concept", "term", "inf.knw.con" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-knw-006-concept-term/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-knw-006", "model": { "registry_id": "vr.wm-knw-006", "model_id": "WM-KNW-006", "name": "Concept / Term", "entry_kind": "entity", "purpose": "Represent a stable, identified semantic concept as a unit of thought that is independent of any label, language or storage format, together with the designations, definitions, notes and usage descriptions that describe it, so that agents and systems can refer to the same meaning across languages, vocabularies and interfaces.", "scope_statement": "WM-KNW-006 models the concept as an aggregate root with its own persistent identity, plus the subordinate or referenced descriptions that give it meaning: designations (terms, appellations, proper names, symbols) with acceptability ratings, lexical entries and word forms, definitions and typed notes, subject field, referents and usage context; the concept's placement in concept schemes and its hierarchical, associative and cross-scheme mapping relations; and its lifecycle, provenance, ownership, editorial governance, access policy references and quality assertions. The model is format-neutral: RDF/SKOS, TBX, OntoLex, JSON, YAML, Markdown, Git, MCP and document stores are projections of the same semantics. External standards are treated as alignments, not as conformance claims.", "in_scope": [ "Concept identity: authoritative identifier, governed IRI, notation, and the rules that decide when a change breaks identity", "Concept delimitation: intension, extension, essential and delimiting characteristics, split/merge and duplicate tests", "Concept kind: general versus individual concept, and explicit separation from lexical entry, word form, sense, class/type, referent and free-text keyword", "Designations attached to the concept: term, appellation, proper name and non-linguistic symbol, with preferred/admitted/deprecated acceptability ratings and hidden retrieval-only labels", "Designation-level identity and attributes where terms are reified rather than carried as plain strings", "Language, script, region and variant tagging of every designation, definition and note, plus transliteration and romanization", "Lexical description at the designation boundary: lexical entry, canonical form, other forms, written and phonetic representation, grammatical categories", "Definitions and typed notes: scope note, example, general note, editorial note, and their attachment level", "Subject field assignment and homograph disambiguation across domains", "Referents and exemplars denoted by the concept, held as references to external entity records", "Usage context: audience, register, territory, discouraged usage and attested occurrences", "Multilingual equivalence asserted at the designation and sense boundary", "Concept scheme membership, top-concept status and scheme-scoped constraints", "Hierarchical, associative and instantial semantic relations between concepts", "Cross-scheme concept mappings and their degree of match", "Concept and designation lifecycle: status, supersession, deprecation, redirect and versioning", "Provenance, ownership, editorial authority and change history", "Access-policy references, quality assertions and validation profiles for concept records" ], "out_of_scope": [ "The real-world objects and entity records that a concept denotes; their attributes, identity resolution and lifecycle belong to domain entity models", "Formal ontology axiomatisation and reasoning: OWL/RDFS class semantics, restrictions, entailment and consistency checking", "Publication of a full lexical or lexicographic resource (dictionary entries, sense inventories, corpora, annotation layers) beyond the designation-level description carried here", "Documents, records and content items that merely mention or are indexed with a concept", "Search, retrieval, ranking and indexing engines that consume designations", "Translation-management workflow, translation memory segments and localisation project state", "Identifier minting and resolution infrastructure such as PID, handle or DOI services", "Runtime access-control evaluation, policy enforcement and audit-trail storage; this model carries policy and audit-record references only", "Machine-learning embeddings, vector representations and similarity models derived from concepts", "Retention scheduling, legal hold and physical destruction execution, which belong to the adopting Dimension's records policy" ], "boundary_notes": [ { "neighbor": "Lexical entry and word form (OntoLex-Lemon lexicon)", "distinction": "A lexical entry is a unit of the lexicon with grammatically related forms and base meanings; a concept is a unit of thought. This model attaches lexical entries and forms at the designation boundary and references the lexicon, but does not own the lexicon's entry inventory or its editorial lifecycle.", "source_refs": [ "SRC-004", "SRC-005" ] }, { "neighbor": "Class or type in a formal ontology", "distinction": "SKOS concepts are individuals of skos:Concept, not classes; the SKOS Primer records that OWL DL forbids treating them as classes. A concept record may be aligned with an owl:Class under a documented punning rule, but class axioms, restrictions and entailment stay in the ontology model.", "source_refs": [ "SRC-001", "SRC-003" ] }, { "neighbor": "Referent or real-world object", "distinction": "ISO 1087 separates the object (anything perceivable or conceivable) from the concept (a mental unit combining characteristics of objects). This model records which referents a concept denotes as references; the referent's own master data belongs elsewhere.", "source_refs": [ "SRC-005", "SRC-004" ] }, { "neighbor": "Concept scheme, thesaurus or controlled vocabulary (parent WM-KNW-002)", "distinction": "The scheme owns membership, top-concept designation, scheme versioning and scheme-wide editorial policy. A concept carries an inScheme reference; the same concept may participate in more than one scheme without the scheme's rules migrating into the concept record.", "source_refs": [ "SRC-001", "SRC-007" ] }, { "neighbor": "Free-text keyword or tag", "distinction": "A keyword is an uncontrolled string with no identity, no rating, no language governance and no definition. A designation in this model is always bound to an identified concept and carries a language tag and an acceptability rating.", "source_refs": [ "SRC-002", "SRC-005" ] }, { "neighbor": "Lexical sense (ontolex:LexicalSense)", "distinction": "A sense pairs one lexical entry with one reference; equivalence asserted sense-to-sense is narrower than equivalence asserted concept-to-concept. This model records which level an equivalence claim was made at, but does not maintain a sense inventory.", "source_refs": [ "SRC-004" ] }, { "neighbor": "Notation, code list and classification registry", "distinction": "skos:notation is a lexical code unique within a concept scheme, typed by datatype. The code list itself, its allocation rules and its release cycle are owned by the issuing registry, not by the concept record that cites the code.", "source_refs": [ "SRC-001", "SRC-003" ] }, { "neighbor": "Semantic relations, mappings, lifecycle, provenance, access and quality areas of WM-KNW-006", "distinction": "These are in scope for the combined model but are specified in separate areas. The semantic core carries only the identity-breaking trigger that forces a split or merge, reference-only pointers to rating authority and definition source, and no relation, status, approval or audit machinery of its own.", "source_refs": [ "SRC-001", "SRC-007", "SRC-008" ] } ] }, "sources": [ { "id": "SRC-001", "title": "SKOS Simple Knowledge Organization System Reference", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/skos-reference/", "version_or_date": "W3C Recommendation, 18 August 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:10:00Z", "relevance": "Normative definitions of skos:Concept, prefLabel/altLabel/hiddenLabel with integrity conditions S13 (pairwise disjoint) and S14 (at most one prefLabel per language tag), skos:notation (S15), and the documentation note properties definition, scopeNote, example, note, editorialNote, historyNote and changeNote." }, { "id": "SRC-002", "title": "SKOS Simple Knowledge Organization System eXtension for Labels (SKOS-XL), section of the SKOS Reference", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/skos-reference/skos-xl.html", "version_or_date": "W3C Recommendation, 18 August 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:12:00Z", "relevance": "Basis for treating a designation as an identified resource: skosxl:Label with exactly one skosxl:literalForm, skosxl:prefLabel/altLabel/hiddenLabel, and skosxl:labelRelation for relations between labels." }, { "id": "SRC-003", "title": "SKOS Simple Knowledge Organization System Primer", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/skos-primer/", "version_or_date": "W3C Working Group Note, 18 August 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:14:00Z", "relevance": "Guidance that concepts are units of thought distinct from the resources they denote, that SKOS concepts are OWL individuals rather than classes in OWL DL, the one-preferred-label-per-language-tag rule, notation styles, note typing, and the requirement to use BCP 47 language tags." }, { "id": "SRC-004", "title": "Lexicon Model for Ontologies: Community Report", "organization": "W3C Ontology-Lexica Community Group", "url": "https://www.w3.org/2016/05/ontolex/", "version_or_date": "Final Community Group Report, 10 May 2016", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T09:16:00Z", "relevance": "Defines LexicalEntry, Word, MultiwordExpression, Affix, Form with canonicalForm/otherForm/writtenRep/phoneticRep, LexicalSense, LexicalConcept as a subclass of skos:Concept, and the denotes/reference/sense/evokes properties that fix the concept-designation-sense-referent boundary." }, { "id": "SRC-005", "title": "MVF ISO 1087 Vocabulary for Terms and Definitions (RDF)", "organization": "Object Management Group (OMG)", "url": "https://www.omg.org/spec/MVF/ISO1087-VocabularyForTermsAndDefinitions.rdf", "version_or_date": "OMG-published RDF rendering accompanying MVF 1.1, retrieved 2026-09-02", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T09:06:00Z", "relevance": "Publicly retrievable rendering of the ISO 1087 vocabulary: object, concept, designation, term, appellation, symbol, proper name, definition, essential and delimiting characteristic, preferred/admitted/deprecated term, subject field and concept system. Used as the evidence route for ISO 1087 notions because the standard's clause text is paywalled." }, { "id": "SRC-006", "title": "Multiple Vocabulary Facility (MVF) specification page", "organization": "Object Management Group (OMG)", "url": "https://www.omg.org/spec/MVF/", "version_or_date": "Version 1.1 beta, April 2026", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T09:30:00Z", "relevance": "Specification for expressing one model element through multiple natural languages and terminologies, with normative mappings to ISO 1087 and SKOS; supports the separation of concept entry, vocabulary and designation and the machine-readable RDF/TTL delivery of terminology." }, { "id": "SRC-007", "title": "ISO 25964 — the international standard for thesauri and interoperability with other vocabularies", "organization": "National Information Standards Organization (NISO)", "url": "https://www.niso.org/schemas/iso25964", "version_or_date": "Part 1 published 2011, Part 2 published 2013; SKOS correspondence published 11 December 2013", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T09:08:00Z", "relevance": "Maintenance page for the ISO 25964 data model, its XML schema and the published correspondence between ISO 25964, SKOS, SKOS-XL and MADS; establishes the reified thesaurus-term view of designations and the preferred/non-preferred distinction." }, { "id": "SRC-008", "title": "SKOS-Thes: ISO 25964 SKOS extension namespace documentation", "organization": "Dublin Core Metadata Initiative (hosting the ISO 25964 SKOS extension by A. Isaac and J. De Smedt)", "url": "https://www.dublincore.org/specifications/skos-thes/ns/", "version_or_date": "Namespace http://purl.org/iso25964/skos-thes, dated 2015-03-17", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T09:26:00Z", "relevance": "Machine-readable classes PreferredTerm, SimpleNonPreferredTerm, SplitNonPreferredTerm, CompoundEquivalence, ConceptGroup and ThesaurusArray, and the status data property applying to concepts or labels; documents that custom term and concept attributes remain unmodelled." }, { "id": "SRC-009", "title": "RFC 5646: Tags for Identifying Languages (BCP 47)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5646.html", "version_or_date": "Best Current Practice 47, September 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:18:00Z", "relevance": "Normative subtag order (language, extlang, script, region, variant, extension, private use), the IANA Language Subtag Registry with Deprecated, Preferred-Value, Prefix and Suppress-Script fields, and the guidance not to state a script subtag that is suppressed for the language." }, { "id": "SRC-010", "title": "ISO 15924 Registration Authority — Codes for the representation of names of scripts", "organization": "Unicode Consortium (ISO 15924 Registration Authority)", "url": "https://www.unicode.org/iso15924/", "version_or_date": "ISO 15924:2022; code list maintained and distributed by the Registration Authority, retrieved 2026-09-02", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:20:00Z", "relevance": "Authoritative source of four-letter script codes and their maintenance process; supplies the value space for the script subtag used on designations, definitions and notes." }, { "id": "SRC-011", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339.html", "version_or_date": "Standards Track, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:28:00Z", "relevance": "Defines full-date, full-time and the mandatory seconds field plus the time-offset as Z or +/-hh:mm, and notes that -00:00 differs semantically from Z; used for the model's timestamp rule." }, { "id": "SRC-012", "title": "Introduction to TermBase eXchange (TBX)", "organization": "TBX Info (complement to ISO 30042, maintained with LTAC Global)", "url": "https://www.tbxinfo.net/", "version_or_date": "TBX Version 3 published 2019 as ISO 30042:2019; site retrieved 2026-09-02", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T09:22:00Z", "relevance": "First-party description of concept-oriented terminological interchange, the TBX-Core, TBX-Min and TBX-Basic dialects and modules, and the publicly available RNG, XSD and Schematron validation artefacts; grounds the interchange-profile and loss-report functions." }, { "id": "SRC-013", "title": "ISO 1087:2019 Terminology work and terminology science — Vocabulary", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/62330.html", "version_or_date": "Second edition, 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:24:00Z", "relevance": "Catalogue entry cited as the origin of the terminology-science vocabulary used here. Automated retrieval of this page returned HTTP 403 and the clause text is paywalled, so no clause is quoted or relied upon directly; every ISO 1087 notion used in this model is evidenced through the publicly retrievable OMG rendering SRC-005." }, { "id": "SRC-014", "title": "XKOS: An SKOS extension for representing statistical classifications", "organization": "DDI Alliance", "url": "https://rdf-vocabulary.ddialliance.org/xkos.html", "version_or_date": "XKOS version 1.0 (DDI Alliance published vocabulary)", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T09:26:00Z", "relevance": "Defines ClassificationLevel, levels, depth and numberOfLevels; Correspondence, ConceptAssociation, compares, sourceConcept and targetConcept for many-to-many cross-scheme and cross-version mapping; and refined relations specializes/generalizes, isPartOf/hasPart, causal, sequential (precedes/succeeds transitive, previous/next non-transitive) and temporal before/after." }, { "id": "SRC-015", "title": "OWL 2 Web Ontology Language Primer (Second Edition)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/owl2-primer/", "version_or_date": "W3C Recommendation, 11 December 2012", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:31:00Z", "relevance": "Establishes the entailment consequences of owl:equivalentClass, rdfs:subClassOf (transitive and reflexive), owl:sameAs and owl:disjointWith, and the distinction between class equivalence and individual identity - the basis for treating an alignment predicate as a commitment rather than a label." }, { "id": "SRC-016", "title": "RDF 1.1 Concepts and Abstract Syntax", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/rdf11-concepts/", "version_or_date": "W3C Recommendation, 25 February 2014", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:33:00Z", "relevance": "Grounds format neutrality: the abstract syntax of IRIs, literals, language-tagged strings, triples, graphs and datasets is independent of concrete serialization, and IRIs have global scope so two appearances denote the same resource." }, { "id": "SRC-017", "title": "Best Practice Recipes for Publishing RDF Vocabularies", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/swbp-vocab-pub/", "version_or_date": "W3C Working Group Note, 28 August 2008", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T09:37:00Z", "relevance": "Guidance on hash versus slash namespace design, dereferenceable term identifiers, content negotiation and keeping term identifiers stable while version information moves into the served document - the basis for namespace and identifier-resolution rules in interchange." }, { "id": "SRC-018", "title": "ANSI/NISO Z39.19-2005 (R2010) Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies", "organization": "National Information Standards Organization (NISO)", "url": "https://www.niso.org/publications/ansiniso-z3919-2005-r2010", "version_or_date": "ANSI/NISO Z39.19-2005, reaffirmed 2010", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:40:00Z", "relevance": "US national standard for the contents, display, construction, testing, maintenance and management of monolingual controlled vocabularies (lists, synonym rings, taxonomies, thesauri); cited as an independent authority that controlled-vocabulary relationship structure is standardised practice, not local convention. The full normative text is behind a download and its clause-level rules were not verified here." }, { "id": "SRC-019", "title": "Data Catalog Vocabulary (DCAT) - Version 3", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vocab-dcat-3/", "version_or_date": "W3C Recommendation, 22 August 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T09:43:00Z", "relevance": "Defines dcat:themeTaxonomy as a knowledge organization system used to classify catalogued resources and dcat:theme as a category, and recommends that such taxonomies be organised as a skos:ConceptScheme, skos:Collection, owl:Ontology or similar so each member is denoted by an IRI - evidence for external consumption of schemes and for the catalogue boundary." }, { "id": "SRC-020", "title": "PROV-O: The PROV Ontology", "organization": "W3C", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T08:12:00Z", "relevance": "Entity/Activity/Agent, wasGeneratedBy, wasDerivedFrom, wasRevisionOf, wasAttributedTo, actedOnBehalfOf, generatedAtTime and invalidatedAtTime, plus the qualified-influence pattern. Grounds provenance, derivation, attribution and delegation for governance events." }, { "id": "SRC-021", "title": "Data on the Web Best Practices", "organization": "W3C", "url": "https://www.w3.org/TR/dwbp/", "version_or_date": "W3C Recommendation 31 January 2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T08:16:00Z", "relevance": "BP4 licensing, BP5 provenance, BP6 quality, BP7 version indicator, BP8 complete version history, BP9 persistent URI, BP10 URI reuse, BP11 URIs for versions and series, BP27 preserve identifiers. Directly grounds versioning, provenance, licensing, quality and identifier persistence requirements." }, { "id": "SRC-022", "title": "Shapes Constraint Language (SHACL)", "organization": "W3C", "url": "https://www.w3.org/TR/shacl/", "version_or_date": "W3C Recommendation 20 July 2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T08:18:00Z", "relevance": "ValidationReport with sh:conforms, ValidationResult with focusNode, resultPath, sourceShape and resultSeverity (Violation/Warning/Info), and the shapes-graph versus data-graph separation. Grounds the validation report artifact and the blocking-versus-advisory severity split without claiming ownership of evaluation." }, { "id": "SRC-023", "title": "Data Quality Vocabulary (DQV)", "organization": "W3C", "url": "https://www.w3.org/TR/vocab-dqv/", "version_or_date": "W3C Group Note 15 December 2016", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T08:20:00Z", "relevance": "QualityMeasurement, Metric, Dimension, Category, QualityAnnotation, QualityCertificate and QualityPolicy, aligned to PROV and DCAT. Grounds editorial quality measurement as dimension-plus-metric rather than an opaque score. It is a Note, not a Recommendation." }, { "id": "SRC-024", "title": "DCMI Metadata Terms", "organization": "Dublin Core Metadata Initiative (DCMI)", "url": "https://www.dublincore.org/specifications/dublin-core/dcmi-terms/", "version_or_date": "DCMI Recommendation, 2020-01-20", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T08:22:00Z", "relevance": "license, accessRights, rightsHolder, provenance, created, issued, modified, valid, replaces, isReplacedBy, source and bibliographicCitation. Grounds rights, access, custody-change provenance, effective validity and supersession pointers." }, { "id": "SRC-025", "title": "RFC 8785: JSON Canonicalization Scheme (JCS)", "organization": "IETF", "url": "https://www.rfc-editor.org/rfc/rfc8785", "version_or_date": "RFC 8785, June 2020", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T08:26:00Z", "relevance": "Deterministic property ordering by UTF-16 code unit, ECMAScript number serialisation and defined string escaping, so hashing and signing are reliably repeatable. Grounds the canonical-form and digest re-derivation rules for structured artifacts." }, { "id": "SRC-026", "title": "ISO/IEC 11179-6:2023 Information technology — Metadata registries (MDR) — Part 6: Registration", "organization": "ISO/IEC", "url": "https://www.iso.org/standard/78916.html", "version_or_date": "Fourth edition, 2023 (cancels and replaces ISO/IEC 11179-6:2015)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T08:30:00Z", "relevance": "Defines information, conditions and procedures for registering administered items, distinguishes lifecycle from documentation registration status categories, requires all mandatory attributes and associations for Recorded, requires steward sponsorship plus registration-authority approval to reach Qualified or higher, and requires retirement procedures. Full text is paywalled; the catalogue record and standards-body summaries were used." }, { "id": "SRC-027", "title": "OBO Foundry Principle 4: Versioning", "organization": "OBO Foundry", "url": "https://obofoundry.org/principles/fp-004-versioning.html", "version_or_date": "OBO Foundry principle, page accessed 2026-09-02", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T08:34:00Z", "relevance": "Each release must have a resolvable version IRI whose identifier string matches the artifact, versioned PURLs must resolve in perpetuity, and the content of released files MUST NOT be changed — bugs are fixed in a new release. Grounds immutable releases and durable version resolution." }, { "id": "SRC-028", "title": "Obsoleting an Existing Ontology Term (OBO Academy / OBOOK)", "organization": "OBO Foundry", "url": "https://oboacademy.github.io/obook/howto/obsolete-term/", "version_or_date": "OBOOK how-to guide, page accessed 2026-09-02", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-02T08:36:00Z", "relevance": "owl:deprecated marking, OBSOLETE label prefix, IAO:0100001 term-replaced-by for successors, oboInOwl:consider for advisory alternatives, obsolescence-reason IRIs including terms-merged and term-split, and the rule that identifiers are never deleted or reused. Grounds deprecation, merge, split and redirect handling." }, { "id": "SRC-029", "title": "Asset Description Metadata Schema (ADMS)", "organization": "W3C", "url": "https://www.w3.org/TR/vocab-adms/", "version_or_date": "W3C Working Group Note 1 August 2013; retired August 2023, maintained by SEMIC", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-02T08:38:00Z", "relevance": "adms:status pointing at a SKOS-controlled workflow status, adms:prev/next/last version chain and adms:versionNotes describing changes between versions. Its retirement as a W3C Note is recorded as a conflict/drift risk." }, { "id": "SRC-030", "title": "ODRL Information Model 2.2", "organization": "W3C", "url": "https://www.w3.org/TR/odrl-model/", "version_or_date": "W3C Recommendation 15 February 2018", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-02T08:40:00Z", "relevance": "Policy (Set, Offer, Agreement), Permission, Prohibition, Duty, Constraint with temporal and spatial refinements, Asset, Party and Action. Grounds machine-readable licence, embargo and access constraints carried as references without local enforcement." }, { "id": "SRC-031", "title": "Semantic Versioning 2.0.0", "organization": "Semantic Versioning (semver.org)", "url": "https://semver.org/spec/v2.0.0.html", "version_or_date": "Version 2.0.0", "source_type": "standard", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-09-02T08:42:00Z", "relevance": "MAJOR for incompatible changes, MINOR for backward-compatible additions, PATCH for backward-compatible fixes, RFC 2119 keywords, and the rule that a released version's contents MUST NOT be modified. Used as a de facto convention for change classification, with its API orientation recorded as a conflict." } ], "structure": { "bundles": [ { "id": "ct-core-identity-bundle", "name": "Concept identity and delimitation", "description": "What makes this concept a single, citable unit of thought: how it is identified, what fixes its boundaries against neighbouring concepts, what kind of concept it is, and which real-world referents it denotes.", "rationale": "ISO 1087 and SKOS both treat the concept, not the label, as the unit that carries identity; SKOS notation is scheme-scoped and labels are language-scoped, so neither can serve as the identifier. Delimitation by essential and delimiting characteristics is the only defensible test for whether two records are the same concept.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005" ], "layers": [ { "id": "ct-core-identity-layer", "name": "Identity and delimitation", "description": "Identifier assignment and the intensional and extensional criteria that fix the concept's boundary and drive split, merge and duplicate decisions.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008" ], "findings": [ { "id": "ct-core-concept-identity", "name": "Concept identifier and identity basis", "description": "The concept holds a persistent identifier independent of any label, definition wording, language or scheme. Records the assigning master system, an optional governed IRI, scheme-scoped notations, and the rule set that separates identity-preserving edits from identity-breaking changes.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005", "SRC-008" ], "questions": [ { "id": "ct-core-q-identity-master", "text": "Which authoritative master system assigns this concept's primary identifier, and what is that identifier value?", "kind": "identity", "answer_data": [ "Assigning system or registry name", "Primary identifier value", "Identifier scheme or syntactic pattern" ] }, { "id": "ct-core-q-identity-iri", "text": "Does the concept have a governed IRI, and which body controls the namespace it is minted in?", "kind": "interoperability", "answer_data": [ "Concept IRI", "Namespace base URI", "Namespace controlling body", "Dereferenceability status" ] }, { "id": "ct-core-q-identity-notation", "text": "Which notations or classification codes denote this concept, and in which coding scheme is each one valid?", "kind": "classification", "answer_data": [ "Notation string", "Notation datatype or coding-scheme identifier", "Scope of validity for the notation" ] }, { "id": "ct-core-q-identity-stability", "text": "Which changes preserve the identifier, and which force a new concept identifier rather than an edit?", "kind": "constraint", "answer_data": [ "List of identity-preserving change types", "List of identity-breaking change types", "Reference to the split or merge rule that applies" ] } ], "data_elements": [ { "id": "ct-core-de-concept-id", "name": "Concept primary identifier", "description": "Identifier assigned by the authoritative master system for the concept; never derived from a label, notation or date.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "ct-core-de-concept-iri", "name": "Governed concept IRI", "description": "Dereferenceable IRI in a namespace controlled by a named authority, used for linked-data projections.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "ct-core-de-notation", "name": "Notation", "description": "Typed lexical code that denotes the concept within a stated coding scheme; unique within that scheme only.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "ct-core-de-identity-rule-ref", "name": "Identity rule reference", "description": "Reference to the documented rule set that decides identity-breaking versus identity-preserving change for this vocabulary.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Identity is pure reference data. Identifiers, namespaces and notations are literal values that every projection must carry inline; no media-bearing or form-bearing artifact would add meaning, and binding identity to a file would make the identifier depend on a storage format the model is explicitly independent of." }, { "id": "ct-core-concept-delimitation", "name": "Intension, extension and delimiting characteristics", "description": "The characteristics an object must have to fall under the concept, how far the extension reaches, and which characteristic distinguishes the concept from its nearest confusable neighbour. Supplies the operational test for duplicate detection and for split and merge decisions.", "source_refs": [ "SRC-005", "SRC-006", "SRC-003" ], "questions": [ { "id": "ct-core-q-delim-essential", "text": "Which essential characteristics must an object have for it to fall under this concept?", "kind": "definition", "answer_data": [ "Ordered list of essential characteristics", "Characteristic type (kind, part, purpose, origin)", "Whether each characteristic is asserted locally or taken from a source standard" ] }, { "id": "ct-core-q-delim-distinguish", "text": "Which delimiting characteristic separates this concept from the nearest concept it is confused with?", "kind": "constraint", "answer_data": [ "Delimiting characteristic statement", "Identifier of the confusable concept", "Directionality of the distinction" ] }, { "id": "ct-core-q-delim-extension", "text": "How is the extension bounded — open, enumerated or sampled by exemplars?", "kind": "composition", "answer_data": [ "Extension boundedness code", "Enumerated member references where applicable", "Sampling or exemplar policy" ] }, { "id": "ct-core-q-delim-evidence", "text": "What evidence supports this delimitation — attested usage, expert ruling or a cited source clause?", "kind": "evidence", "answer_data": [ "Evidence type", "Source reference or clause citation", "Evidence strength assessment" ] }, { "id": "ct-core-q-delim-duplicate", "text": "When two records share designations, which test decides whether they are one concept or two?", "kind": "decision", "answer_data": [ "Duplicate-test procedure reference", "Decision outcome", "Deciding characteristic that carried the outcome" ] } ], "data_elements": [ { "id": "ct-core-de-characteristic", "name": "Characteristic", "description": "A single characteristic asserted of the concept, typed as essential or non-essential.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "ct-core-de-delimiting-characteristic", "name": "Delimiting characteristic", "description": "Essential characteristic used to distinguish this concept from a stated related concept.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "ct-core-de-extension-kind", "name": "Extension boundedness", "description": "Code stating whether the concept's extension is open, enumerated or exemplar-sampled.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Characteristics and delimitation statements are short structured assertions consumed by reasoning and duplicate-detection logic. Externalising them as artifacts would hide the very data the split or merge decision depends on and would prevent constraint evaluation over the record itself." } ] }, { "id": "ct-core-boundary-layer", "name": "Concept kind and referents", "description": "Typing the record against its neighbours and recording which real-world objects it denotes, without absorbing those objects' own master data.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005" ], "findings": [ { "id": "ct-core-concept-kind", "name": "Concept kind and neighbour typing", "description": "Classifies the record as a general concept covering many objects or an individual concept covering exactly one, and asserts explicitly what it is not: not a lexical entry, not a word form, not a sense, not an OWL or RDFS class, not the referent, and not a free-text keyword. Prevents category errors during projection.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-005" ], "questions": [ { "id": "ct-core-q-kind-general", "text": "Is this a general concept covering many objects, or an individual concept covering exactly one?", "kind": "classification", "answer_data": [ "Concept kind code (general or individual)", "Justification statement", "Whether a proper name designates it" ] }, { "id": "ct-core-q-kind-owl", "text": "When projected into a formal ontology, is this an individual of skos:Concept, an owl:Class, or both under a documented punning rule?", "kind": "interoperability", "answer_data": [ "Projection typing decision", "OWL flavour assumed (OWL Full or OWL DL)", "Reference to the punning rule if both are asserted" ] }, { "id": "ct-core-q-kind-conflation", "text": "Which neighbouring construct — lexical entry, word form, sense, referent, class or keyword — has previously been conflated with this record?", "kind": "exception", "answer_data": [ "Conflated construct type", "Where the conflation occurred (system or profile)", "Corrective rule applied" ] }, { "id": "ct-core-q-kind-keyword", "text": "What distinguishes this concept record from an uncontrolled keyword or tag carrying the same string?", "kind": "definition", "answer_data": [ "Governance attributes the keyword lacks", "Identifier and language-tag presence", "Acceptability rating presence" ] } ], "data_elements": [ { "id": "ct-core-de-concept-kind", "name": "Concept kind", "description": "Code distinguishing a general concept from an individual concept.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "ct-core-de-ontology-typing", "name": "Ontology projection typing", "description": "Declared typing used when the concept is projected into RDF or OWL, including the OWL flavour assumed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "ct-core-de-not-a-assertion", "name": "Negative typing assertion", "description": "Explicit statement of a neighbouring construct that this record is not, retained to prevent recurring conflation.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Typing decisions are single-valued codes and short justifications that must be readable by validators before any projection is attempted; there is no media form in which they could sensibly be held." }, { "id": "ct-core-referent-denotation", "name": "Referents, exemplars and denotation", "description": "Which objects or entity records the concept denotes, and which exemplars illustrate it without being equated with it. Keeps the ISO 1087 object and concept split and the OntoLex reference and evokes split intact, holding referents as external references only.", "source_refs": [ "SRC-004", "SRC-005", "SRC-003" ], "questions": [ { "id": "ct-core-q-ref-denotes", "text": "Which real-world objects or entity records does this concept denote, and in which model are those referents mastered?", "kind": "relationship", "answer_data": [ "Referent identifiers", "Mastering model or system name", "Denotation basis (extension membership or individual identity)" ] }, { "id": "ct-core-q-ref-exemplar", "text": "Which exemplar, type specimen or illustration is used to show the concept without being equated with it?", "kind": "evidence", "answer_data": [ "Exemplar artifact reference", "Exemplar role (typical, boundary, counterexample)", "Statement that the exemplar is not the concept" ] }, { "id": "ct-core-q-ref-direct", "text": "Does any designation denote the referent directly rather than through the concept, and how is that recorded?", "kind": "interoperability", "answer_data": [ "Designation identifier", "Direct-denotation flag", "Target ontology entity or sense reference" ] }, { "id": "ct-core-q-ref-excluded", "text": "What is explicitly not a referent of this concept despite being commonly assumed to be one?", "kind": "exception", "answer_data": [ "Excluded referent reference", "Reason for exclusion", "Concept that does cover it, where known" ] } ], "data_elements": [ { "id": "ct-core-de-referent-ref", "name": "Referent reference", "description": "Reference to an externally mastered object or entity record denoted by the concept.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "ct-core-de-exemplar-role", "name": "Exemplar role", "description": "Role played by an exemplar: typical instance, boundary case or explicit counterexample.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "ct-core-referent-exemplar", "name": "Referent exemplar record", "description": "Media or specimen record used to illustrate what falls under the concept, held separately from the concept so the illustration is never mistaken for the unit of thought.", "media_or_form": [ "still image", "technical diagram", "specimen or sample record", "short video" ], "serial": false, "identity_strategy": "The asset identifier assigned by the holding system takes priority; where none exists, a content hash of the exemplar file is used. The exemplar is linked to the concept identifier and never carries or substitutes for it.", "source_refs": [ "SRC-005", "SRC-004" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "ct-core-designation-bundle", "name": "Designations and linguistic form", "description": "The signs that represent the concept — terms, appellations, proper names and symbols — with their acceptability ratings, their own identity where needed, their language and script tagging, their lexical description, and cross-language equivalence at the designation boundary.", "rationale": "ISO 1087 treats designation as a construct distinct from concept, and SKOS constrains labels (at most one preferred label per language tag, pairwise disjoint label properties). SKOS-XL and ISO 25964 reify terms so that ratings, sources and grammatical data can attach to the designation rather than the concept; OntoLex supplies the lexical description layer.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005", "SRC-008" ], "layers": [ { "id": "ct-core-designation-layer", "name": "Designation inventory and identity", "description": "Which signs represent the concept, how they are rated and typed, and when a designation must become an identified object in its own right.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-008" ], "findings": [ { "id": "ct-core-designation-inventory", "name": "Designation inventory and acceptability rating", "description": "The set of designations attached to the concept, each typed as term, appellation, proper name or non-linguistic symbol, each rated preferred, admitted or deprecated, and each marked as displayed or hidden for retrieval only. Carries the uniqueness constraint on preferred designations per language tag.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-007", "SRC-008" ], "questions": [ { "id": "ct-core-q-desig-rating", "text": "Which designation is rated preferred in each language, and which are admitted, deprecated or hidden?", "kind": "classification", "answer_data": [ "Designation string or symbol reference", "Acceptability rating value", "Language tag", "Display or hidden flag" ] }, { "id": "ct-core-q-desig-type", "text": "What designation type is each sign — term, appellation, proper name or non-linguistic symbol?", "kind": "definition", "answer_data": [ "Designation type code", "Justification where the type is contested", "Whether a lexical entry exists for it" ] }, { "id": "ct-core-q-desig-authority", "text": "Which rating-authority reference is carried on the designation, given that the rating process itself is governed outside this area?", "kind": "authority", "answer_data": [ "Rating authority reference", "Acceptability rating scale identifier", "Pointer to the governing process record" ] }, { "id": "ct-core-q-desig-uniqueness", "text": "Can two designations share the same rating in one language, and which constraint prevents duplicate preferred labels?", "kind": "constraint", "answer_data": [ "Applicable uniqueness constraint identifier", "Profile decision where the constraint is relaxed", "Conflict-detection result" ] }, { "id": "ct-core-q-desig-symbol", "text": "Which non-linguistic symbol represents the concept, and in what medium is that symbol fixed?", "kind": "composition", "answer_data": [ "Symbol artifact reference", "Symbol medium or encoding", "Issuing authority for the symbol" ] } ], "data_elements": [ { "id": "ct-core-de-designation-string", "name": "Designation literal form", "description": "The written form of a linguistic designation, always carried with a language tag.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "ct-core-de-designation-type", "name": "Designation type", "description": "Code distinguishing term, appellation, proper name and symbol.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "ct-core-de-acceptability-rating", "name": "Acceptability rating", "description": "Rating of the designation as preferred, admitted or deprecated on a named scale.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "ct-core-de-hidden-flag", "name": "Hidden designation flag", "description": "Marks a designation as available to text-based retrieval but suppressed from display, for example a known misspelling.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] } ], "artifacts": [ { "id": "ct-core-designation-symbol", "name": "Non-linguistic symbol asset", "description": "Graphical or glyph asset that designates the concept by non-linguistic means, such as a hazard pictogram, unit symbol or standardised graphical symbol.", "media_or_form": [ "vector graphic", "raster image", "glyph or character reference", "printed plate or reproduction sheet" ], "serial": false, "identity_strategy": "The symbol identifier issued by the standardising authority takes priority; otherwise a content hash bound to the designation record identifier. The symbol asset never carries the concept identifier by itself.", "source_refs": [ "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "ct-core-designation-identity", "name": "Designation as an identified object", "description": "When a designation must carry its own attributes — rating history, defining source, grammatical data, relations to other designations — it is reified as an identified object rather than held as a plain string. Covers the SKOS-XL Label, the ISO 25964 preferred and non-preferred term classes and the TBX term section, and the constraint that a reified label has exactly one literal form.", "source_refs": [ "SRC-002", "SRC-007", "SRC-008", "SRC-012" ], "questions": [ { "id": "ct-core-q-desigid-identifier", "text": "Does this designation carry its own identifier, and which system assigns it?", "kind": "identity", "answer_data": [ "Designation identifier", "Assigning system", "Whether reification is required by the active profile" ] }, { "id": "ct-core-q-desigid-attributes", "text": "Which attributes are held on the designation rather than on the concept, and why does each belong there?", "kind": "composition", "answer_data": [ "Attribute names held at designation level", "Rationale per attribute", "Attributes deliberately kept at concept level" ] }, { "id": "ct-core-q-desigid-consistency", "text": "How is a plain-string projection kept consistent with the reified designation's single literal form?", "kind": "validation", "answer_data": [ "Consistency rule statement", "Detected divergences", "Constraint identifier violated where applicable" ] }, { "id": "ct-core-q-desigid-relations", "text": "Which relations hold between designations of the same concept, such as abbreviation of, variant of or transliteration of?", "kind": "relationship", "answer_data": [ "Relation type", "Source and target designation identifiers", "Whether the relation is symmetric" ] } ], "data_elements": [ { "id": "ct-core-de-designation-id", "name": "Designation identifier", "description": "Identifier of a reified designation, enabling attributes and relations to attach to the sign itself.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "ct-core-de-designation-relation", "name": "Designation-to-designation relation", "description": "Typed relation between two designations of the same concept, such as abbreviation or transliteration.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Reified designations are structured records of identifiers, codes and short literals evaluated by constraint checks; they are not media. Holding them as artifacts would break the exactly-one-literal-form constraint that has to be checkable in the record itself." } ] }, { "id": "ct-core-language-layer", "name": "Language, script and lexical form", "description": "How every designation, definition and note is language-tagged and scripted, and how the linguistic description of a designation is recorded without leaking into the concept.", "source_refs": [ "SRC-004", "SRC-009", "SRC-010" ], "findings": [ { "id": "ct-core-language-script", "name": "Language tag, script, region and transliteration", "description": "Every language-bearing value carries a BCP 47 tag built in the normative subtag order; the script subtag is taken from ISO 15924 and stated only when it is not suppressed for the language. Covers region and variant subtags, transliteration and romanization provenance, and language fallback behaviour.", "source_refs": [ "SRC-009", "SRC-010", "SRC-001", "SRC-003" ], "questions": [ { "id": "ct-core-q-lang-tag", "text": "Which complete BCP 47 language tag applies to this designation, including script, region and variant subtags where they are meaningful?", "kind": "requirement", "answer_data": [ "Full language tag", "Primary language subtag", "Script, region and variant subtags used", "Registry entry validity status" ] }, { "id": "ct-core-q-lang-script", "text": "Is the script subtag suppressed for this language, and if it is present anyway, what justifies including it?", "kind": "constraint", "answer_data": [ "Suppress-Script value from the subtag registry", "Script subtag actually recorded", "Justification for a non-suppressed script" ] }, { "id": "ct-core-q-lang-translit", "text": "Which transliteration or romanization scheme produced this designation, and what is its source designation?", "kind": "provenance", "answer_data": [ "Transliteration scheme identifier", "Source designation identifier", "Reversibility of the transliteration" ] }, { "id": "ct-core-q-lang-region", "text": "Where a designation is region-specific, which territory or usage community does it apply to?", "kind": "spatial", "answer_data": [ "Region subtag or UN M.49 code", "Usage community description", "Territories where the designation is not current" ] }, { "id": "ct-core-q-lang-fallback", "text": "How should a consuming system behave when no designation exists for the requested language tag?", "kind": "exception", "answer_data": [ "Fallback order of language tags", "Whether an untagged or notation value may be returned", "Explicit no-designation signal" ] } ], "data_elements": [ { "id": "ct-core-de-language-tag", "name": "Language tag", "description": "BCP 47 tag applied to a designation, definition or note; validated against the IANA Language Subtag Registry.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "ct-core-de-script-code", "name": "Script code", "description": "ISO 15924 four-letter script code, recorded only where it is not suppressed for the language.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-009" ] }, { "id": "ct-core-de-translit-scheme", "name": "Transliteration scheme reference", "description": "Identifier of the romanization or transliteration scheme that produced a derived designation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Language, script and region values are registry-controlled codes that must travel with every literal in every projection. They are validated against external registries by reference, so no artifact is created or stored by this model." }, { "id": "ct-core-lexical-form", "name": "Lexical entry, word forms and grammatical description", "description": "The linguistic description subordinate to a designation: the lexical entry realising it (word, multiword expression or affix), its canonical form, other forms, written and phonetic representations and grammatical categories. Attached at the designation boundary because symbols and appellations may have no lexical entry at all.", "source_refs": [ "SRC-004", "SRC-012", "SRC-009" ], "questions": [ { "id": "ct-core-q-lex-entry", "text": "Which lexical entry realises this designation, and is it a single word, a multiword expression or an affix?", "kind": "classification", "answer_data": [ "Lexical entry reference", "Entry subtype", "Lexicon or lexical resource that masters the entry" ] }, { "id": "ct-core-q-lex-forms", "text": "What is the canonical form of the designation, and which other forms are recorded alongside it?", "kind": "composition", "answer_data": [ "Canonical form written representation", "Other form written representations", "Morphosyntactic features per form" ] }, { "id": "ct-core-q-lex-grammar", "text": "Which grammatical categories are asserted, and from which data-category registry are their values drawn?", "kind": "interoperability", "answer_data": [ "Part of speech value and registry reference", "Grammatical gender and number values", "Registry or data-category persistent identifiers" ] }, { "id": "ct-core-q-lex-pronunciation", "text": "What evidence fixes the pronunciation or spoken form of this designation?", "kind": "evidence", "answer_data": [ "Phonetic representation and notation used", "Audio artifact reference", "Speaker variety or accent described" ] }, { "id": "ct-core-q-lex-not-designation", "text": "Which forms must not be treated as separate designations of the concept?", "kind": "constraint", "answer_data": [ "Forms excluded from the designation inventory", "Exclusion rule applied", "Handling in retrieval indexes" ] } ], "data_elements": [ { "id": "ct-core-de-canonical-form", "name": "Canonical form", "description": "The lemma or citation form of the lexical entry realising a designation.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "ct-core-de-other-form", "name": "Other form", "description": "A non-canonical grammatical realisation of the lexical entry, with its written representation.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "ct-core-de-grammatical-category", "name": "Grammatical category value", "description": "Part of speech, gender, number or similar category value drawn from a named data-category registry.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "ct-core-de-phonetic-rep", "name": "Phonetic representation", "description": "Phonetic transcription of a form, with the transcription notation named.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "ct-core-pronunciation-record", "name": "Pronunciation record", "description": "Spoken realisation of a designation captured as audio or as a formal phonetic transcription document, used where the written form underdetermines pronunciation.", "media_or_form": [ "audio recording", "phonetic transcription document", "speech sample with speaker metadata" ], "serial": false, "identity_strategy": "Identifier assigned by the holding lexical or media system where one exists; otherwise a content hash bound to the designation identifier and the recorded language tag.", "source_refs": [ "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "ct-core-equivalence-layer", "name": "Cross-language equivalence", "description": "How designations in different languages are asserted to represent the same concept, and how gaps and partial equivalence are recorded.", "source_refs": [ "SRC-004", "SRC-007", "SRC-012" ], "findings": [ { "id": "ct-core-designation-equivalence", "name": "Multilingual equivalence at the designation and sense boundary", "description": "Assertions that designations in different languages represent this one concept, with the degree of equivalence, the level at which the claim was made (concept-to-concept or sense-to-sense), the evidence behind it, and the way a missing target-language designation is recorded without inventing a term. Concept-to-concept mapping across schemes is deliberately excluded.", "source_refs": [ "SRC-007", "SRC-008", "SRC-004", "SRC-001" ], "questions": [ { "id": "ct-core-q-equiv-designations", "text": "Which designations in other languages are asserted to represent this same concept, and at what degree of equivalence?", "kind": "relationship", "answer_data": [ "Designation identifiers per language", "Degree-of-equivalence value", "Direction of the assertion" ] }, { "id": "ct-core-q-equiv-gap", "text": "Where a target language has no designation, how is that gap recorded without coining a term?", "kind": "exception", "answer_data": [ "Explicit no-equivalent marker", "Descriptive gloss provided instead of a term", "Whether coinage is permitted and by whom" ] }, { "id": "ct-core-q-equiv-level", "text": "Is equivalence asserted concept-to-concept or sense-to-sense, and what follows for downstream reuse?", "kind": "decision", "answer_data": [ "Assertion level", "Consequence for translation or substitution", "Reference to the sense records where sense-level" ] }, { "id": "ct-core-q-equiv-evidence", "text": "What evidence supports each equivalence assertion?", "kind": "evidence", "answer_data": [ "Evidence type (parallel text, expert attestation, standard clause)", "Source reference", "Date of attestation in RFC 3339 form" ] }, { "id": "ct-core-q-equiv-contested", "text": "Which equivalence claims are known to be partial or contested, and how is that flagged?", "kind": "quality", "answer_data": [ "Contested claim identifier", "Nature of the partiality", "Flag value carried in projections" ] } ], "data_elements": [ { "id": "ct-core-de-equivalence-degree", "name": "Degree of equivalence", "description": "Code stating whether a cross-language designation is exact, close, partial or a descriptive gloss.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "ct-core-de-equivalence-level", "name": "Equivalence assertion level", "description": "Whether the equivalence was asserted at concept level or at sense level.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "ct-core-de-no-equivalent-marker", "name": "No-equivalent marker", "description": "Explicit marker recording that a language has no designation for the concept, distinguished from missing data.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Equivalence claims are assertions between records already held in this model, plus a small set of qualifiers. Their supporting documents are cited by reference to sources owned by the provenance area, so this finding declares no artifact of its own." } ] } ] }, { "id": "ct-core-meaning-bundle", "name": "Definition, scope and usage", "description": "The written descriptions that make the concept understandable and usable: definitions, typed notes, subject field and homograph disambiguation, and the usage context and attestation of its designations.", "rationale": "ISO 1087 defines a definition as a representation of the concept that describes it and differentiates it from related concepts; SKOS supplies the typed note vocabulary and requires language tagging. Subject field is the standard disambiguator for homographic terms, and attested usage is the evidence base for acceptability ratings.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005", "SRC-007" ], "layers": [ { "id": "ct-core-definition-layer", "name": "Definitions and notes", "description": "The intensional statement of meaning and the typed documentation attached around it.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005" ], "findings": [ { "id": "ct-core-definition", "name": "Definition of the concept", "description": "The statement that describes the concept and differentiates it from related concepts, recorded per language with a definition type, the delimiting characteristic it carries, the source it is taken or adapted from, and checks against circular and purely negative definitions.", "source_refs": [ "SRC-005", "SRC-001", "SRC-003", "SRC-006" ], "questions": [ { "id": "ct-core-q-def-text", "text": "What is the definition text in each language, and which language tag applies to each version?", "kind": "definition", "answer_data": [ "Definition text", "Language tag", "Whether the version is an original or a translation" ] }, { "id": "ct-core-q-def-type", "text": "Is the definition intensional, extensional or ostensive, and which delimiting characteristic does it carry?", "kind": "classification", "answer_data": [ "Definition type code", "Delimiting characteristic referenced", "Broader concept named in the definition, if any" ] }, { "id": "ct-core-q-def-source", "text": "From which source document, clause or authority is the definition taken or adapted?", "kind": "provenance", "answer_data": [ "Source document reference", "Clause or section citation", "Adaptation status (verbatim, adapted, original)" ] }, { "id": "ct-core-q-def-multiplicity", "text": "How many definitions may coexist per language, and which rule resolves competing definitions?", "kind": "constraint", "answer_data": [ "Cardinality rule for definitions per language", "Precedence rule between competing definitions", "Profile decision reference" ] }, { "id": "ct-core-q-def-circularity", "text": "Which check confirms that the definition is neither circular nor a bare negation of another concept?", "kind": "validation", "answer_data": [ "Check identifier and method", "Result of the check", "Terms in the definition that resolve to other concepts" ] } ], "data_elements": [ { "id": "ct-core-de-definition-text", "name": "Definition text", "description": "Language-tagged statement describing the concept and differentiating it from related concepts.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "ct-core-de-definition-type", "name": "Definition type", "description": "Code distinguishing intensional, extensional and ostensive definitions.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "ct-core-de-definition-source-ref", "name": "Definition source reference", "description": "Reference to the document, clause or authority the definition derives from; the provenance chain itself is owned elsewhere.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "A definition is a short language-tagged literal that must appear in every projection and be diffable and constraint-checkable; storing it as an artifact would put the primary meaning-bearing value outside the record that validators and consumers read." }, { "id": "ct-core-notes", "name": "Scope notes, examples and explanatory notes", "description": "Typed documentation attached either to the concept or to a specific designation: scope note, example, general note and editorial note. Separates meaning-bearing notes that must survive interchange from editorial notes that may be filtered, and keeps change and history notes with the lifecycle and provenance areas.", "source_refs": [ "SRC-001", "SRC-003", "SRC-002" ], "questions": [ { "id": "ct-core-q-note-attachment", "text": "Which note types are recorded, and does each attach to the concept or to a specific designation?", "kind": "composition", "answer_data": [ "Note type per note", "Attachment level", "Language tag of the note" ] }, { "id": "ct-core-q-note-scope", "text": "What does the scope note state as included in and excluded from the concept's coverage?", "kind": "definition", "answer_data": [ "Inclusion statement", "Exclusion statement", "Neighbouring concept referenced for contrast" ] }, { "id": "ct-core-q-note-examples", "text": "Which examples illustrate correct and incorrect use of the designation?", "kind": "evidence", "answer_data": [ "Example text", "Correct or incorrect marker", "Reference to the designation the example applies to" ] }, { "id": "ct-core-q-note-filtering", "text": "Which notes are meaning-bearing and must survive interchange, and which are editorial and may be filtered?", "kind": "interoperability", "answer_data": [ "Note type classification as meaning-bearing or editorial", "Behaviour of each target interchange profile", "Loss report entry where a note cannot be carried" ] } ], "data_elements": [ { "id": "ct-core-de-note-type", "name": "Note type", "description": "Code identifying the note as a scope note, example, general note or editorial note.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "ct-core-de-note-text", "name": "Note text", "description": "Language-tagged documentation text attached to a concept or designation.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "ct-core-de-note-attachment-level", "name": "Note attachment level", "description": "Whether the note attaches to the concept or to a named designation.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Notes are short language-tagged literals whose type determines whether an interchange profile can carry them; the filtering decision has to be made over inline values, so externalising them as artifacts would defeat the loss reporting this finding exists to support." } ] }, { "id": "ct-core-context-layer", "name": "Subject field and usage", "description": "The domain that bounds the concept and disambiguates homographs, and the audience, register, territory and attested usage of its designations.", "source_refs": [ "SRC-005", "SRC-007", "SRC-012" ], "findings": [ { "id": "ct-core-subject-field", "name": "Subject field and homograph disambiguation", "description": "The field of special knowledge in which the concept and its terms are valid, drawn from an external classification. Used to disambiguate homographic designations across domains and to bound the intension; the classification itself is referenced, never redefined here.", "source_refs": [ "SRC-005", "SRC-006", "SRC-007" ], "questions": [ { "id": "ct-core-q-domain-value", "text": "Which subject field does this concept belong to, and from which classification is that value drawn?", "kind": "classification", "answer_data": [ "Subject field value", "Classification identifier and version", "Whether the assignment is primary or secondary" ] }, { "id": "ct-core-q-domain-homograph", "text": "Which other concept shares a designation with this one in a different subject field, and how is the pair distinguished?", "kind": "identity", "answer_data": [ "Homographic concept identifier", "Subject field of each concept", "Disambiguating qualifier applied to the designation" ] }, { "id": "ct-core-q-domain-effect", "text": "Does the subject field change the concept's delimitation, or only the usage of its designations?", "kind": "decision", "answer_data": [ "Effect classification", "Delimiting characteristic affected, if any", "Decision record reference" ] }, { "id": "ct-core-q-domain-authority", "text": "Which classification is authoritative for subject-field values, and what happens when it is revised?", "kind": "interoperability", "answer_data": [ "Authoritative classification reference", "Revision handling rule", "Deprecated value mapping" ] } ], "data_elements": [ { "id": "ct-core-de-subject-field", "name": "Subject field value", "description": "Referenced value from an external subject-field or domain classification.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-007" ] }, { "id": "ct-core-de-homograph-qualifier", "name": "Homograph qualifier", "description": "Qualifier added to a designation to distinguish it from a homograph in another subject field.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Subject field is a referenced classification value plus a short qualifier; the classification is owned by an external registry, so this model holds only inline reference values and would gain nothing from an artifact." }, { "id": "ct-core-usage-context", "name": "Usage context, register, audience and attestation", "description": "How and by whom a designation is actually used: audience and register, territory of currency, discouraged or offensive usage with directed alternatives, and attested occurrences that evidence real use. Keeps a designation's usage status distinct from the concept's own status, which belongs to the lifecycle area.", "source_refs": [ "SRC-002", "SRC-007", "SRC-012", "SRC-005" ], "questions": [ { "id": "ct-core-q-usage-audience", "text": "For which audience and register is this designation appropriate — specialist, general public, regulatory or internal?", "kind": "classification", "answer_data": [ "Audience code", "Register code", "Restriction on use outside that audience" ] }, { "id": "ct-core-q-usage-attestation", "text": "Which attested occurrence evidences that the designation is really used in this sense?", "kind": "evidence", "answer_data": [ "Attestation artifact reference", "Source publication and locator", "Attestation date in RFC 3339 form" ] }, { "id": "ct-core-q-usage-territory", "text": "In which territory or community is the designation current, and where is it not used?", "kind": "spatial", "answer_data": [ "Territories of currency", "Territories where it is not used", "Region subtag applied to the designation" ] }, { "id": "ct-core-q-usage-discouraged", "text": "Which usage is flagged as discouraged or offensive, and which alternative is directed instead?", "kind": "exception", "answer_data": [ "Discouraged designation identifier", "Reason for discouragement", "Directed alternative designation identifier" ] }, { "id": "ct-core-q-usage-vs-status", "text": "How is a designation's usage status kept distinct from the concept's own status?", "kind": "constraint", "answer_data": [ "Usage status value at designation level", "Statement that concept status is held in the lifecycle area", "Rule preventing propagation between the two" ] } ], "data_elements": [ { "id": "ct-core-de-audience-register", "name": "Audience and register", "description": "Codes describing the intended audience and stylistic register for a designation.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] }, { "id": "ct-core-de-usage-territory", "name": "Usage territory", "description": "Territory or community in which a designation is current, expressed with a region subtag or named community.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "ct-core-de-attestation-date", "name": "Attestation event time", "description": "RFC 3339 date-time at which the attested use occurred, recorded separately from when this model ingested the attestation.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "ct-core-de-discouraged-flag", "name": "Discouraged usage flag", "description": "Marks a designation as discouraged or offensive and points to the directed alternative.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] } ], "artifacts": [ { "id": "ct-core-usage-attestation", "name": "Usage attestation record", "description": "Captured evidence that a designation is used for this concept in real text or speech: a source excerpt, concordance line, screenshot of published use or a citation record.", "media_or_form": [ "source text excerpt", "corpus concordance line", "screenshot of published use", "structured citation record" ], "serial": true, "identity_strategy": "Attestations accumulate per designation as an ordered series; identity is the designation identifier plus the zero-padded series number assigned by the owning package, together with a content hash of the captured excerpt. No date component is used in the identifier.", "source_refs": [ "SRC-012", "SRC-007" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "ct-rel-bundle-placement", "name": "Scheme placement and grouping", "description": "Where a concept sits: which concept schemes assert it, whether it is a declared entry point into a hierarchy, and which non-hierarchical grouping constructs (collections, arrays, concept groups, classification levels) contain it.", "rationale": "SKOS treats scheme membership as an assertion about curation context rather than about meaning: a concept may be in zero, one or many schemes, membership does not propagate along semantic relations, and grouping constructs are formally disjoint from concepts. An agent that conflates placement with meaning will over-infer, so placement is separated from relation semantics at the top level.", "source_refs": [ "SRC-001", "SRC-003", "SRC-008", "SRC-014" ], "layers": [ { "id": "ct-rel-layer-scheme", "name": "Concept-scheme membership and entry points", "description": "Assertions binding a concept to concept schemes and declaring it a top concept, together with the rules governing multi-scheme participation, non-propagation of membership and hierarchy entry.", "source_refs": [ "SRC-001", "SRC-003" ], "findings": [ { "id": "ct-rel-find-scheme-membership", "name": "Concept-scheme membership and multi-scheme participation", "description": "SKOS places no cardinality constraint on membership: there are no conditions preventing a concept from taking part in zero, one or more than one concept scheme, skos:inScheme is not declared transitive, and a semantic link between two concepts does not entail that both are in the same scheme. Membership must therefore be asserted per concept per scheme, and an implementation that derives it from relations is making a local rule, not a standard entailment. skos:topConceptOf is a sub-property of skos:inScheme, so a top-concept declaration also asserts membership.", "source_refs": [ "SRC-001", "SRC-003", "SRC-019" ], "questions": [ { "id": "ct-rel-q-scheme-membership-set", "text": "Which concept schemes does this concept assert membership in, and is one of them designated the maintenance scheme that issues its authoritative identifier?", "kind": "composition", "answer_data": [ "Scheme reference (identifier or IRI) for each asserted membership", "Flag or reference marking the maintenance scheme, where one is designated", "Note recording that the zero-scheme and multi-scheme cases are both permitted by the standard" ] }, { "id": "ct-rel-q-scheme-membership-cardinality", "text": "Does this deployment permit a concept to belong to more than one scheme, and what local rule resolves conflicting structure between those schemes?", "kind": "constraint", "answer_data": [ "Local cardinality rule for scheme membership", "Conflict-resolution rule naming which scheme's structure prevails for navigation", "Reference to the governing scheme whose rules were applied" ] }, { "id": "ct-rel-q-scheme-membership-propagation", "text": "Is membership asserted explicitly for every concept, or derived from broader, narrower or related links in this deployment?", "kind": "validation", "answer_data": [ "Membership assertion mode: explicitly asserted or locally derived", "Statement that SKOS gives no entailment from a semantic relation to scheme membership", "Validation result listing concepts whose membership is only derived" ] }, { "id": "ct-rel-q-scheme-membership-orphan", "text": "How are concepts that assert no scheme membership treated by navigation, validation and export?", "kind": "exception", "answer_data": [ "Handling rule for scheme-less concepts", "Whether such concepts are exportable and under which closure rule", "Report of scheme-less concepts encountered" ] } ], "data_elements": [ { "id": "ct-rel-de-scheme-membership-ref", "name": "Concept scheme membership reference", "description": "Reference to a concept scheme in which this concept is asserted to be a member.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-home-scheme-ref", "name": "Maintenance scheme reference", "description": "Reference to the scheme whose maintenance agency issues the concept's authoritative identifier, where one is designated.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "ct-rel-de-membership-assertion-mode", "name": "Membership assertion mode", "description": "Coded value distinguishing an explicitly asserted membership from one derived by a local rule, since the standard supplies no derivation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Membership is a set of assertions linking two identifiers plus a small number of coded qualifiers. It has no document body, no rendition and no content to fix by digest; producing a separate artifact would create a second place where the same reference could drift out of step with the concept record." }, { "id": "ct-rel-find-top-concept", "name": "Top concepts and hierarchy entry points", "description": "skos:hasTopConcept has domain skos:ConceptScheme and range skos:Concept, and skos:topConceptOf is its inverse and a sub-property of skos:inScheme. Critically, the SKOS Reference defines no integrity condition preventing a declared top concept from also asserting a broader concept in the same scheme. A top concept is therefore a declared entry point chosen by the scheme, not a root derived from the absence of a broader link; treating it as a derived root is a common but unsupported assumption.", "source_refs": [ "SRC-001", "SRC-003" ], "questions": [ { "id": "ct-rel-q-top-concept-declared", "text": "Which schemes declare this concept a top concept, and is that declaration made by the scheme rather than inferred from missing broader links?", "kind": "relationship", "answer_data": [ "Reference to each scheme declaring this concept a top concept", "Source of the declaration: scheme assertion or local inference", "Note that topConceptOf also entails scheme membership" ] }, { "id": "ct-rel-q-top-concept-vs-root", "text": "Does a concept declared as a top concept also assert a broader concept within the same scheme, and how is that reconciled?", "kind": "constraint", "answer_data": [ "Boolean flag recording coexistence of a top-concept declaration and an in-scheme broader link", "Local reconciliation rule, with the note that SKOS supplies no integrity condition here", "List of affected concept and scheme pairs" ] }, { "id": "ct-rel-q-top-concept-entry", "text": "Which entry points should an agent use to enter a scheme's hierarchy when no top concept has been declared?", "kind": "decision", "answer_data": [ "Entry-point rule, for example concepts with no asserted broader link in the scheme", "Deterministic ordering rule for presenting entry points", "Statement that a computed entry set is derived and not written back as a declaration" ] }, { "id": "ct-rel-q-top-concept-multi", "text": "How is consistency kept when a concept is a top concept in one scheme but a mid-level concept in another?", "kind": "validation", "answer_data": [ "Per-scheme record of the concept's structural position", "Rule stating that a top-concept declaration is scheme-scoped and never global", "Validation output flagging cross-scheme position mismatches" ] } ], "data_elements": [ { "id": "ct-rel-de-top-concept-of-ref", "name": "Top concept of scheme reference", "description": "Reference to each scheme that declares this concept one of its top concepts.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-entry-point-rule", "name": "Hierarchy entry-point rule", "description": "Coded rule an agent applies to determine entry points into a scheme when top concepts are not declared.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "ct-rel-de-root-consistency-flag", "name": "Top-concept and broader-link coexistence flag", "description": "Boolean recording that a declared top concept also asserts a broader concept in the same scheme, which SKOS permits but which most consumers do not expect.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Top-concept declarations are directed assertions between a scheme identifier and a concept identifier, plus one consistency flag. There is no renderable body and no interchange payload distinct from the scheme export already covered by the interchange finding, so a separate artifact would duplicate state." } ] }, { "id": "ct-rel-layer-grouping", "name": "Grouping, array and level constructs", "description": "Non-hierarchical grouping of concepts: SKOS collections and ordered collections, ISO 25964 thesaurus arrays and concept groups, and XKOS classification levels, all of which are formally distinct from concepts and must not be exported as retrievable concepts.", "source_refs": [ "SRC-001", "SRC-008", "SRC-014" ], "findings": [ { "id": "ct-rel-find-grouping-construct", "name": "Collections, arrays, concept groups and classification levels", "description": "skos:Collection and skos:OrderedCollection group concepts through skos:member and the functional skos:memberList, with every list item also a member (S36); collections are disjoint from both skos:Concept and skos:ConceptScheme (S37). ISO 25964 adds ThesaurusArray with superOrdinate and subordinateArray for sibling grouping under a node label or facet indicator, and ConceptGroup with microThesaurusOf for domain subsets. XKOS adds ClassificationLevel with levels, depth and numberOfLevels. Because grouping nodes are not concepts, a hierarchical link between a parent concept and its children must still be asserted concept to concept; relying on the array to carry the hierarchy silently breaks navigation.", "source_refs": [ "SRC-001", "SRC-003", "SRC-008", "SRC-014" ], "questions": [ { "id": "ct-rel-q-grouping-membership", "text": "Which collections, thesaurus arrays or concept groups include this concept, and is any of those memberships ordered?", "kind": "composition", "answer_data": [ "Reference to each grouping construct containing the concept", "Construct type: collection, ordered collection, thesaurus array or concept group", "Position within an ordered member list where ordering applies" ] }, { "id": "ct-rel-q-grouping-disjointness", "text": "How is the disjointness of grouping constructs from concepts enforced so that a grouping node is never resolved or exported as a concept?", "kind": "constraint", "answer_data": [ "Type discriminator distinguishing grouping nodes from concepts", "Validation rule implementing the collection/concept and collection/scheme disjointness conditions", "List of identifiers typed as both, if any" ] }, { "id": "ct-rel-q-grouping-node-label", "text": "Does a containing array carry a node label or facet indicator that organises siblings without itself being a retrievable concept?", "kind": "classification", "answer_data": [ "Node label or facet indicator text carried by the array", "Superordinate concept the array subdivides", "Export rule excluding node labels from concept-level result sets" ] }, { "id": "ct-rel-q-grouping-level", "text": "Does this concept sit at a declared classification level, and what depth and ordering does that level carry?", "kind": "measurement", "answer_data": [ "Reference to the declared classification level", "Numeric depth of that level from the scheme root", "Total number of levels declared for the scheme" ] }, { "id": "ct-rel-q-grouping-hierarchy-gap", "text": "When a grouping construct sits between a parent concept and its child concepts, is the concept-to-concept hierarchical link still asserted directly?", "kind": "validation", "answer_data": [ "Boolean confirming a direct broader or narrower assertion exists in parallel with the grouping", "Report of children reachable only through a grouping node", "Remediation rule for adding the missing direct assertion" ] } ], "data_elements": [ { "id": "ct-rel-de-collection-membership-ref", "name": "Grouping construct membership reference", "description": "Reference to a collection, ordered collection, thesaurus array or concept group of which this concept is a member.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-008" ] }, { "id": "ct-rel-de-member-list-position", "name": "Ordered member position", "description": "Position of the concept within an ordered collection's member list, meaningful only where the grouping is ordered.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-array-superordinate-ref", "name": "Array superordinate concept reference", "description": "Reference to the concept that a containing thesaurus array subdivides.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "ct-rel-de-concept-group-ref", "name": "Concept group or micro-thesaurus reference", "description": "Reference to a concept group or micro-thesaurus subset of the scheme that contains this concept.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "ct-rel-de-classification-level-depth", "name": "Classification level depth", "description": "Numeric depth of the declared classification level at which the concept sits, counted from the scheme root.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "Grouping membership, array superordinates and level depth are reference and scalar values attached to the concept and to the grouping node. Ordered collections are carried as a position value rather than a stored list document, so there is no independent content object to identify, version or verify by digest." } ] } ] }, { "id": "ct-rel-bundle-semantics", "name": "Within-scheme semantic relations", "description": "Relations asserted between concepts inside one concept scheme: direct hierarchical links and their derived transitive closure, refined hierarchical kinds, associative relations and their disjointness from hierarchy, and the modelling of compound (pre-coordinated) concepts.", "rationale": "SKOS deliberately does not declare skos:broader or skos:narrower transitive and asserts them only for direct links, while providing separate transitive properties and declaring skos:related disjoint from the transitive hierarchical closure. These are the constraints most often violated by implementations, so asserted structure, derived structure and refined typing are separated and treated conservatively.", "source_refs": [ "SRC-001", "SRC-003", "SRC-008", "SRC-014", "SRC-018" ], "layers": [ { "id": "ct-rel-layer-semantic-relation", "name": "Hierarchical and associative relations", "description": "The direct relation assertions a concept makes inside its scheme, the refinement of hierarchical kind, the associative relation, and the transitivity, symmetry and disjointness rules that constrain all of them.", "source_refs": [ "SRC-001", "SRC-008", "SRC-014" ], "findings": [ { "id": "ct-rel-find-hierarchical", "name": "Direct hierarchical assertion versus derived transitive closure", "description": "skos:broader and skos:narrower are inverses and are, by convention, used only to assert direct hierarchical links; neither is declared transitive. skos:broaderTransitive and skos:narrowerTransitive are the transitive properties that capture direct or indirect links. The operational consequence is that ancestor and descendant sets are derived views: they may be computed at query time or materialised for performance, but must never be written back as if they were asserted direct links, because that destroys the ability to reconstruct the authored hierarchy.", "source_refs": [ "SRC-001", "SRC-003" ], "questions": [ { "id": "ct-rel-q-hier-direct", "text": "Which broader and narrower concepts does this concept assert, and is every one of them a direct link rather than an ancestor or descendant?", "kind": "relationship", "answer_data": [ "Reference to each directly asserted broader concept", "Reference to each directly asserted narrower concept", "Assertion marker distinguishing authored direct links from computed ones" ] }, { "id": "ct-rel-q-hier-transitive", "text": "Is the transitive form of the hierarchy computed at read time, materialised in storage, or both, and how is materialised closure marked as derived?", "kind": "decision", "answer_data": [ "Closure materialisation mode", "Marker applied to every derived transitive statement", "Recomputation trigger when a direct link changes" ] }, { "id": "ct-rel-q-hier-polyhierarchy", "text": "Does this concept assert more than one broader concept, and does the governing scheme permit polyhierarchy?", "kind": "constraint", "answer_data": [ "Count of asserted broader concepts", "Scheme-level rule permitting or forbidding polyhierarchy", "Reference to the scheme whose rule was applied" ] }, { "id": "ct-rel-q-hier-cycle", "text": "How are cycles and self-referential links detected in the hierarchical graph before they enter the derived closure?", "kind": "validation", "answer_data": [ "Cycle-detection result over the direct hierarchical graph", "List of concept identifiers participating in any cycle", "Rejection or quarantine rule applied to a cyclic assertion" ] }, { "id": "ct-rel-q-hier-cross-scheme", "text": "May a hierarchical link point at a concept in a different scheme, and how is such a link distinguished from a cross-scheme mapping?", "kind": "interoperability", "answer_data": [ "Local rule permitting or forbidding cross-scheme hierarchical links", "Discriminator recording whether the link is a semantic relation or a mapping relation", "Note that SKOS permits semantic relations across schemes but that mapping properties are the conventional construct" ] } ], "data_elements": [ { "id": "ct-rel-de-broader-direct-ref", "name": "Direct broader concept reference", "description": "Reference to a concept asserted as a direct broader concept; ancestors reachable only transitively are excluded.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-narrower-direct-ref", "name": "Direct narrower concept reference", "description": "Reference to a concept asserted as a direct narrower concept; descendants reachable only transitively are excluded.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-closure-materialisation-mode", "name": "Transitive closure materialisation mode", "description": "Coded value stating whether transitive hierarchy is computed on demand, materialised and marked derived, or not provided.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-polyhierarchy-permitted", "name": "Polyhierarchy permission flag", "description": "Boolean recording whether the governing scheme permits a concept to assert more than one broader concept.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-018" ] } ], "artifacts": [], "inline_only_rationale": "Hierarchical structure is a set of directed references between concept identifiers plus derivation flags. The derived closure is intentionally not persisted as an addressable object, so there is nothing here with independent content, rendition or integrity requirements to justify an artifact." }, { "id": "ct-rel-find-hierarchy-kind", "name": "Hierarchical relation kinds: generic, partitive and instantial", "description": "SKOS offers a single undifferentiated broader relation. ISO 25964, through iso-thes, refines it into broaderGeneric, broaderPartitive and broaderInstantial, and XKOS distinguishes specializes/generalizes from isPartOf/hasPart. ISO 1087 gives the corresponding terminology-science distinction between generic and partitive relations. The refinement matters operationally because chaining behaves differently: generic subsumption composes reliably, whereas partitive chains are unsafe across changes of part-whole kind. Projecting a refined kind onto plain broader for interchange is lossy and must be declared.", "source_refs": [ "SRC-001", "SRC-008", "SRC-014", "SRC-018", "SRC-013" ], "questions": [ { "id": "ct-rel-q-hier-kind-declared", "text": "What kind of hierarchical relation is asserted to each broader concept - generic, partitive, instantial or undifferentiated?", "kind": "classification", "answer_data": [ "Coded relation kind per broader assertion", "Vocabulary the kind is drawn from, such as the ISO 25964 or XKOS refinement set", "Default kind applied when the scheme does not refine" ] }, { "id": "ct-rel-q-hier-kind-test", "text": "Which test must be satisfied before a hierarchical relation is asserted, and is the justification recorded with the assertion?", "kind": "requirement", "answer_data": [ "Named test applied, such as the all-and-some subsumption test for generic relations", "Short justification note attached to the assertion", "Rule stating whether an untested assertion may be created at all" ] }, { "id": "ct-rel-q-hier-kind-transitivity", "text": "Which hierarchical kinds may be chained transitively in this deployment, and at which point must a chain stop?", "kind": "constraint", "answer_data": [ "Per-kind chaining rule", "Stop condition where the kind changes along a path", "Statement that SKOS itself declares transitivity only for broaderTransitive, not for the refined kinds" ] }, { "id": "ct-rel-q-hier-kind-loss", "text": "What information is lost when a refined hierarchical kind is projected onto plain broader or narrower for interchange?", "kind": "interoperability", "answer_data": [ "List of refined kinds collapsed in the projection", "Declaration that the projection is lossy and not reversible from the output alone", "Retention of the refined kind in the source record" ] } ], "data_elements": [ { "id": "ct-rel-de-hierarchy-relation-kind", "name": "Hierarchical relation kind", "description": "Coded refinement of a hierarchical assertion: generic, partitive, instantial or undifferentiated.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-014" ] }, { "id": "ct-rel-de-hierarchy-justification-note", "name": "Hierarchical assertion justification", "description": "Short note recording which test justified the hierarchical assertion, held with the relation rather than as a separate evidence record.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "ct-rel-de-hierarchy-chaining-rule", "name": "Hierarchical chaining rule", "description": "Coded rule stating whether and how far assertions of this kind may be composed into a transitive path.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "Relation kind, justification note and chaining rule are qualifiers on an existing relation assertion. They have no standalone existence: detaching them into an artifact would separate a qualifier from the assertion it qualifies and create an orphaning risk with no compensating benefit." }, { "id": "ct-rel-find-associative", "name": "Associative relations and disjointness from hierarchy", "description": "skos:related is symmetric and is not transitive, and integrity condition S27 declares it disjoint with skos:broaderTransitive - so two concepts connected by any hierarchical path must not also be linked associatively. XKOS refines association into causal (causes, causedBy), sequential (precedes and succeeds, which are transitive, versus previous and next, which are not) and temporal (before, after). Because symmetry is a property of the relation rather than of the record, a deployment must decide once whether the inverse statement is stored or inferred, and apply that decision uniformly.", "source_refs": [ "SRC-001", "SRC-014", "SRC-018" ], "questions": [ { "id": "ct-rel-q-assoc-declared", "text": "Which associative relations does this concept assert, and is a refined association subtype recorded for each?", "kind": "relationship", "answer_data": [ "Reference to each associatively related concept", "Coded association subtype where refinement is used, such as causal, sequential or temporal", "Scheme context in which the association was asserted" ] }, { "id": "ct-rel-q-assoc-disjoint", "text": "How is the rule that an associative link must not coexist with a hierarchical path between the same two concepts checked?", "kind": "validation", "answer_data": [ "Validation result over the transitive hierarchical closure for each associative pair", "List of pairs violating the disjointness condition", "Resolution rule choosing which assertion is withdrawn" ] }, { "id": "ct-rel-q-assoc-symmetry", "text": "Is the inverse of each associative assertion stored explicitly, inferred at read time, or both?", "kind": "decision", "answer_data": [ "Inverse storage mode applied uniformly across the deployment", "Rule preventing double counting when both directions are stored", "Behaviour on export when only one direction is present in the source" ] }, { "id": "ct-rel-q-assoc-refined-transitivity", "text": "Which refined associative relations may be composed transitively and which are explicitly non-transitive?", "kind": "constraint", "answer_data": [ "Per-subtype transitivity declaration", "Explicit statement that the base associative relation is not transitive", "Traversal depth limit applied by navigation functions" ] } ], "data_elements": [ { "id": "ct-rel-de-related-concept-ref", "name": "Associatively related concept reference", "description": "Reference to a concept linked by an associative relation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-association-subtype", "name": "Association subtype", "description": "Coded refinement of an associative relation, such as causal, sequential or temporal, drawn from an extension vocabulary.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "ct-rel-de-inverse-storage-mode", "name": "Inverse assertion storage mode", "description": "Coded decision on whether the symmetric counterpart of an associative assertion is stored, inferred or both.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Associative structure consists of symmetric references and coded subtypes attached to the concept. The disjointness check produces a transient report consumed by the validation area rather than a record this model owns, so no artifact is declared here." } ] }, { "id": "ct-rel-layer-compound", "name": "Compound concepts and decomposition", "description": "Whether a concept is pre-coordinated, how its components are recorded without over-claiming, and how one-to-many compound equivalence is expressed when a concept can only be matched by combining several concepts in another vocabulary.", "source_refs": [ "SRC-003", "SRC-007", "SRC-008", "SRC-004" ], "findings": [ { "id": "ct-rel-find-compound-modelling", "name": "Compound concepts, coordination choice and decomposition cautions", "description": "A knowledge organization system may pre-coordinate a compound concept as a single unit or leave the combination to retrieval time (post-coordination). The SKOS Primer records that established patterns for pre-coordination have not emerged in the SKOS community and recommends extensions rather than additions to the core vocabulary, so a deployment must state its own rule. OntoLex decomp offers subterm, constituent and Component, but this decomposes a lexical entry, not a concept: a recorded lexical decomposition must never be read as a claim that the concept is the semantic composition of its parts.", "source_refs": [ "SRC-003", "SRC-004", "SRC-018" ], "questions": [ { "id": "ct-rel-q-compound-status", "text": "Is this concept a pre-coordinated compound, and which concepts are recorded as its components?", "kind": "composition", "answer_data": [ "Coordination mode: pre-coordinated compound or atomic", "Reference to each recorded component concept", "Scheme rule that permitted the compound to be created" ] }, { "id": "ct-rel-q-compound-decision", "text": "Under which rule was this combination modelled as one concept rather than left to be combined at retrieval time?", "kind": "decision", "answer_data": [ "Named coordination rule applied by the scheme", "Reason the combination is treated as a stable unit of meaning", "Note recording that no standard SKOS pre-coordination pattern is available" ] }, { "id": "ct-rel-q-compound-decomposition-limit", "text": "Is the recorded decomposition lexical or semantic, and what must a consumer not infer from it?", "kind": "definition", "answer_data": [ "Decomposition basis: lexical form decomposition or asserted semantic composition", "Explicit non-inference statement covering hierarchy and equivalence", "Reference to the lexical model where form-level decomposition is owned" ] }, { "id": "ct-rel-q-compound-relation", "text": "How are the compound and its components linked without implying a hierarchical or equivalence claim between them?", "kind": "relationship", "answer_data": [ "Relation construct used to link compound to component", "Statement that the link is not asserted as broader, narrower or a match", "Export behaviour for consumers that do not understand the construct" ] } ], "data_elements": [ { "id": "ct-rel-de-coordination-mode", "name": "Coordination mode", "description": "Coded value recording whether the concept is a pre-coordinated compound or an atomic concept intended for post-coordination.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "ct-rel-de-component-concept-ref", "name": "Component concept reference", "description": "Reference to a concept recorded as a component of this compound concept, without any implied hierarchical or equivalence claim.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "ct-rel-de-decomposition-basis", "name": "Decomposition basis", "description": "Coded value stating whether a recorded decomposition is lexical (form-level) or an asserted semantic composition.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Coordination mode, component references and decomposition basis are qualifiers of the concept record itself. There is no standard-defined document for pre-coordination, and inventing an artifact would present unsupported structure as canonical when the primary source states that no such pattern has been established." }, { "id": "ct-rel-find-compound-equivalence", "name": "Compound one-to-many equivalence across vocabularies", "description": "ISO 25964-2 recognises that equivalence between vocabularies is often not one to one and provides compound equivalence, where a concept in one vocabulary is expressed by combining several concepts in another. The iso-thes vocabulary carries this as CompoundEquivalence with plusUF and plusUse, plus SplitNonPreferredTerm for a concept that is not directly present but is representable by combining preferred terms. SKOS has no native construct for this: a consumer reading plain SKOS will see either nothing or a set of unqualified matches, so the combination operator and the degradation behaviour must both be recorded.", "source_refs": [ "SRC-007", "SRC-008", "SRC-003" ], "questions": [ { "id": "ct-rel-q-compound-equiv-target", "text": "Which set of target concepts jointly expresses this concept, and in which vocabulary do they sit?", "kind": "interoperability", "answer_data": [ "Ordered or unordered set of target concept references forming the equivalence", "Reference to the target vocabulary and its bound release", "Direction of the equivalence, from this concept to the set" ] }, { "id": "ct-rel-q-compound-equiv-construct", "text": "Which combination operator applies to the target set, and which construct carries it when the interchange format has no compound-equivalence class?", "kind": "requirement", "answer_data": [ "Combination operator: conjunctive or disjunctive", "Construct or extension used to carry the operator", "Fallback representation when the target format cannot express it" ] }, { "id": "ct-rel-q-compound-equiv-degradation", "text": "How is a one-to-many equivalence degraded for consumers that accept only one-to-one matches, and is the loss flagged?", "kind": "exception", "answer_data": [ "Degradation rule, such as suppression or emission as separate close matches", "Boolean flag marking the output as degraded", "Warning text carried alongside the degraded output" ] }, { "id": "ct-rel-q-compound-equiv-direction", "text": "Is the compound equivalence reversible, and what if anything is asserted in the opposite direction?", "kind": "constraint", "answer_data": [ "Reversibility statement for the equivalence", "Assertions made in the reverse direction, if any", "Rule preventing an automatic symmetric inverse from being generated" ] } ], "data_elements": [ { "id": "ct-rel-de-compound-equivalence-target-set", "name": "Compound equivalence target set", "description": "Collection of target concept references that jointly express this concept in another vocabulary.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "ct-rel-de-compound-combination-operator", "name": "Compound combination operator", "description": "Coded operator stating whether the target set is combined conjunctively or disjunctively to express this concept.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "ct-rel-de-compound-degradation-flag", "name": "Compound degradation flag", "description": "Boolean marking that a compound equivalence has been degraded to simpler match statements for a consumer that cannot represent it.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "A compound equivalence is a structured assertion carried inside whichever mapping set contains it; the mapping set is already declared as an artifact in the mapping layer. Declaring a second artifact for the individual equivalence would fragment the identity of the same interchange payload." } ] } ] }, { "id": "ct-rel-bundle-interop", "name": "Cross-scheme mapping, alignment and interchange", "description": "How a concept is connected to concepts in other schemes, aligned to formal ontology terms, and moved between systems and serializations without losing or over-stating meaning.", "rationale": "SKOS separates mapping properties from within-scheme semantic relations only by convention, and defines exactMatch as transitive and symmetric while closeMatch is symmetric but not transitive; broadMatch and narrowMatch are simultaneously sub-properties of broader and narrower, so cross-scheme assertions leak into the hierarchical closure. Interoperability therefore needs explicit chain rules, alignment-entailment declarations and format-neutral projection rules rather than being treated as an export detail.", "source_refs": [ "SRC-001", "SRC-003", "SRC-014", "SRC-015", "SRC-016", "SRC-009" ], "layers": [ { "id": "ct-rel-layer-mapping", "name": "Cross-scheme mapping relations and mapping sets", "description": "Mapping relation types and their formal properties, the packaging of mappings into sets or correspondences with cardinality and chain rules, and the caveats that apply when mapping across languages.", "source_refs": [ "SRC-001", "SRC-007", "SRC-014", "SRC-009" ], "findings": [ { "id": "ct-rel-find-mapping-relation", "name": "Mapping relation types and their formal properties", "description": "skos:mappingRelation is a sub-property of skos:semanticRelation. exactMatch is transitive and symmetric; closeMatch is symmetric but explicitly not transitive; broadMatch and narrowMatch are sub-properties of skos:broader and skos:narrower as well as of mappingRelation, so they participate in the hierarchical closure; relatedMatch is a sub-property of skos:related and is symmetric. Integrity condition S46 makes exactMatch disjoint with broadMatch and relatedMatch. Two facts are commonly missed: cross-scheme use of the mapping properties is a convention, not a formal requirement, and SKOS supplies no integrity condition making a same-scheme mapping inconsistent.", "source_refs": [ "SRC-001", "SRC-003" ], "questions": [ { "id": "ct-rel-q-map-type", "text": "Which mapping relation type is asserted towards each target concept, and which scheme owns that target?", "kind": "relationship", "answer_data": [ "Coded mapping type per target: exact, close, broad, narrow or related match", "Reference to the target concept", "Reference to the scheme that governs the target concept" ] }, { "id": "ct-rel-q-map-strength", "text": "What threshold distinguishes an exact match from a close match in this deployment, and who applies it?", "kind": "decision", "answer_data": [ "Stated criterion for asserting interchangeability rather than similarity", "Role authorised to assert the stronger type", "Short basis note recorded with the assertion" ] }, { "id": "ct-rel-q-map-hierarchy-leak", "text": "How does the deployment handle the fact that broad and narrow matches are also hierarchical properties and therefore enter the transitive hierarchical closure?", "kind": "constraint", "answer_data": [ "Rule stating whether cross-scheme matches are admitted into the local hierarchy closure", "Marker separating mapping-derived ancestors from in-scheme ancestors in navigation output", "Traversal boundary applied at the scheme edge" ] }, { "id": "ct-rel-q-map-disjointness", "text": "How is the disjointness of an exact match with a broad match or a related match between the same pair of concepts enforced?", "kind": "validation", "answer_data": [ "Validation result per concept pair across all mapping types", "List of pairs holding disjoint mapping types simultaneously", "Rejection rule applied when a conflicting assertion is submitted" ] }, { "id": "ct-rel-q-map-same-scheme", "text": "Is a mapping relation permitted between two concepts of the same scheme, and what is being asserted when it occurs?", "kind": "exception", "answer_data": [ "Local rule on same-scheme mapping assertions", "Note that SKOS makes such a graph consistent and that cross-scheme use is a convention", "Typical cause, such as a merge of data from different sources" ] } ], "data_elements": [ { "id": "ct-rel-de-mapping-target-ref", "name": "Mapping target concept reference", "description": "Reference to the concept in another scheme that this mapping assertion points at.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-mapping-relation-type", "name": "Mapping relation type", "description": "Coded mapping type asserted towards the target: exact, close, broad, narrow or related match.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "ct-rel-de-mapping-target-scheme-ref", "name": "Target scheme reference", "description": "Reference to the concept scheme that governs the mapping target, needed to distinguish a mapping from a within-scheme relation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "ct-rel-de-mapping-strength-basis", "name": "Mapping strength basis note", "description": "Short note recording the criterion that justified the chosen mapping type, especially the exact versus close decision.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "An individual mapping assertion is a typed reference between two concept identifiers with a small qualifier set; its interchange container is the mapping set declared in the neighbouring finding. Giving the single assertion its own artifact would duplicate the mapping set's identity and integrity guarantees." }, { "id": "ct-rel-find-mapping-set", "name": "Mapping sets, cardinality, binding and chain limits", "description": "Mappings are managed as sets rather than as isolated statements. XKOS provides Correspondence, which compares two schemes, and ConceptAssociation with sourceConcept and targetConcept, allowing many-to-many associations to be reified and described. ISO 25964-2 similarly organises equivalence, hierarchical and associative mappings between vocabularies. Chain composition must be conservative: exactMatch is transitive so exact chains compose, but closeMatch is not transitive and a chain mixing types must not be composed at all. Every set binds to specific releases of the two schemes it compares; the releases themselves are issued by the lifecycle area.", "source_refs": [ "SRC-001", "SRC-003", "SRC-007", "SRC-014" ], "questions": [ { "id": "ct-rel-q-mapset-membership", "text": "Which mapping set or correspondence contains this concept's mapping assertions, and which two schemes does that set compare?", "kind": "composition", "answer_data": [ "Reference to each containing mapping set or correspondence", "References to the source and target schemes the set compares", "Whether the association is reified with explicit source and target roles" ] }, { "id": "ct-rel-q-mapset-cardinality", "text": "What cardinality does the mapping set permit, and how are many-to-many associations represented?", "kind": "classification", "answer_data": [ "Permitted cardinality: one-to-one, one-to-many or many-to-many", "Reification construct used for many-to-many associations", "Count of associations involving this concept" ] }, { "id": "ct-rel-q-mapset-binding", "text": "Which specific scheme releases does the mapping set bind to on each side?", "kind": "interoperability", "answer_data": [ "Release identifier bound on the source side", "Release identifier bound on the target side", "Statement that release issuance and succession are owned by the lifecycle area, not asserted here" ] }, { "id": "ct-rel-q-mapset-chain", "text": "Which mapping types may be composed across two sets to derive a third mapping, and where must composition stop?", "kind": "constraint", "answer_data": [ "Per-type composition rule, with exact-match chains composable and close-match chains not", "Prohibition on composing chains of mixed mapping types", "Derived marker applied to any composed mapping" ] }, { "id": "ct-rel-q-mapset-conflict", "text": "How are contradictory mappings from different sets for the same concept pair detected and reported?", "kind": "quality", "answer_data": [ "List of conflicting assertions with their originating sets", "Precedence rule naming which set prevails for a consumer", "Report handed to the governance area, which owns adjudication" ] } ], "data_elements": [ { "id": "ct-rel-de-mapping-set-ref", "name": "Mapping set reference", "description": "Reference to a mapping set or correspondence that contains mapping assertions involving this concept.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "ct-rel-de-mapping-set-cardinality", "name": "Mapping set cardinality", "description": "Coded cardinality the mapping set permits between source and target concepts.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-014" ] }, { "id": "ct-rel-de-mapping-set-bound-release", "name": "Bound scheme release reference", "description": "Reference to the specific scheme release bound on each side of the mapping set; the release object itself is owned by the lifecycle area.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-014", "SRC-007" ] }, { "id": "ct-rel-de-mapping-chain-composability", "name": "Mapping chain composability rule", "description": "Coded rule stating whether assertions of a given mapping type may be composed across sets and where composition must stop.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] } ], "artifacts": [ { "id": "ct-rel-art-mapping-set", "name": "Mapping set / correspondence", "description": "A managed, citable collection of mapping assertions between two named concept schemes at specific bound releases, carrying its cardinality rule, the mapping type of each association, any reified many-to-many associations, and the chain-composition limits that apply to it. It is the unit that is published, cited and superseded, so it needs its own identity and integrity guarantee.", "media_or_form": [ "Tabular correspondence table with source and target concept identifiers, mapping type and qualifiers", "Graph of reified concept associations with explicit source and target roles", "Structured mapping-set document with a header declaring the two compared schemes and their bound releases" ], "serial": true, "identity_strategy": "Use the identifier issued by the maintenance agency that publishes the correspondence. Failing that, mint a governed identifier in a namespace the publisher controls and can dereference. Only where neither exists, assign a UUID or ULID in the adopting Dimension and record it as locally minted. The pair of bound scheme releases and the series number are qualifiers on the identifier, never the identifier itself, and no date is used as an identifier.", "source_refs": [ "SRC-007", "SRC-014", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "ct-rel-find-multilingual-mapping", "name": "Multilingual and cross-lingual mapping caveats", "description": "A concept is a language-independent node: SKOS attaches labels in many languages to one concept and permits only one preferred label per language tag, so a translation is normally a label of the same concept rather than a mapping to a different concept. Where two vocabularies are maintained in different languages, ISO 25964 treats cross-lingual equivalence as graded - exact, inexact, partial, one-to-many or absent. BCP 47 tags identify the language, script and region of a string; matching tags on two labels says nothing about whether the labels denote the same concept, and equal tags must never be used as evidence of equivalence.", "source_refs": [ "SRC-001", "SRC-003", "SRC-007", "SRC-009" ], "questions": [ { "id": "ct-rel-q-multiling-identity", "text": "Is this a single language-independent concept carrying multilingual labels, or are language-specific concepts linked by cross-lingual mapping?", "kind": "definition", "answer_data": [ "Boolean stating whether the concept node is language independent", "Where language-specific concepts exist, the mapping type linking them", "Reference to the vocabulary design decision that produced the arrangement" ] }, { "id": "ct-rel-q-multiling-degree", "text": "What degree of cross-lingual equivalence is recorded when the target language has no exact equivalent?", "kind": "classification", "answer_data": [ "Coded equivalence degree: exact, inexact, partial, one-to-many or none", "Explanatory note where the equivalence is less than exact", "Fallback behaviour when no equivalent exists at all" ] }, { "id": "ct-rel-q-multiling-tag", "text": "Which BCP 47 language tags, including any script and region subtags, scope each side of a cross-lingual assertion?", "kind": "identity", "answer_data": [ "Language tag on the source side in canonical case form", "Language tag on the target side in canonical case form", "Canonicalisation rule applied to legacy or non-BCP-47 codes before comparison" ] }, { "id": "ct-rel-q-multiling-inference", "text": "What must a consumer not infer from two labels carrying the same language tag or from a translated label?", "kind": "constraint", "answer_data": [ "Explicit non-inference statement covering equivalence, hierarchy and interchangeability", "Statement that a language tag identifies the language of the string, not the meaning", "Reference to the lexical area that owns label-to-label relations" ] } ], "data_elements": [ { "id": "ct-rel-de-assertion-language-tag", "name": "Assertion language tag", "description": "BCP 47 tag, including script and region subtags where they matter, scoping one side of a cross-lingual assertion.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "ct-rel-de-cross-lingual-equivalence-degree", "name": "Cross-lingual equivalence degree", "description": "Coded degree of equivalence recorded for a cross-lingual match: exact, inexact, partial, one-to-many or none.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "ct-rel-de-language-independent-node-flag", "name": "Language-independent concept flag", "description": "Boolean recording whether the concept is a single language-independent node with multilingual labels rather than one node per language.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Language tags, equivalence degrees and the language-independence flag are qualifiers on concepts and on mapping assertions that already have containers. The multilingual label set itself belongs to the lexical area, so creating an artifact here would claim ownership of content this pass explicitly excludes." } ] }, { "id": "ct-rel-layer-alignment-interchange", "name": "Formal alignment and interchange", "description": "Connecting the concept to formal ontology terms with an explicit statement of entailment, and moving the concept's relation and mapping structure between systems and serializations with declared closure, crosswalks and losses.", "source_refs": [ "SRC-004", "SRC-015", "SRC-016", "SRC-017", "SRC-019" ], "findings": [ { "id": "ct-rel-find-ontology-alignment", "name": "Semantic alignment to ontology classes, properties and individuals", "description": "Aligning a concept to an ontology term is not the same as mapping it to another concept. OWL 2 gives owl:equivalentClass a set-extensional meaning over individuals, rdfs:subClassOf transitive and reflexive subsumption, and owl:sameAs identity of individuals, and each licenses a reasoner to draw consequences the vocabulary editor may not intend. OntoLex sits deliberately between the two worlds: LexicalConcept is a subclass of skos:Concept and is connected to entries by evokes and lexicalizedSense, while denotes and reference point at ontology predicates. DCAT shows the practical consequence, allowing a taxonomy to be a concept scheme, a collection or an ontology. The alignment predicate and its entailment scope must therefore be recorded with the alignment, not assumed.", "source_refs": [ "SRC-004", "SRC-015", "SRC-016", "SRC-019" ], "questions": [ { "id": "ct-rel-q-align-target-kind", "text": "Is the alignment target an ontology class, a property, an individual or another concept?", "kind": "classification", "answer_data": [ "Coded target kind", "Reference to the target term and the ontology that defines it", "Reference to the model or registry that governs the target" ] }, { "id": "ct-rel-q-align-strength", "text": "Which alignment predicate is asserted, and what entailment does it commit a consuming reasoner to?", "kind": "constraint", "answer_data": [ "Alignment predicate asserted", "Declared entailment scope, including what may and may not be derived", "Whether the alignment is intended for reasoning or for documentation only" ] }, { "id": "ct-rel-q-align-owl-caution", "text": "Why is this concept not asserted as identical or class-equivalent to the ontology term by default?", "kind": "definition", "answer_data": [ "Statement of the difference between a unit of thought in a vocabulary and a class extension over individuals", "Record of the weaker predicate chosen instead and the reason", "Named risk that a stronger predicate would create, such as unintended merging of individuals" ] }, { "id": "ct-rel-q-align-lexical-bridge", "text": "How is the concept connected to lexical entries and senses without importing lexical structure into the concept record?", "kind": "relationship", "answer_data": [ "Bridging construct used, such as evokes or lexicalized sense", "Reference to the lexical entry or sense in the lexical model", "Statement that forms, senses and translations remain owned by the lexical model" ] } ], "data_elements": [ { "id": "ct-rel-de-alignment-target-ref", "name": "Alignment target reference", "description": "Reference to the ontology class, property, individual or external concept that the alignment points at.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-015", "SRC-016" ] }, { "id": "ct-rel-de-alignment-predicate", "name": "Alignment predicate", "description": "Coded predicate asserted between the concept and the alignment target.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-015" ] }, { "id": "ct-rel-de-alignment-target-kind", "name": "Alignment target kind", "description": "Coded kind of the alignment target: class, property, individual or concept.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-019" ] }, { "id": "ct-rel-de-alignment-entailment-scope", "name": "Declared entailment scope", "description": "Coded declaration of what a consumer may derive from the alignment, distinguishing documentation-only alignments from reasoning-bearing ones.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "An alignment is a typed reference plus an entailment declaration held on the concept. Executing the entailment, materialising its consequences and storing inferred graphs belong to the referenced reasoning environment, so this model deliberately holds no artifact that could be mistaken for an inference result." }, { "id": "ct-rel-find-interchange", "name": "Import, export, projection and crosswalk behaviour", "description": "RDF 1.1 establishes that the abstract structure of identifiers, values and statements is independent of any concrete serialization, and that identifiers have global scope, so JSON, YAML, Markdown, tabular files, Turtle and JSON-LD are projections of one assertion set. Interchange therefore turns on three decisions that must be declared rather than implied: which closure is included (concept alone, direct relations, whole scheme, or transitive neighbourhood); how references that leave the closure are represented so they are not read as missing data; and which constructs are lossy in the target model - refined hierarchical kinds, compound equivalence and reified associations are the usual casualties. Namespace and identifier resolution follow the published-vocabulary recipes: term identifiers stay stable while version information moves into the served document.", "source_refs": [ "SRC-007", "SRC-008", "SRC-014", "SRC-016", "SRC-017", "SRC-019" ], "questions": [ { "id": "ct-rel-q-interchange-closure", "text": "What closure does an export include - the concept alone, its direct relations, its whole scheme, or its transitive neighbourhood?", "kind": "composition", "answer_data": [ "Coded closure rule applied to the export", "Depth limit where a transitive neighbourhood is included", "Count of concepts and assertions included under the rule" ] }, { "id": "ct-rel-q-interchange-dangling", "text": "How are references to concepts outside the exported closure represented so they are not mistaken for missing or broken data?", "kind": "exception", "answer_data": [ "Coded handling for out-of-closure references: retained as bare identifiers, stubbed, or omitted with a manifest entry", "List of out-of-closure targets carried in the package manifest", "Consumer instruction for resolving them" ] }, { "id": "ct-rel-q-interchange-crosswalk", "text": "Which crosswalk rule maps each local relation, grouping and mapping construct onto the target interchange model?", "kind": "interoperability", "answer_data": [ "Rule set mapping each local construct to a target construct", "Target model and its version", "Constructs with no target equivalent and their fallback" ] }, { "id": "ct-rel-q-interchange-roundtrip", "text": "Which constructs are lossy on a round trip through this projection, and how is the loss declared to the consumer?", "kind": "validation", "answer_data": [ "List of lossy constructs, such as refined hierarchy kinds, compound equivalence and reified associations", "Round-trip test result comparing re-imported structure with the source", "Loss declaration carried in the package" ] }, { "id": "ct-rel-q-interchange-namespace", "text": "Which namespace and identifier-resolution rule applies to concept references inside the exchanged package?", "kind": "identity", "answer_data": [ "Namespace design in use and its base identifier", "Dereferencing expectation for a concept identifier", "Rule keeping term identifiers stable while release information is carried in the served document" ] } ], "data_elements": [ { "id": "ct-rel-de-export-closure-rule", "name": "Export closure rule", "description": "Coded rule determining which concepts and assertions are included in an export or import package.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "ct-rel-de-dangling-reference-handling", "name": "Out-of-closure reference handling", "description": "Coded handling for references that point outside the exported closure, so they are distinguishable from missing data.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "ct-rel-de-crosswalk-rule-ref", "name": "Crosswalk rule reference", "description": "Reference to the rule that maps a local relation, grouping or mapping construct onto a construct in the target interchange model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008", "SRC-014" ] }, { "id": "ct-rel-de-lossy-construct-list", "name": "Lossy construct declaration", "description": "Collection naming the constructs that cannot survive a round trip through the chosen projection.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-014" ] } ], "artifacts": [ { "id": "ct-rel-art-interchange-package", "name": "Relation and mapping interchange package", "description": "A self-describing export or import payload carrying the selected closure of concepts, their scheme and grouping memberships, direct relations, mappings and alignments, together with a manifest declaring the closure rule, out-of-closure references, the crosswalk applied and any lossy constructs. It is produced repeatedly and must be verifiable on receipt, so it carries its own identifier, digest and assertion count.", "media_or_form": [ "Graph serialization of the exported assertions", "Tabular extract with one row per assertion", "Structured document bundling a manifest with the exported assertion set" ], "identity_strategy": "Assign a governed identifier in the exporting Dimension's controlled namespace, qualified by the series number and the identifiers of the source records included. Where an external maintenance agency publishes the package, its issued identifier takes precedence. A UUID or ULID is used only as a last resort; no date or filename is treated as the identifier.", "serial": true, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "ct-rel-art-crosswalk-specification", "name": "Crosswalk specification", "description": "A rule set stating, construct by construct, how local relation, grouping, mapping and alignment structures are expressed in a named target model and version, including which constructs have no equivalent, what fallback is emitted, and which direction the crosswalk has been tested in. It is referenced by every package produced under it.", "media_or_form": [ "Construct-to-construct rule table naming source construct, target construct and fallback", "Specification document with a per-construct clause and a tested-direction statement" ], "identity_strategy": "Use the identifier issued by the body that publishes the crosswalk where one exists; otherwise mint a governed identifier in the maintaining Dimension's namespace, qualified by the identifiers of the two models it bridges. A UUID or ULID is a last resort and is marked as locally minted.", "serial": false, "source_refs": [ "SRC-007", "SRC-008", "SRC-014", "SRC-019" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "ct-gov-bundle-lifecycle-authority", "name": "Concept lifecycle, decision authority and change control", "description": "How a concept record enters the register, moves between governed states under a named authority, is bound to releases, and accumulates an immutable change history including merge, split and redirect.", "rationale": "SKOS defines the concept but supplies no status or versioning vocabulary, so registration status, workflow authority and version chains must be sourced from registration and cataloguing standards and modelled explicitly on the stable concept rather than on any label.", "source_refs": [ "SRC-001", "SRC-026", "SRC-029", "SRC-019", "SRC-021" ], "layers": [ { "id": "ct-gov-layer-registration-lifecycle", "name": "Registration states, authority and retirement", "description": "The governed state set, who may move a record between states, and how a concept leaves active use without its identifier ever being reused.", "source_refs": [ "SRC-026", "SRC-029", "SRC-028", "SRC-018" ], "findings": [ { "id": "ct-gov-finding-registration-state-model", "name": "Registration state model and transition rules", "description": "The enumerated states a concept record may occupy, split into lifecycle states (development and usage preference) and documentation states (no further development), with entry criteria, permitted transitions and the meaning each state guarantees to consumers.", "source_refs": [ "SRC-026", "SRC-029", "SRC-019", "SRC-001" ], "questions": [ { "id": "ct-gov-q-state-set", "text": "Which registration states may this concept record occupy, and which are lifecycle states rather than documentation-only states?", "kind": "state", "answer_data": [ "Registration status code and its governing code system", "Status category flag: lifecycle or documentation" ] }, { "id": "ct-gov-q-state-entry-criteria", "text": "What mandatory attributes and associations must be complete before the record may progress beyond the recorded state?", "kind": "requirement", "answer_data": [ "Completeness criteria set per target state", "Unsatisfied criteria list at the time of evaluation" ] }, { "id": "ct-gov-q-state-transition-authority", "text": "Which role must authorise each transition, and which transitions are irreversible?", "kind": "authority", "answer_data": [ "Transition-to-required-role matrix", "Irreversibility flag and statement of authorisation" ] }, { "id": "ct-gov-q-state-consumer-guarantee", "text": "What stability guarantee does each state give a downstream consumer about the concept's meaning?", "kind": "classification", "answer_data": [ "Per-state consumer guarantee statement", "Whether the state permits definition-scope change" ] } ], "data_elements": [ { "id": "ct-gov-de-registration-status", "name": "Registration status", "description": "Coded state of the concept record within the registration authority's workflow.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-026", "SRC-029" ] }, { "id": "ct-gov-de-status-category", "name": "Status category", "description": "Whether the status is a lifecycle category or a documentation category.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "ct-gov-de-status-authorisation", "name": "Statement of authorisation", "description": "The recorded basis on which the current status was conferred, naming the authorising body.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "ct-gov-de-permitted-transitions", "name": "Permitted transition set", "description": "Allowed next states from the current state, each with its required role and reversibility flag.", "value_kind": "collection", "cardinality": "1", "required": true, "source_refs": [ "SRC-026", "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "The state model is a governed enumeration plus a transition matrix. It is reference data resolved against a code system and a role registry, carries no payload, and would be falsified rather than supported by materialising it as a document; the decision that moved the record is captured separately as a decision record." }, { "id": "ct-gov-finding-decision-authority-workflow", "name": "Decision authority and proposal workflow", "description": "Who holds decision authority over this concept, the proposal-review-approval steps a change must pass, and the auditable record of each governed decision including dissent and appeal.", "source_refs": [ "SRC-026", "SRC-020", "SRC-019", "SRC-018" ], "questions": [ { "id": "ct-gov-q-decision-mandate", "text": "Who holds decision authority over this concept, and under what documented mandate?", "kind": "authority", "answer_data": [ "Decision body identifier and mandate reference", "Scope of authority: which change classes it may approve" ] }, { "id": "ct-gov-q-decision-workflow", "text": "What proposal, review and approval steps must a change pass before publication?", "kind": "process", "answer_data": [ "Ordered workflow step list with required role per step", "Step outcome and completion event time" ] }, { "id": "ct-gov-q-decision-evidence", "text": "What evidence, options considered and dissent must a decision capture to remain auditable?", "kind": "decision", "answer_data": [ "Considered options with rationale for the chosen one", "Recorded dissent, abstention or minority position" ] }, { "id": "ct-gov-q-decision-appeal", "text": "How is a contested or appealed decision recorded without rewriting the original decision?", "kind": "exception", "answer_data": [ "Appeal reference and superseding decision identifier", "Supersession pointer on the original, which remains readable" ] } ], "data_elements": [ { "id": "ct-gov-de-decision-body", "name": "Decision body reference", "description": "Reference to the party or committee holding authority for the decision class.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-026", "SRC-019" ] }, { "id": "ct-gov-de-decision-role-binding", "name": "Role-qualified attribution", "description": "Agent reference plus the role in which the agent acted for this decision.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-020", "SRC-019" ] }, { "id": "ct-gov-de-decision-outcome", "name": "Decision outcome", "description": "Coded outcome of the governed decision, such as approved, rejected, deferred or withdrawn.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "ct-gov-de-decision-supersedes", "name": "Superseded decision reference", "description": "Pointer from a later decision to the decision it replaces, leaving the original intact.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] } ], "artifacts": [ { "id": "ct-gov-artifact-decision-record", "name": "Concept governance decision record", "description": "Immutable record of one governed decision about this concept: the question put, options considered, outcome, role-qualified participants, dissent, and the event and effective times.", "media_or_form": [ "structured governance record", "human-readable minute rendition" ], "serial": true, "identity_strategy": "Concept-scoped serial: concept identifier as scope discriminator plus a never-reused integer sequence dedicated to decision records; if the registration authority's case-management system already assigns a decision key, that authoritative master-system identifier takes priority and the serial becomes a secondary local reference.", "source_refs": [ "SRC-026", "SRC-020" ] } ], "inline_only_rationale": null }, { "id": "ct-gov-finding-deprecation-retirement-succession", "name": "Deprecation, retirement and succession", "description": "Grounds for deprecating rather than correcting a concept, the successor relationship offered to clients, the guarantee that a retired identifier is never reused or repointed, and how long resolution is promised.", "source_refs": [ "SRC-028", "SRC-021", "SRC-024", "SRC-027" ], "questions": [ { "id": "ct-gov-q-deprecation-grounds", "text": "On what grounds may this concept be deprecated instead of corrected in place?", "kind": "lifecycle", "answer_data": [ "Coded obsolescence reason, for example merged, split, out of scope or placeholder removed", "Narrative justification and the deciding authority reference" ] }, { "id": "ct-gov-q-successor-binding", "text": "Which successor concept replaces the deprecated concept, and is the replacement authoritative or merely advisory?", "kind": "relationship", "answer_data": [ "Authoritative replacement reference, zero or one", "Advisory alternative references, zero to many" ] }, { "id": "ct-gov-q-deprecation-client-duty", "text": "What must a client still holding the deprecated identifier do, and until when is resolution guaranteed?", "kind": "interoperability", "answer_data": [ "Client migration instruction and target", "Resolution guarantee end instant or an explicit perpetual commitment" ] }, { "id": "ct-gov-q-identifier-never-reuse", "text": "How is a retired identifier prevented from ever being reused or repointed to a different meaning?", "kind": "identity", "answer_data": [ "Tombstone record retained in the namespace register", "Minting-service exclusion entry for the retired identifier" ] } ], "data_elements": [ { "id": "ct-gov-de-deprecated-flag", "name": "Deprecated flag", "description": "Boolean marking that the concept is no longer in active use, independent of whether a successor exists.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-028" ] }, { "id": "ct-gov-de-obsolescence-reason", "name": "Obsolescence reason", "description": "Coded reason for obsolescence, distinguishing merge, split, scope removal and placeholder removal.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "ct-gov-de-replaced-by", "name": "Replaced by", "description": "Authoritative successor concept reference that consumers should substitute.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028", "SRC-024" ] }, { "id": "ct-gov-de-consider-alternatives", "name": "Advisory alternatives", "description": "Non-authoritative candidate concepts offered where no exact successor exists.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] } ], "artifacts": [ { "id": "ct-gov-artifact-deprecation-notice", "name": "Concept deprecation notice", "description": "Published notice that a concept has been deprecated or retired, carrying the obsolescence reason, successor or advisory alternatives, client migration instruction, resolution guarantee and effective instant.", "media_or_form": [ "structured governance record", "published human-readable notice" ], "serial": true, "identity_strategy": "Concept-scoped serial: concept identifier as scope discriminator plus a never-reused integer sequence dedicated to deprecation notices, so a re-deprecation after reinstatement produces a new number rather than overwriting the first.", "source_refs": [ "SRC-028", "SRC-021" ] } ], "inline_only_rationale": null } ] }, { "id": "ct-gov-layer-change-version-control", "name": "Versioning, change history and duplicate resolution", "description": "How a concept record's state is bound to an immutable release, how every change is recorded append-only with cause and time, and how duplicates are detected and resolved by merge, split or redirect.", "source_refs": [ "SRC-027", "SRC-019", "SRC-021", "SRC-028", "SRC-025" ], "findings": [ { "id": "ct-gov-finding-version-release-binding", "name": "Version designation and release binding", "description": "Which immutable release of the owning scheme a governed record state belongs to, how a change is classified as editorial, additive or breaking, and how a version designation stays distinct from record identity.", "source_refs": [ "SRC-027", "SRC-019", "SRC-021", "SRC-031" ], "questions": [ { "id": "ct-gov-q-release-binding", "text": "Which immutable release of the owning concept scheme does this governed record state belong to?", "kind": "identity", "answer_data": [ "Release identifier and its resolvable version IRI", "Record state digest as published in that release" ] }, { "id": "ct-gov-q-change-classification", "text": "How is a proposed change classified as editorial, additive or breaking, and who performs that classification?", "kind": "classification", "answer_data": [ "Change class code and the classification rule applied", "Classifying agent reference and role" ] }, { "id": "ct-gov-q-release-immutability", "text": "What guarantees that a published release remains unaltered and retrievable at a later date?", "kind": "constraint", "answer_data": [ "Immutability commitment statement and its custodian", "Retained release digest with algorithm, mode and mode version" ] }, { "id": "ct-gov-q-version-versus-identity", "text": "How does a version designation relate to, and remain distinct from, the concept record identifier?", "kind": "definition", "answer_data": [ "Concept identifier that is stable across all releases", "Version designation string, which may be date-formed but is never identity" ] } ], "data_elements": [ { "id": "ct-gov-de-release-reference", "name": "Bound release reference", "description": "Identifier of the scheme release in which this record state was published.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-027", "SRC-019" ] }, { "id": "ct-gov-de-version-designation", "name": "Version designation", "description": "Human-facing version label for the release, which may use a date form but never serves as identity.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-027", "SRC-031" ] }, { "id": "ct-gov-de-change-class", "name": "Change class", "description": "Coded classification of the change as editorial, additive or breaking.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-031", "SRC-019" ] }, { "id": "ct-gov-de-previous-version", "name": "Previous version reference", "description": "Pointer to the immediately preceding published state of this concept, forming the version chain.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-029" ] } ], "artifacts": [], "inline_only_rationale": "Release binding and change classification are pointers and codes on the concept record; the release artifact itself is owned by the parent scheme model and the interchange package is owned by the relation split, so materialising a local artifact here would duplicate a neighbour's payload." }, { "id": "ct-gov-finding-change-history-audit-trail", "name": "Change history, event timing and audit trail", "description": "Append-only atomic change records with the causing activity, agent and decision, separated event, effective and ingestion times, and the ability to reconstruct the record as it stood at any past instant.", "source_refs": [ "SRC-020", "SRC-011", "SRC-021", "SRC-025", "SRC-029" ], "questions": [ { "id": "ct-gov-q-change-delta", "text": "What atomic change was made, to which element of the concept record, and from what prior value?", "kind": "event", "answer_data": [ "Changed element path with prior and new canonical values", "Pre-image digest of the record before the change" ] }, { "id": "ct-gov-q-change-causation", "text": "Which activity, agent and prior decision caused this change?", "kind": "provenance", "answer_data": [ "Causing activity reference and its agent attribution", "Referenced decision record identifier" ] }, { "id": "ct-gov-q-change-time-separation", "text": "When did the change occur, when does it take effect, and when was it ingested into this register?", "kind": "temporal", "answer_data": [ "Event time, effective time and ingestion time as separate values", "Whether effective time is prospective or retrospective" ] }, { "id": "ct-gov-q-history-reconstruction", "text": "How can a consumer reconstruct this concept record exactly as it stood at an arbitrary past instant?", "kind": "evidence", "answer_data": [ "Ordered change sequence with inverse operations", "Verifiable digest of each reconstructed state" ] }, { "id": "ct-gov-q-change-correction", "text": "How is an erroneous change record corrected without deleting or rewriting history?", "kind": "quality", "answer_data": [ "Correcting change record with a pointer to the erroneous one", "Non-destructive annotation marking the original as superseded" ] } ], "data_elements": [ { "id": "ct-gov-de-change-operation", "name": "Change operation", "description": "Typed, reversible operation over a semantic path: add, replace, remove or move, with prior and new values.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-025", "SRC-021" ] }, { "id": "ct-gov-de-event-time", "name": "Event time", "description": "Instant at which the governed act actually occurred, as RFC 3339 with seconds and explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-020" ] }, { "id": "ct-gov-de-effective-time", "name": "Effective time", "description": "Instant from which the change takes effect for consumers, which may differ from the event time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-024" ] }, { "id": "ct-gov-de-ingestion-time", "name": "Observation or ingestion time", "description": "Instant at which the register captured or received the record of the change.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-020" ] }, { "id": "ct-gov-de-preimage-digest", "name": "Pre-image digest", "description": "Digest of the canonical record state immediately before the change, used for conflict detection.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] } ], "artifacts": [ { "id": "ct-gov-artifact-change-record", "name": "Concept change record", "description": "Immutable, append-only record of one accepted change to a concept record, carrying reversible operations, pre-image digest, causing activity and decision references, and separated event, effective and ingestion times.", "media_or_form": [ "structured governance record", "version-history rendition for publication" ], "serial": true, "identity_strategy": "Concept-scoped serial: concept identifier as scope discriminator plus a never-reused integer sequence dedicated to change records, giving a total order of changes per concept independent of clock skew between contributing systems.", "source_refs": [ "SRC-020", "SRC-021", "SRC-025" ] } ], "inline_only_rationale": null }, { "id": "ct-gov-finding-duplicate-merge-split", "name": "Duplicate candidacy, merge, split and redirect", "description": "Evidence by which another record is judged to denote the same concept, which identifier survives a merge, how a split disambiguates inbound references, and how automated duplicate signals are bounded.", "source_refs": [ "SRC-028", "SRC-001", "SRC-018", "SRC-023" ], "questions": [ { "id": "ct-gov-q-duplicate-evidence", "text": "By what evidence is another record judged to denote the same unit of thought as this one?", "kind": "evidence", "answer_data": [ "Sameness evidence set: definition comparison, notation, shared authoritative source", "Confidence statement and the reviewing agent" ] }, { "id": "ct-gov-q-merge-survivor", "text": "Which identifier survives a merge, and how are the non-surviving identifiers redirected?", "kind": "decision", "answer_data": [ "Surviving concept identifier and the survivorship rule applied", "Redirect entries from each non-surviving identifier to the survivor" ] }, { "id": "ct-gov-q-split-disambiguation", "text": "When a concept is split, how are prior usages and inbound references disambiguated across the successors?", "kind": "composition", "answer_data": [ "Successor concept identifiers with their delimited scopes", "Disposition rule for inbound references that cannot be resolved automatically" ] }, { "id": "ct-gov-q-duplicate-signal-tolerance", "text": "Which automated duplicate-candidate signals are used, and what false-positive tolerance is accepted before human review?", "kind": "measurement", "answer_data": [ "Signal list with score and threshold per signal", "Required human confirmation step and its role" ] } ], "data_elements": [ { "id": "ct-gov-de-duplicate-candidate", "name": "Duplicate candidate", "description": "Reference to another concept record proposed as denoting the same concept, with signal scores.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-023", "SRC-001" ] }, { "id": "ct-gov-de-merge-survivorship", "name": "Merge survivorship rule", "description": "Rule and its outcome determining which identifier survives, such as earliest registration or widest external adoption.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "ct-gov-de-redirect-entry", "name": "Redirect entry", "description": "Directed mapping from a non-surviving or split-source identifier to one or more successors.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028", "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "Merge, split and redirect outcomes are structural pointers held on the concept records themselves and are published through the deprecation notice and change record already declared elsewhere in this bundle; adding a separate merge artifact would duplicate those payloads and create a second, competing source of truth for successor resolution." } ] } ] }, { "id": "ct-gov-bundle-evidence-assurance", "name": "Provenance, evidence, validation and editorial quality", "description": "Where the concept's meaning comes from, what warrant justifies it, which constraint sets it is checked against, and how editorially complete and mature the record is.", "rationale": "Best practice requires complete origin information, quality information and fitness statements alongside the data itself; validation reports and quality measurements give falsifiable assurance rather than an unevidenced conformance claim.", "source_refs": [ "SRC-021", "SRC-022", "SRC-023", "SRC-020", "SRC-018" ], "layers": [ { "id": "ct-gov-layer-provenance-evidence", "name": "Authoritative sources and evidentiary warrant", "description": "The external authority for the concept's definition, the derivation relationship to it, and the warrant that justifies admitting the concept at all.", "source_refs": [ "SRC-020", "SRC-021", "SRC-024", "SRC-018" ], "findings": [ { "id": "ct-gov-finding-authoritative-source-provenance", "name": "Authoritative source and derivation provenance", "description": "Which external source is authoritative for this concept's definition and at which version, whether the concept is originated, adopted verbatim, adapted or derived, and how later change or withdrawal of that source is reflected.", "source_refs": [ "SRC-020", "SRC-024", "SRC-021", "SRC-001" ], "questions": [ { "id": "ct-gov-q-authoritative-source", "text": "Which external source is authoritative for this concept's definition, and at what version or publication date?", "kind": "provenance", "answer_data": [ "Source reference with citation and version or date", "Locator or clause within the source" ] }, { "id": "ct-gov-q-derivation-mode", "text": "Is this concept originated locally, adopted verbatim, adapted, or derived from another vocabulary?", "kind": "classification", "answer_data": [ "Derivation mode code", "Derivation link to the upstream concept where one exists" ] }, { "id": "ct-gov-q-provenance-attribution", "text": "Which agent asserted the current definition, and on whose behalf did that agent act?", "kind": "ownership", "answer_data": [ "Asserting agent reference and role", "Delegating organisation reference" ] }, { "id": "ct-gov-q-source-drift", "text": "How is a later change to, or withdrawal of, the authoritative source reflected in this record?", "kind": "lifecycle", "answer_data": [ "Source-monitoring commitment and review interval", "Triggered change class when the source changes materially" ] } ], "data_elements": [ { "id": "ct-gov-de-authoritative-source", "name": "Authoritative source reference", "description": "Citation and identifier of the source that is authoritative for the definition, with its version or date.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024", "SRC-021" ] }, { "id": "ct-gov-de-derivation-mode", "name": "Derivation mode", "description": "Coded relationship to the upstream source: originated, adopted, adapted or derived.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-020" ] }, { "id": "ct-gov-de-custody-statement", "name": "Custody and ownership-change statement", "description": "Narrative of changes in ownership and custody significant for authenticity and interpretation.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] } ], "artifacts": [], "inline_only_rationale": "Authoritative-source provenance is a set of outbound citations and derivation pointers to resources held and versioned by their own publishers. Copying source text locally would create an uncontrolled and rapidly stale replica and could breach the source licence; the reference plus version binding is the defensible representation." }, { "id": "ct-gov-finding-warrant-evidence-dossier", "name": "Warrant and rationale evidence", "description": "The governance-grade evidence set justifying that this is a distinct unit of thought with the scope claimed, held by reference to retained attestations and citations rather than restated locally.", "source_refs": [ "SRC-018", "SRC-021", "SRC-020", "SRC-024" ], "questions": [ { "id": "ct-gov-q-warrant-basis", "text": "What warrant justifies admitting this as a distinct concept rather than a variant of an existing one?", "kind": "evidence", "answer_data": [ "Warrant type: literary, organisational or user warrant", "Distinguishing criterion against the nearest existing concept" ] }, { "id": "ct-gov-q-evidence-inventory", "text": "Which retained attestations and citations support the current definition, and where are they held?", "kind": "composition", "answer_data": [ "References to retained usage attestations held by the lexical core structures", "Holding system identifier and retrieval path for each item" ] }, { "id": "ct-gov-q-counter-evidence", "text": "What counter-evidence or rejected alternative scoping was considered, and why was it set aside?", "kind": "decision", "answer_data": [ "Rejected scoping options with reasons", "Reference to the decision record that resolved the question" ] }, { "id": "ct-gov-q-evidence-nondisclosure", "text": "When supporting evidence cannot be published, what minimal defensible reference is exposed instead?", "kind": "privacy", "answer_data": [ "Restricted-reference stub with holding system and access route", "Redaction or minimisation note, without the restricted content itself" ] } ], "data_elements": [ { "id": "ct-gov-de-warrant-type", "name": "Warrant type", "description": "Coded basis for admitting the concept: literary, organisational or user warrant.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "ct-gov-de-evidence-reference", "name": "Evidence reference", "description": "Pointer to a retained attestation or citation supporting the definition, with its holding system.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021", "SRC-020" ] }, { "id": "ct-gov-de-evidence-disclosure-state", "name": "Evidence disclosure state", "description": "Whether each evidence item is publishable, restricted or embargoed, and the basis recorded for that state.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024" ] } ], "artifacts": [], "inline_only_rationale": "The retained evidence payloads are usage attestations owned by the lexical core structures under ct-core-usage-attestation. This finding carries only warrant typing, evidence pointers and disclosure state; declaring a local evidence artifact would duplicate an adjacent split's artifact and split custody of the same material." } ] }, { "id": "ct-gov-layer-validation-quality", "name": "Validation, conformance and editorial quality", "description": "Which constraint sets apply and what the last check returned, and how editorially complete and mature the record is on a governed scale.", "source_refs": [ "SRC-022", "SRC-023", "SRC-021", "SRC-018" ], "findings": [ { "id": "ct-gov-finding-validation-conformance", "name": "Constraint declaration and conformance reporting", "description": "Which constraint sets are declared applicable at which severity, the outcome of the most recent check against a named record state and constraint version, and what conformance is claimed against external standards.", "source_refs": [ "SRC-022", "SRC-021", "SRC-025", "SRC-001" ], "questions": [ { "id": "ct-gov-q-constraint-applicability", "text": "Which constraint sets apply to this concept record, at which severity, and who declared them applicable?", "kind": "validation", "answer_data": [ "Constraint set reference with its version identifier", "Declared severity per constraint and the declaring role" ] }, { "id": "ct-gov-q-validation-outcome", "text": "What did the most recent check return, against which record state and which constraint-set version?", "kind": "quality", "answer_data": [ "Conformance boolean plus per-result focus node, path and severity", "Digest of the validated record state and the constraint set version" ] }, { "id": "ct-gov-q-blocking-versus-advisory", "text": "Which failures block publication and which are advisory only?", "kind": "constraint", "answer_data": [ "Blocking severity threshold for each registration state", "Waiver reference where a blocking failure was accepted" ] }, { "id": "ct-gov-q-external-conformance-claim", "text": "What conformance to an external standard is claimed for this record, and on what evidence?", "kind": "interoperability", "answer_data": [ "Named standard, clause and claim scope", "Evidence reference supporting the claim, or an explicit no-claim statement" ] } ], "data_elements": [ { "id": "ct-gov-de-constraint-set-reference", "name": "Constraint set reference", "description": "Versioned reference to the externally owned constraint or shape set declared applicable.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "ct-gov-de-conformance-flag", "name": "Conformance flag", "description": "Whether the validated record state satisfied all constraints above the blocking threshold.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "ct-gov-de-result-severity", "name": "Result severity", "description": "Severity assigned to an individual validation result, such as violation, warning or informational.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "ct-gov-de-conformance-claim", "name": "External conformance claim", "description": "Explicit claim of conformance to a named external standard clause, with its supporting evidence reference.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021" ] } ], "artifacts": [ { "id": "ct-gov-artifact-validation-report", "name": "Concept validation report", "description": "Retained report returned by an external evaluation of one concept record state against a named constraint-set version, carrying the conformance flag and individual results with focus node, path, source constraint and severity.", "media_or_form": [ "structured validation report", "human-readable report rendition" ], "serial": true, "identity_strategy": "Concept-scoped serial: concept identifier as scope discriminator plus a never-reused integer sequence dedicated to validation reports; where the evaluating system issues its own run identifier, that authoritative master-system identifier is recorded and takes priority for cross-system correlation.", "source_refs": [ "SRC-022", "SRC-025" ] } ], "inline_only_rationale": null }, { "id": "ct-gov-finding-editorial-quality-status", "name": "Editorial completeness, maturity and quality measurement", "description": "Which editorial criteria the record has met, how mature and stable the definition is on a governed scale, which quality dimension each measurement addresses, and when the next editorial review falls due.", "source_refs": [ "SRC-023", "SRC-018", "SRC-021", "SRC-007" ], "questions": [ { "id": "ct-gov-q-editorial-completeness", "text": "Which editorial completeness criteria has this record met, and which remain open?", "kind": "measurement", "answer_data": [ "Met and unmet criteria lists with the assessing agent", "Assessment event time" ] }, { "id": "ct-gov-q-definition-maturity", "text": "How mature and stable is the definition, expressed on a governed scale?", "kind": "classification", "answer_data": [ "Maturity or term-status code from a governed scale", "Expected stability statement for the next release" ] }, { "id": "ct-gov-q-quality-dimension-metric", "text": "Which quality dimension does each recorded measurement address, and by which metric was it computed?", "kind": "quality", "answer_data": [ "Quality dimension and category references", "Metric reference, computed value and unit" ] }, { "id": "ct-gov-q-editorial-review-cycle", "text": "Who last reviewed the editorial content, and when is the next review due?", "kind": "temporal", "answer_data": [ "Last review event time and reviewing agent", "Next review due instant and the rule that sets it" ] } ], "data_elements": [ { "id": "ct-gov-de-editorial-criteria", "name": "Editorial criteria assessment", "description": "Per-criterion met or unmet result for the record's editorial completeness.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-023" ] }, { "id": "ct-gov-de-maturity-code", "name": "Definition maturity code", "description": "Governed code for how settled the definition is, distinct from registration status.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023", "SRC-029" ] }, { "id": "ct-gov-de-quality-measurement", "name": "Quality measurement", "description": "A computed value for a named metric addressing a named quality dimension, with its unit and generating activity.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "ct-gov-de-next-review-due", "name": "Next review due", "description": "Instant by which the next editorial review must occur, as RFC 3339 with seconds and offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Quality here is a set of dimension-scoped measurements and status codes attached to the record and recomputed on each assessment. They are references into an externally owned metric catalogue plus scalar values; freezing them into an artifact would create a stale parallel copy of measurements whose authoritative form is the live measurement series." } ] } ] }, { "id": "ct-gov-bundle-stewardship-custody", "name": "Stewardship, namespace, rights and retention", "description": "Who owns and maintains the concept record, who controls the namespace its identifier lives in, and under what rights, access, embargo and retention terms the record and its evidence are held.", "rationale": "Persistent identifiers require a named custodian and an explicit persistence commitment, and licence, access rights and rights holder must be stated for reusable data; retention and disposition instructions are carried but executed by the records authority.", "source_refs": [ "SRC-021", "SRC-024", "SRC-027", "SRC-030", "SRC-026" ], "layers": [ { "id": "ct-gov-layer-ownership-namespace", "name": "Ownership, stewardship and namespace authority", "description": "The owning organisation, the named steward, delegated responsibilities and escalation, and the namespace that mints and guarantees the identifier.", "source_refs": [ "SRC-026", "SRC-021", "SRC-027", "SRC-019" ], "findings": [ { "id": "ct-gov-finding-ownership-stewardship", "name": "Ownership, stewardship and delegation", "description": "Which organisation owns the record, which named steward maintains it, what is delegated without transferring ownership, how escalation works when a steward is unavailable, and how an ownership transfer is recorded without breaking identifier continuity.", "source_refs": [ "SRC-026", "SRC-019", "SRC-024", "SRC-020" ], "questions": [ { "id": "ct-gov-q-owning-organisation", "text": "Which organisation owns this concept record, and which named steward maintains it?", "kind": "ownership", "answer_data": [ "Owning organisation reference and steward reference", "Effective period of the stewardship assignment" ] }, { "id": "ct-gov-q-steward-escalation", "text": "What is the escalation and hand-over path when the steward is unavailable or the role lapses?", "kind": "process", "answer_data": [ "Ordered escalation contacts with roles", "Lapse threshold and default custodian" ] }, { "id": "ct-gov-q-delegated-responsibility", "text": "Which responsibilities are delegated to a contributor without transferring ownership?", "kind": "authority", "answer_data": [ "Delegated action list with the delegating agent", "Actions explicitly reserved to the owner" ] }, { "id": "ct-gov-q-ownership-transfer", "text": "How is a change of owning organisation recorded without breaking identifier continuity?", "kind": "lifecycle", "answer_data": [ "Transfer decision reference and effective time", "Continuity commitment for the identifier and its resolution" ] } ], "data_elements": [ { "id": "ct-gov-de-owning-organisation", "name": "Owning organisation", "description": "Party accountable for the concept record and its governance outcomes.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-026", "SRC-024" ] }, { "id": "ct-gov-de-steward", "name": "Steward assignment", "description": "Named agent responsible for maintaining the record, with the effective period of the assignment.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-026", "SRC-019" ] }, { "id": "ct-gov-de-delegated-actions", "name": "Delegated action set", "description": "Actions a contributor may perform under delegation, and those reserved to the owner.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-026" ] } ], "artifacts": [], "inline_only_rationale": "Ownership and stewardship are role-qualified references into an externally owned party model plus effective periods. The party's identity, contact data and organisational lifecycle belong to that model, so this finding carries bindings only and must not materialise a local party document." }, { "id": "ct-gov-finding-identifier-namespace-stewardship", "name": "Identifier and namespace stewardship", "description": "Which namespace mints the concept identifier, who controls it, what resolution and persistence is committed, how identifiers are minted and prevented from collision or reuse, and what happens if the namespace is transferred or discontinued.", "source_refs": [ "SRC-021", "SRC-027", "SRC-028", "SRC-001" ], "questions": [ { "id": "ct-gov-q-namespace-control", "text": "Which namespace mints this concept's identifier, and which body controls that namespace?", "kind": "identity", "answer_data": [ "Namespace identifier or base IRI", "Controlling body reference and its mandate" ] }, { "id": "ct-gov-q-persistence-commitment", "text": "What resolution and persistence commitment is made for the identifier, and for how long?", "kind": "constraint", "answer_data": [ "Persistence commitment statement and its end condition, if any", "Resolution service reference and expected behaviour for retired identifiers" ] }, { "id": "ct-gov-q-minting-procedure", "text": "How are identifiers minted, reserved and prevented from collision or reuse across the namespace?", "kind": "process", "answer_data": [ "Minting procedure and reservation mechanism", "Exclusion register of retired identifiers" ] }, { "id": "ct-gov-q-namespace-discontinuity", "text": "What happens to identifiers if the namespace is transferred, forked or discontinued?", "kind": "exception", "answer_data": [ "Succession plan and receiving custodian", "Redirect or archival commitment for existing identifiers" ] } ], "data_elements": [ { "id": "ct-gov-de-namespace-reference", "name": "Namespace reference", "description": "Identifier or base IRI of the namespace in which the concept identifier is minted.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-027" ] }, { "id": "ct-gov-de-identifier-scheme", "name": "Identifier scheme", "description": "Governed scheme of the concept identifier, such as a scheme PURL, DOI, Handle, ARK or locally minted UUID or ULID.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-027" ] }, { "id": "ct-gov-de-persistence-commitment", "name": "Persistence commitment", "description": "Stated commitment to keep the identifier resolvable, with its custodian and any end condition.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-027" ] }, { "id": "ct-gov-de-reuse-exclusion", "name": "Reuse exclusion entry", "description": "Register entry blocking a retired identifier from being minted again for a different meaning.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] } ], "artifacts": [], "inline_only_rationale": "Namespace stewardship is expressed as references to an externally operated namespace and resolution service plus locally held commitments and exclusion entries. The minting service, resolver configuration and its operational records belong to that service, so no local artifact is declared." } ] }, { "id": "ct-gov-layer-rights-retention", "name": "Rights, access, embargo, retention and disposition", "description": "Under what licence and access terms the record and its evidence may be reused, what is embargoed until when, and which retention class and disposition instruction the record carries for execution elsewhere.", "source_refs": [ "SRC-024", "SRC-030", "SRC-021", "SRC-020" ], "findings": [ { "id": "ct-gov-finding-rights-access-embargo", "name": "Licence, access rights and embargo", "description": "The licence governing reuse of the concept record and its attached evidence, which parts are restricted and to whom, what is embargoed and what releases it, and whether attached evidence identifies a living person or carries third-party rights.", "source_refs": [ "SRC-024", "SRC-030", "SRC-021" ], "questions": [ { "id": "ct-gov-q-reuse-licence", "text": "Under which licence may this concept record and its attached evidence be reused?", "kind": "access", "answer_data": [ "Licence reference, preferably by URI, per record part", "Rights holder reference" ] }, { "id": "ct-gov-q-restricted-parts", "text": "Which parts of the record are restricted, to which parties, and on what stated basis?", "kind": "security", "answer_data": [ "Restricted element paths with permitted party or role", "Stated basis for the restriction" ] }, { "id": "ct-gov-q-embargo-release", "text": "Is any content embargoed, and which event or instant releases the embargo?", "kind": "temporal", "answer_data": [ "Embargoed element paths and embargo end instant or releasing event", "Fallback state if the releasing event never occurs" ] }, { "id": "ct-gov-q-personal-and-third-party-rights", "text": "Does any attached evidence identify a living person or carry third-party rights that constrain publication?", "kind": "privacy", "answer_data": [ "Flag for personal-data or third-party-rights content per evidence item", "Required review outcome and any minimisation or redaction applied" ] } ], "data_elements": [ { "id": "ct-gov-de-licence-reference", "name": "Licence reference", "description": "Reference to the licence controlling reuse of a record part or evidence item.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024", "SRC-030" ] }, { "id": "ct-gov-de-access-rights", "name": "Access rights statement", "description": "Statement of who may access a record part, or an indication of its security status.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "ct-gov-de-embargo-end", "name": "Embargo end", "description": "Instant or releasing event after which embargoed content becomes accessible.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030", "SRC-011" ] }, { "id": "ct-gov-de-personal-data-flag", "name": "Personal data or third-party rights flag", "description": "Marks an evidence item as identifying a living person or carrying third-party rights, triggering review before publication.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024", "SRC-030" ] } ], "artifacts": [], "inline_only_rationale": "Licence and access terms are carried as references to externally governed policies plus subject-specific constraint parameters. Policy interpretation, evaluation and enforcement belong to the rights policy model and its evaluator, so this finding holds bindings and flags only and declares no local policy artifact." }, { "id": "ct-gov-finding-retention-disposition", "name": "Retention class, disposition instruction and tombstone", "description": "The retention class and disposition instruction the concept record carries, legal-hold state, the tombstone that must survive any disposition, and which authority executes the disposition.", "source_refs": [ "SRC-024", "SRC-021", "SRC-028", "SRC-020" ], "questions": [ { "id": "ct-gov-q-retention-class", "text": "Which retention class applies to this record and to each attached evidence item?", "kind": "retention", "answer_data": [ "Retention class reference per record part", "Retention period start event and duration" ] }, { "id": "ct-gov-q-disposition-authority", "text": "Which authority approves and executes disposition, and what evidence of execution is returned?", "kind": "authority", "answer_data": [ "Disposition authority reference", "Execution confirmation reference returned to this register" ] }, { "id": "ct-gov-q-legal-hold", "text": "Is the record under a hold that suspends disposition, and what releases that hold?", "kind": "exception", "answer_data": [ "Hold flag with imposing authority and basis", "Hold release condition or instant" ] }, { "id": "ct-gov-q-tombstone-content", "text": "What minimum tombstone must survive after disposition so that references do not silently break?", "kind": "requirement", "answer_data": [ "Retained identifier, deprecation status and successor pointer", "Statement that the payload was disposed, with disposition event time" ] } ], "data_elements": [ { "id": "ct-gov-de-retention-class", "name": "Retention class reference", "description": "Reference to the externally owned retention class governing how long a record part is kept.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024", "SRC-021" ] }, { "id": "ct-gov-de-disposition-instruction", "name": "Disposition instruction", "description": "Coded instruction for end of retention, such as retain permanently, review, restrict or destroy payload.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "ct-gov-de-legal-hold", "name": "Hold flag", "description": "Whether disposition is suspended, with the imposing authority and release condition.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "ct-gov-de-tombstone", "name": "Tombstone record", "description": "Minimal surviving record retaining identifier, status and successor pointer after payload disposition.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028", "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "Retention and disposition are declarative instructions and references carried on the record. Scheduling, approval and physical destruction are executed by the adopting Dimension's records authority, whose disposition certificate is that authority's artifact; producing a competing local artifact would imply ownership of execution this model does not hold." } ] } ] } ] }, "functions": [ { "id": "ct-core-fn-establish-concept", "name": "Establish a concept identity", "description": "Create a new concept record with a persistent identifier and an initial delimitation, after confirming that no existing concept already covers the same intension.", "inputs": [ "Essential and delimiting characteristics proposed for the concept", "Candidate designations with language tags", "Subject field reference", "Assigning master system or governed namespace" ], "outputs": [ "Concept record carrying a primary identifier", "Optional governed IRI", "Recorded intension and extension boundedness" ], "preconditions": [ "A duplicate test has been run against existing concepts sharing any candidate designation", "The authority controlling the identifier namespace is known and reachable", "At least one delimiting characteristic distinguishes the new concept from its nearest neighbour" ], "effects": [ "A citable concept identifier exists and can be referenced by other models", "No scheme membership, editorial status or approval is asserted; those remain with the scheme and lifecycle areas", "The identity rule reference in force at creation is recorded for later split and merge decisions" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-005" ] }, { "id": "ct-core-fn-attach-designation", "name": "Attach a designation to a concept", "description": "Attach a term, appellation, proper name or symbol to an existing concept with its language tag, designation type and acceptability rating, reifying the designation where the active profile requires designation-level attributes.", "inputs": [ "Concept identifier", "Designation literal form or symbol asset reference", "Designation type", "BCP 47 language tag and optional script subtag", "Acceptability rating and rating-authority reference" ], "outputs": [ "Designation record linked to the concept", "Reified designation identifier where the profile requires one", "Constraint evaluation result for preferred-label uniqueness" ], "preconditions": [ "The language tag validates against the IANA Language Subtag Registry and any script subtag is justified against Suppress-Script", "The concept identifier resolves", "No conflicting preferred designation already exists for the same language tag unless the profile documents a relaxation" ], "effects": [ "The designation inventory is updated and the uniqueness constraint is re-evaluated", "The rating-authority pointer is stored as a reference only; the rating process, its approval and its audit record stay outside this model", "Hidden designations become available to retrieval without becoming displayable" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-009", "SRC-010" ] }, { "id": "ct-core-fn-record-definition-note", "name": "Record a definition or typed note", "description": "Attach a language-tagged definition or a typed note to a concept or to a specific designation, with its source reference and attachment level.", "inputs": [ "Concept or designation identifier", "Note or definition type", "Text and language tag", "Source document or clause reference" ], "outputs": [ "Typed definition or note attached at the declared level", "Classification of the note as meaning-bearing or editorial" ], "preconditions": [ "The language tag is valid", "The note type is drawn from the declared note vocabulary", "The definition cardinality rule for the target language permits the addition" ], "effects": [ "The meaning description of the concept is extended", "Editorial notes are marked filterable so interchange profiles can drop them without loss of meaning", "Circularity and bare-negation checks are queued for the validation function" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-005" ] }, { "id": "ct-core-fn-resolve-designation", "name": "Resolve a designation to candidate concepts", "description": "Look up a string in a given language and optional subject field and return the concepts whose designations match, with the evidence needed to disambiguate homographs.", "inputs": [ "Search string", "Language tag and optional fallback order", "Optional subject field filter", "Whether hidden designations are in scope" ], "outputs": [ "Ranked candidate concept identifiers", "Matched designation with its type, rating and language tag", "Homograph disambiguation evidence including subject field and delimiting characteristic" ], "preconditions": [ "The caller is authorised to read the designations in scope under the adopting Dimension's policy", "The language fallback order is declared" ], "effects": [ "Read-only: no concept, designation or note is modified", "Hidden designations may be matched but are not returned for display unless the caller is explicitly permitted", "A no-designation signal is returned rather than a coined term when no match exists in the requested language" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-009" ] }, { "id": "ct-core-fn-validate-core-record", "name": "Validate a concept record against declared constraints", "description": "Check a concept record and its designations, definitions and notes against the structural constraints declared for the active profile, and return findings.", "inputs": [ "Concept record with its designations, definitions and notes", "Declared interchange or validation profile", "Registry endpoints for language and script code validation" ], "outputs": [ "List of constraint findings with severity and constraint identifier", "Summary of unresolved references", "Statement of which constraints were not evaluated and why" ], "preconditions": [ "The applicable profile has been declared", "Any referenced registry is reachable, or its unavailability is reported rather than assumed to pass" ], "effects": [ "Findings are returned to the caller only", "No remediation, no enforcement and no audit record is written; enforcement and audit storage belong to the adopting Dimension and to the governance area", "A failed constraint marks the record unverified rather than altering it" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-008", "SRC-012" ] }, { "id": "ct-core-fn-project-interchange", "name": "Project a concept set to or from an interchange profile", "description": "Render concepts and their designations into a named interchange profile, or read them back, producing an explicit report of anything the target profile cannot carry.", "inputs": [ "Concept records in scope", "Target profile identifier such as SKOS, SKOS-XL with the ISO 25964 extension, TBX or OntoLex", "Language filter", "Direction of projection" ], "outputs": [ "Profile-shaped projection of the selected concepts", "Loss report naming every attribute the target profile cannot represent", "Mapping table used for the projection" ], "preconditions": [ "A documented mapping exists for the target profile", "Where the profile reifies designations, designation identifiers exist for every designation in scope" ], "effects": [ "Model semantics are unchanged; the projection is a rendering, not a redefinition", "A loss report is produced whenever designation-level attributes or note types cannot be carried", "No conformance to the target standard is claimed unless validation evidence for that profile is attached" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-008", "SRC-012" ] }, { "id": "ct-rel-fn-assert-semantic-relation", "name": "Assert a within-scheme semantic relation", "description": "Record a direct hierarchical or associative relation between two concepts inside one scheme, with its refined kind where the scheme supports refinement, and with the justification note that accompanies the assertion.", "inputs": [ "Source concept reference", "Target concept reference", "Relation type and refined kind", "Governing scheme reference", "Justification note" ], "outputs": [ "Stored direct relation assertion marked as authored", "Accepted or rejected status with the reason", "List of integrity conditions evaluated for this assertion" ], "preconditions": [ "Both endpoints resolve to concepts, not to grouping nodes or schemes", "The relation type is one the governing scheme permits", "For an associative assertion, no hierarchical path already connects the pair", "For a second broader assertion, the scheme permits polyhierarchy" ], "effects": [ "Only the direct form is stored; no transitive or ancestor statement is written", "Any materialised closure is marked stale for recomputation", "Approval, publication and change-history recording are left to the governance and lifecycle areas" ], "source_refs": [ "SRC-001", "SRC-008", "SRC-014" ] }, { "id": "ct-rel-fn-assert-mapping", "name": "Assert a cross-scheme mapping", "description": "Record a mapping from this concept to a concept in another scheme, with the mapping type, the target scheme reference, the bound scheme releases and the basis for the chosen strength.", "inputs": [ "Source concept reference", "Target concept reference and target scheme reference", "Mapping type", "Mapping set reference and bound releases", "Strength basis note" ], "outputs": [ "Stored mapping assertion within the named mapping set", "Accepted or rejected status with the reason", "Warning where the assertion will also enter the hierarchical closure" ], "preconditions": [ "The mapping set exists and declares both compared schemes with bound releases", "No disjoint mapping type is already asserted for the same pair", "The role asserting an exact match is authorised to assert interchangeability" ], "effects": [ "A broad or narrow match is flagged as also being a hierarchical assertion", "The symmetric counterpart is stored or left to inference according to the deployment's declared mode", "Adjudication of conflicting mappings is reported, not decided, here" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-007" ] }, { "id": "ct-rel-fn-derive-hierarchy-closure", "name": "Derive transitive hierarchy closure", "description": "Compute ancestor and descendant sets from direct hierarchical assertions, honouring per-kind chaining rules and stopping where a refined kind changes or a scheme boundary is crossed.", "inputs": [ "Concept reference", "Direction and depth limit", "Per-kind chaining rules", "Scheme boundary policy" ], "outputs": [ "Ordered ancestor or descendant set with every element marked derived", "Path list showing the direct assertions each derived element rests on", "Truncation notice where a depth limit or chaining stop applied" ], "preconditions": [ "The direct hierarchical graph is free of cycles", "Chaining rules are declared for every refined kind present on the paths" ], "effects": [ "Derived results are never written back as direct assertions", "Results are invalidated when any direct assertion on a contributing path changes", "No inference beyond hierarchical composition is performed" ], "source_refs": [ "SRC-001", "SRC-014" ] }, { "id": "ct-rel-fn-navigate-from-entry-point", "name": "Navigate a scheme from its entry points", "description": "Return a scheme's declared top concepts, or a computed entry set where none are declared, and traverse from there through direct relations and grouping constructs to a bounded depth.", "inputs": [ "Scheme reference", "Traversal depth", "Entry-point rule to apply when no top concept is declared", "Whether grouping nodes are included in the traversal" ], "outputs": [ "Entry-point list with each element marked declared or computed", "Traversal result with grouping nodes typed distinctly from concepts", "Notice where a declared top concept also asserts an in-scheme broader concept" ], "preconditions": [ "The scheme reference resolves", "The entry-point rule is declared where top concepts are absent" ], "effects": [ "Grouping nodes are returned as navigational structure and never as retrievable concepts", "Computed entry points are not persisted as top-concept declarations", "Traversal stops at the declared depth and reports truncation" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-008" ] }, { "id": "ct-rel-fn-check-relation-integrity", "name": "Check relation and mapping integrity", "description": "Evaluate this model's own relation, mapping, membership and grouping assertions against the declared integrity conditions and produce a findings report.", "inputs": [ "Concept, scheme or mapping-set scope", "Set of integrity conditions to evaluate", "Local rules on polyhierarchy, same-scheme mapping and membership derivation" ], "outputs": [ "Findings report listing each violation with the offending assertions", "Summary counts by condition", "Severity classification distinguishing standard-defined conditions from local rules" ], "preconditions": [ "The evaluation scope resolves", "Local rules are declared, so that local violations are not reported as standard violations" ], "effects": [ "Reports violations without deciding whether an exception is granted", "Gating, enforcement and persistence of the report are performed by the governance area or the adopting Dimension", "No assertion is modified by the check itself" ], "source_refs": [ "SRC-001", "SRC-008" ] }, { "id": "ct-rel-fn-compose-mapping-chain", "name": "Compose a mapping chain conservatively", "description": "Derive an indirect mapping between two concepts by composing mappings across sets, only where the mapping types involved licence composition.", "inputs": [ "Start concept reference", "Candidate mapping sets and their bound releases", "Per-type composability rules", "Maximum chain length" ], "outputs": [ "Derived mapping candidates marked derived, with the full chain that produced each", "Rejected chains with the reason for rejection", "Release-binding mismatches encountered along a chain" ], "preconditions": [ "Every set in the chain declares its bound releases on both sides", "Composability is declared for each mapping type on the path" ], "effects": [ "Chains of exact matches compose; chains involving a non-transitive type or a mix of types are rejected", "Derived candidates are never stored as asserted mappings without an explicit human assertion", "Chain composition performs no ontological inference" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-014" ] }, { "id": "ct-rel-fn-export-relation-package", "name": "Export a relation and mapping package", "description": "Produce an interchange package containing the selected closure of relations, memberships, mappings and alignments, projected through a named crosswalk into a target model and serialization.", "inputs": [ "Export scope and closure rule", "Target model, version and crosswalk reference", "Out-of-closure reference handling rule", "Serialization choice" ], "outputs": [ "Interchange package with manifest, digest and assertion count", "Loss declaration naming constructs the target model cannot carry", "List of out-of-closure references retained in the manifest" ], "preconditions": [ "A crosswalk exists for the target model and version", "The closure rule and out-of-closure handling are declared before export" ], "effects": [ "Derived assertions are either excluded or emitted with their derived marker intact", "Constructs with no target equivalent are degraded only under a declared fallback and are flagged", "Licence-restricted third-party mappings are excluded from the package" ], "source_refs": [ "SRC-016", "SRC-017", "SRC-019" ] }, { "id": "ct-rel-fn-import-relation-package", "name": "Import a relation and mapping package", "description": "Ingest an external package of relation, mapping and alignment assertions, verify its integrity, resolve or retain its references, and merge accepted assertions under the local rules.", "inputs": [ "Interchange package and its manifest", "Crosswalk reference for the source model", "Local integrity and permission rules", "Identifier resolution and namespace rules" ], "outputs": [ "Merged assertion set with provenance references retained as supplied", "Quarantine list for assertions that fail verification or integrity checks", "Report of unresolved references and constructs lost in translation" ], "preconditions": [ "The package digest and assertion count verify against the manifest", "Concept identifiers resolve or are explicitly retained as external references", "The crosswalk for the source model and version is available" ], "effects": [ "An assertion that would violate a declared integrity condition is quarantined rather than merged", "Unresolved references are retained as external references rather than silently dropped", "Imported assertions never overwrite locally authored assertions without an explicit merge decision" ], "source_refs": [ "SRC-007", "SRC-014", "SRC-016", "SRC-017" ] }, { "id": "ct-gov-function-submit-concept-proposal", "name": "Submit concept proposal", "description": "Register a candidate concept or a proposed change to an existing concept, opening a governance case without asserting any published state.", "inputs": [ "Proposed concept payload or change set", "Submitting agent reference and role", "Warrant type and evidence references" ], "outputs": [ "Governance case identifier", "Initial registration status of the candidate" ], "preconditions": [ "Submitting agent is authenticated and holds a submitter role", "Duplicate candidacy screening has been run and its result attached" ], "effects": [ "A governance case is opened and a change record is queued in pending state", "No published record state changes until a decision is recorded" ], "source_refs": [ "SRC-026", "SRC-018" ] }, { "id": "ct-gov-function-transition-registration-state", "name": "Transition registration state", "description": "Move a concept record from its current registration state to a permitted next state under the required authority.", "inputs": [ "Concept identifier", "Target registration status", "Authorising agent reference and statement of authorisation" ], "outputs": [ "New registration status with its category", "Emitted change record reference" ], "preconditions": [ "Target state appears in the permitted transition set for the current state", "All mandatory attributes and associations for the target state are complete", "Authorising agent holds the role required for that transition" ], "effects": [ "Registration status and its authorisation statement are updated", "Event, effective and ingestion times are recorded separately" ], "source_refs": [ "SRC-026", "SRC-011" ] }, { "id": "ct-gov-function-record-governance-decision", "name": "Record governance decision", "description": "Emit an immutable decision record capturing the question, options, outcome, participants and dissent for one governed decision.", "inputs": [ "Governance case identifier", "Decision outcome and rationale", "Role-qualified participant references and any dissent" ], "outputs": [ "Decision record artifact reference", "Effective time of the decision" ], "preconditions": [ "The deciding body holds authority for the change class in question", "Required review steps for that change class are complete" ], "effects": [ "A concept-scoped, never-reused decision record serial is allocated and sealed", "Any earlier decision it supersedes gains a supersession pointer and remains readable" ], "source_refs": [ "SRC-026", "SRC-020" ] }, { "id": "ct-gov-function-bind-concept-to-release", "name": "Bind concept state to a release", "description": "Bind the current concept record state to an immutable scheme release and classify the change since the previous bound state.", "inputs": [ "Concept identifier", "Release identifier and version designation", "Proposed change class" ], "outputs": [ "Bound release reference and record state digest", "Confirmed change class and previous version pointer" ], "preconditions": [ "The release is open for binding and has not yet been published", "The change class has been reviewed against the compatibility rules" ], "effects": [ "The record state becomes immutable once the release is published", "A breaking change forces a major increment and blocks reuse of any released version designation" ], "source_refs": [ "SRC-027", "SRC-019", "SRC-031" ] }, { "id": "ct-gov-function-validate-concept-record", "name": "Validate concept record", "description": "Submit a concept record state to an externally owned evaluation against declared constraint-set versions and retain the returned report.", "inputs": [ "Concept record state and its canonical digest", "Constraint set references with versions" ], "outputs": [ "Validation report artifact reference", "Conformance flag and blocking-failure list" ], "preconditions": [ "Each declared constraint set resolves to a specific version", "The record state digest is computed over the versioned canonical semantic form" ], "effects": [ "A concept-scoped validation report is retained and linked to the validated state", "Blocking failures prevent progression to states that require conformance; the evaluation itself is performed and owned by the external engine" ], "source_refs": [ "SRC-022", "SRC-025" ] }, { "id": "ct-gov-function-assess-duplicate-candidacy", "name": "Assess duplicate candidacy", "description": "Score and review whether another record denotes the same unit of thought, producing a reviewed sameness judgement rather than an automatic merge.", "inputs": [ "Concept identifier", "Candidate concept references with signal scores" ], "outputs": [ "Sameness judgement per candidate with confidence", "Referral for decision where the threshold is exceeded" ], "preconditions": [ "Signal thresholds and false-positive tolerance are configured for the scheme", "A human reviewer role is available for confirmation" ], "effects": [ "Candidates are recorded on the concept with their evidence", "No identifier is merged or redirected by this function alone" ], "source_refs": [ "SRC-023", "SRC-001" ] }, { "id": "ct-gov-function-execute-merge-or-split", "name": "Execute merge or split", "description": "Apply an approved merge or split, establishing survivorship, successor scopes and redirects for every affected identifier.", "inputs": [ "Approving decision record reference", "Surviving or successor concept identifiers", "Redirect entries for non-surviving or split-source identifiers" ], "outputs": [ "Updated successor pointers and redirect entries", "Deprecation notices for non-surviving identifiers" ], "preconditions": [ "An approving decision record exists and is in force", "Every affected identifier has a resolvable redirect target or a documented unresolvable disposition" ], "effects": [ "Non-surviving identifiers are deprecated with a terms-merged or term-split reason and never reused", "Change records are emitted for each affected concept" ], "source_refs": [ "SRC-028", "SRC-021" ] }, { "id": "ct-gov-function-deprecate-with-successor", "name": "Deprecate concept with successor", "description": "Mark a concept deprecated or retired, publish the obsolescence reason, successor or advisory alternatives, and the resolution guarantee.", "inputs": [ "Concept identifier and obsolescence reason", "Authoritative successor reference or advisory alternatives", "Effective instant and resolution guarantee" ], "outputs": [ "Deprecation notice artifact reference", "Updated deprecated flag and successor pointers" ], "preconditions": [ "A decision record authorising deprecation is in force", "The identifier is registered in the reuse exclusion register" ], "effects": [ "The concept ceases to be recommended for new use from the effective instant", "The identifier remains resolvable under the stated guarantee and is never reassigned" ], "source_refs": [ "SRC-028", "SRC-027", "SRC-021" ] }, { "id": "ct-gov-function-reconstruct-record-at-instant", "name": "Reconstruct concept record at an instant", "description": "Rebuild the concept record exactly as it stood at a given instant by replaying change records, for audit and dispute resolution.", "inputs": [ "Concept identifier", "Target instant as RFC 3339 with seconds and offset", "Time basis: event time, effective time or ingestion time" ], "outputs": [ "Reconstructed record state", "Verifying digest with algorithm, mode and mode version" ], "preconditions": [ "Change records for the concept are complete and unbroken over the interval", "The canonical-form version applicable at that instant is known" ], "effects": [ "A read-only reconstruction is produced without mutating stored history", "A gap or digest mismatch is reported as an integrity finding rather than silently interpolated" ], "source_refs": [ "SRC-020", "SRC-011", "SRC-025" ] }, { "id": "ct-gov-function-apply-retention-disposition", "name": "Apply retention and disposition instruction", "description": "Evaluate the retention class and hold state for a record part and hand the disposition instruction to the authority that executes it.", "inputs": [ "Concept identifier and record part reference", "Retention class reference and hold state" ], "outputs": [ "Disposition instruction and target authority reference", "Tombstone specification for anything to be disposed" ], "preconditions": [ "The retention period start event has occurred and the period has elapsed", "No hold is in force for the record part" ], "effects": [ "A disposition request is issued to the records authority, which performs the execution", "On confirmed disposition the tombstone is retained so identifiers and successor pointers do not break" ], "source_refs": [ "SRC-024", "SRC-021", "SRC-028" ] } ], "composition": [ { "target": "WM-KNW-002 — concept scheme or knowledge organization system (registered parent)", "relation": "CHILD", "purpose": "A concept is registered as a member of one or more schemes. This model carries only the inScheme reference and any scheme-scoped notation; scheme membership rules, top-concept designation, scheme versioning and scheme-wide editorial policy remain with the parent.", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "target": "W3C SKOS and SKOS-XL vocabulary", "relation": "ALIGN", "purpose": "Express concept identity, labels, notation and typed notes in RDF, including reified labels where designation-level attributes are needed. Alignment only: conformance is claimed solely where a validated profile and evidence exist.", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] }, { "target": "W3C OntoLex-Lemon lexicon model", "relation": "ALIGN", "purpose": "Attach lexical entries, canonical and other forms, written and phonetic representations and senses at the designation boundary. The lexicon's own entry inventory, sense inventory and editorial lifecycle remain in the lexical resource.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "ISO 25964 SKOS extension (iso-thes) thesaurus profile", "relation": "ALIGN", "purpose": "Map reified preferred and non-preferred terms and the term-level status property. The extension's hierarchical relation properties are used by the relations area of this model, not by the semantic core.", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "target": "TBX interchange profile (ISO 30042 dialects)", "relation": "ALIGN", "purpose": "Support concept-oriented terminological interchange of designations, grammatical data and usage notes, and drive the loss report when a dialect cannot carry an attribute. Dialect validation artefacts remain with the TBX specification.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "IANA Language Subtag Registry (IETF BCP 47)", "relation": "REFERENCE", "purpose": "Supplies the value space and validity rules for language, extlang, region and variant subtags, including Deprecated, Preferred-Value and Suppress-Script handling. Registry maintenance, subtag deprecation and republication remain with IANA and the IETF.", "required": true, "source_refs": [ "SRC-009" ] }, { "target": "ISO 15924 script code registry (Unicode Consortium Registration Authority)", "relation": "REFERENCE", "purpose": "Supplies four-letter script code values for the script subtag. Code allocation, change requests and distribution remain with the Registration Authority.", "required": true, "source_refs": [ "SRC-010" ] }, { "target": "Subject field or domain classification model", "relation": "REFERENCE", "purpose": "Supplies subject-field values used to bound the concept and disambiguate homographs. Classification structure, maintenance and revision handling remain in that model; this model stores the referenced value and its classification version.", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "Referent or real-world entity model", "relation": "REFERENCE", "purpose": "Identifies the objects the concept denotes. Entity attributes, identity resolution, matching and lifecycle remain in the entity model; this model records the denotation link and the exclusion statements.", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "target": "OMG Multiple Vocabulary Facility (MVF)", "relation": "ALIGN", "purpose": "Map a concept entry and its designation sets onto model elements expressed in multiple natural languages and terminologies, using MVF's normative mappings to ISO 1087 and SKOS. MVF's model-management semantics remain with MVF.", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "WM-KNW-002 concept scheme / knowledge-organization model (registered parent)", "relation": "CHILD", "purpose": "This concept is placed in schemes governed by the parent model. The parent owns scheme identity, maintenance agency, coverage and release policy; this model carries only the membership assertion, the top-concept declaration and the scheme reference used to bind a mapping.", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "target": "W3C SKOS and SKOS-XL vocabulary (http://www.w3.org/2004/02/skos/core#)", "relation": "ALIGN", "purpose": "Relation, mapping and grouping constructs are aligned to SKOS classes and properties, and SKOS integrity conditions are evaluated as alignments. The alignment is a recorded correspondence, not a conformance claim; no SKOS conformance is asserted without evidence.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "ISO 25964 thesaurus data model and the iso-thes RDF vocabulary (http://purl.org/iso25964/skos-thes)", "relation": "ALIGN", "purpose": "Refined hierarchical kinds, thesaurus arrays, concept groups, micro-thesauri and compound equivalence are aligned to ISO 25964 constructs where the governing scheme uses them. Where the clause-level normative text was not verified, the alignment is recorded as provisional.", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "target": "XKOS extension for statistical classifications (DDI Alliance)", "relation": "ALIGN", "purpose": "Classification levels and depth, refined semantic relations, and the Correspondence and ConceptAssociation structures used for many-to-many cross-scheme and cross-version mapping are aligned to XKOS for statistical classification schemes.", "required": false, "source_refs": [ "SRC-014" ] }, { "target": "Ontology term model (RDFS and OWL 2 classes, properties and individuals) and its reasoning environment", "relation": "REFERENCE", "purpose": "Semantic alignments point at ontology terms. This model carries the target reference, the alignment predicate and its declared entailment scope only. Entailment computation, reasoner configuration, closure materialisation and inference results are owned by the referenced reasoning environment.", "required": false, "source_refs": [ "SRC-015", "SRC-016" ] }, { "target": "OntoLex-Lemon lexical entry, form and sense model", "relation": "REFERENCE", "purpose": "Lexicalisation of the concept and lexical decomposition of multiword expressions are reached through the evokes and lexicalized-sense bridge. Entries, forms, senses, translations and label relations remain owned by the lexical model and are not reproduced here.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "IANA Language Subtag Registry (BCP 47 / RFC 5646)", "relation": "REFERENCE", "purpose": "Language, script and region subtags that scope a cross-lingual assertion are referenced from the registry. Subtag validity, registration and registry maintenance are external; this model only records the tag and the canonicalisation rule applied before comparison.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "DCAT catalogue and theme taxonomy model", "relation": "REFERENCE", "purpose": "A scheme may be referenced by a catalogue as a theme taxonomy and a concept used as a theme, which is why concept identifiers must be dereferenceable IRIs. Catalogue records, distributions and dataset description remain outside this model.", "required": false, "source_refs": [ "SRC-019" ] }, { "target": "WM-KNW-002 (parent knowledge organization system / concept scheme model)", "relation": "CHILD", "purpose": "Concepts governed here are registered within, and their record states bound to, releases of a scheme owned by the parent. Scheme membership, top concepts, scheme boundaries and scheme-level release identity remain with the parent; this model carries the scheme and release references only.", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "target": "Party / Agent model (person, organisation or software agent acting as submitter, steward, reviewer or registration authority)", "relation": "REFERENCE", "purpose": "Carry an agent reference plus the role in which that agent acted for a governance event. Agent identity, contact data and organisational lifecycle stay in the party model; this model never reproduces them.", "required": true, "source_refs": [ "SRC-020", "SRC-019" ] }, { "target": "Provenance activity record model (PROV-conformant Entity, Activity, Agent and derivation records)", "relation": "ALIGN", "purpose": "Express governance events so they project to activity, generation, derivation and attribution structures without redefining provenance semantics or owning any provenance store.", "required": false, "source_refs": [ "SRC-020" ] }, { "target": "Constraint / shape specification model (versioned constraint sets and severities)", "relation": "REFERENCE", "purpose": "Record which constraint-set version was declared applicable and retain the returned report. Constraint language, evaluation algorithm and engine execution are owned there; a reference to the evaluator grants no ownership of evaluation.", "required": true, "source_refs": [ "SRC-022" ] }, { "target": "Rights and licence policy model (machine-readable permissions, prohibitions, duties and constraints)", "relation": "REFERENCE", "purpose": "Carry the licence or policy reference and subject-specific constraint parameters such as embargo end. Policy interpretation, evaluation and enforcement belong to the policy model and its evaluator.", "required": false, "source_refs": [ "SRC-030", "SRC-024" ] }, { "target": "Records retention and disposition schedule model (retention classes, holds, disposition authority)", "relation": "REFERENCE", "purpose": "Carry the retention class reference, hold state and disposition instruction for this model's own records. Scheduling, approval and destruction execution remain with the records authority.", "required": false, "source_refs": [ "SRC-024", "SRC-021" ] }, { "target": "Vocabulary status and asset version-chain vocabulary (status codes, previous/next/current version, version notes)", "relation": "ALIGN", "purpose": "Map local registration status and version-chain pointers to published status and versioning terms rather than redefining them, while recording that the source note has been retired and migrated to another maintainer.", "required": false, "source_refs": [ "SRC-029", "SRC-019" ] }, { "target": "Metadata registry registration model (registration authority, submitter, steward, registration status categories)", "relation": "ALIGN", "purpose": "Align local registration state names, entry criteria and progression authority to registry practice where the adopting Dimension operates a metadata registry; registry-wide administration remains there.", "required": false, "source_refs": [ "SRC-026" ] }, { "target": "Data quality measurement model (quality dimensions, categories, metrics and measurements)", "relation": "ALIGN", "purpose": "Express editorial quality as dimension-scoped measurements against named metrics. Metric definitions, computation and any certification remain in the quality model.", "required": false, "source_refs": [ "SRC-023" ] }, { "target": "Persistent identifier and namespace registry model (minting, reservation, resolution and exclusion)", "relation": "REFERENCE", "purpose": "Carry the namespace, identifier scheme, persistence commitment and reuse-exclusion entries for this concept. Minting service operation and resolver infrastructure are owned there.", "required": true, "source_refs": [ "SRC-021", "SRC-027" ] }, { "target": "WM-KNW-006 lexical designation structures (designations, language-tagged labels, definitions and ct-core-usage-attestation)", "relation": "COMPOSE", "purpose": "Governance states, decisions and change records attach to the stable concept while designation-level content and retained usage attestations remain in the lexical structures. This pass carries designation references, disclosure state and the publication access exception only.", "required": true, "source_refs": [ "SRC-001", "SRC-018" ] }, { "target": "WM-KNW-006 semantic relation and mapping structures (ct-rel-art-mapping-set, ct-rel-art-crosswalk-specification, ct-rel-art-interchange-package)", "relation": "COMPOSE", "purpose": "Mapping and relation assertions are defined and composed there; this pass supplies only the change classification, decision, validation and release-binding gates that a mapping change must pass through.", "required": true, "source_refs": [ "SRC-001", "SRC-019" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting package MUST declare itself owner of vr.wm-knw-006 and name a registration authority, at least one concept steward, a namespace controller and a rights-and-privacy reviewer before any concept record may progress beyond the recorded state.", "The package MUST publish the governed code systems it uses for registration status, change class, obsolescence reason, warrant type, maturity, retention class and disposition, each with a version identifier, because this model fixes the slots but not the local value sets.", "The package MUST declare its canonical-form version tag, digest algorithm and mode set, and its release cadence, and MUST commit to keeping published releases immutable and resolvable.", "The package MUST state, per jurisdiction it operates in, which privacy and rights regime governs publication of usage attestations and other evidence; this model records the flag and the review, not the legal determination.", "The package MUST bind the three local-ID zones to concrete storage or interface namespaces without renaming them, and MUST reject any record whose local ID falls outside the declared zones." ], "namespace_guidance": "WM-KNW-006 uses exactly three stable local-ID zones, all lower-kebab-case, all stable across storage and interface projections: ct-core- for the lexical and designation surface (concepts, designations, language-tagged labels, definitions and the ct-core-usage-attestation artifact); ct-rel- for semantic relations, scheme mappings and interchange (including ct-rel-art-mapping-set, ct-rel-art-crosswalk-specification and ct-rel-art-interchange-package); and ct-gov- for lifecycle, decision, provenance, evidence, validation, quality, stewardship, rights and retention structures (including ct-gov-artifact-decision-record, ct-gov-artifact-change-record, ct-gov-artifact-deprecation-notice and ct-gov-artifact-validation-report). Every bundle, layer, finding, question, data element, artifact and function ID MUST begin with its zone prefix, and a node MUST NOT be moved between zones without a deprecation of the old ID and a new ID in the target zone; IDs are never reused across zones. Zone prefixes are semantic addresses, not folder names: a Markdown tree, a Git path, a MongoDB collection, an MCP resource URI and a JSON pointer are all equally valid projections provided the zone prefix survives intact. Local IDs MUST NOT contain a date, timestamp, release label or sequence position. Externally facing IRIs are minted in the package's own namespace and MUST NOT reuse a standards-body namespace.", "registry_links": [ "The Vercy registry record vr.wm-knw-006 with model_id WM-KNW-006, nav path NAV.INF.KNW.CON and domain tag INF.KNW.CON is the authoritative registration entry; the adopting package manifest MUST match it exactly.", "Parent registry link: parent_ids WM-KNW-002, which owns concept scheme identity and release publication; a concept record MUST resolve its scheme reference against that entry.", "Where the adopting Dimension operates an external metadata registry or vocabulary registry, the package MUST record the external register identifier alongside the Vercy registry_id and state which one is the master system for identity." ] }, "canon_and_patch": { "canonicalization_rules": [ "Canonical form is the versioned canonical semantic form of the record, never a stored file or a pretty-printed serialisation. Serialise the record's semantic content as UTF-8 JSON and apply RFC 8785 (lexicographic UTF-16 code-unit key ordering, ECMAScript number serialisation, defined string escaping), then record the canonical-form version tag, for example ct-canon/1.", "Lexical and designation content: designation and label strings are normalised to Unicode NFC and trimmed only of leading and trailing whitespace. No case folding, diacritic stripping, transliteration or punctuation rewriting is applied, because those operations change the designation itself rather than its encoding.", "Language-tagged values: each value canonicalises as the pair (BCP 47 language tag in canonical case, NFC string). A value carrying no language tag is a distinct value from the same string carrying one and MUST NOT be merged with it. Collections of language-tagged values sort by language tag, then by string.", "Scheme relations and mappings: each assertion canonicalises as the tuple (source concept identifier, source scheme release, predicate, target concept identifier, target scheme release). Sets sort by source identifier, then predicate, then target identifier, then target release. Inverse and inferred assertions are never materialised into the canonical form; only asserted direction and asserted closure are canonical.", "Governance content: all timestamps normalise to RFC 3339 with seconds and an explicit offset or Z; code values canonicalise as (code system identifier, code version, code) triples; free-text rationale is NFC. Governance event collections sort by event time, then by record identifier, so equal event times never produce a non-deterministic order.", "Absence and explicit null are distinct: omit a property that was never asserted, and assert null only where the model defines an asserted-unknown. Canonicalisation never fills defaults, never drops empty collections that were explicitly asserted, and never reorders array-typed content whose order is semantic.", "Derived, cached and projection-only content is excluded from the canonical form and therefore from every digest: rendered display labels, inferred broader or narrower closures, sort keys, pagination metadata and storage-engine fields." ], "patch_rules": [ "A patch targets exactly one governed record at one named canonical-form version and carries the pre-image digest. Apply only if the pre-image digest matches the current canonical form; otherwise reject as a conflict and require re-derivation.", "Patches are ordered, typed operations over semantic paths (add, replace, remove, move) and MUST be reversible: every accepted patch stores its inverse operation set so any superseded state can be reconstructed exactly.", "Lexical and designation content: a published designation is never rewritten in place. Changing the string retires the existing designation and adds a new one, because usage attestations and mapping assertions bind to the designation, not to the concept alone.", "Language-tagged values: retagging is a distinct operation from restringing. A patch MUST NOT change a language tag and a string in a single operation, and MUST NOT silently attach a tag to a previously untagged value.", "Scheme relations and mappings: changing a match predicate, changing a mapping's bound target release, or removing a published mapping is a semantic change requiring a decision record. It is never applied as a patch-level correction, and a patch that touches a mapping without a referenced decision is rejected.", "Governance content is append-only. A patch may add a correcting record or set a supersession pointer, but MUST NOT mutate or delete an emitted decision, change, validation or deprecation record, nor alter a recorded event, effective or ingestion time.", "Every accepted patch emits exactly one ct-gov-artifact-change-record; where the patch resolved a governed choice, that change record MUST reference the ct-gov-artifact-decision-record that authorised it." ], "compatibility_rules": [ "Change classes are EDITORIAL (no change to canonical semantics: typography, non-normative notes, examples), ADDITIVE (new designations, new non-conflicting mappings, new governance metadata, new evidence) and BREAKING (definition scope change, merge, split, deprecation, retirement, or removal or narrowing of a published designation or mapping).", "A BREAKING change MUST increment the major component of the release designation and MUST NOT reuse any released version designation. Released content is immutable: defects are corrected in a new release, never by editing a published one.", "A concept identifier is never reused, never repointed to a different meaning and never deleted. Meaning change is modelled as deprecation plus successor, so downstream consumers can detect it rather than silently inherit it.", "Lexical compatibility: adding a language-tagged value is ADDITIVE; removing the last value for a language is BREAKING for consumers of that language and MUST be declared per language in the release notes. Changing the preferred designation within a language is BREAKING for label-keyed consumers.", "Mapping compatibility: tightening or loosening a match predicate is BREAKING for downstream inference. Rebinding an existing mapping to a newer target-scheme release is ADDITIVE only when a conformance check shows the target concept is unchanged in that release; otherwise it is BREAKING.", "Governance compatibility: steward change, added evidence and status progression that does not withdraw the concept are ADDITIVE. Retirement, withdrawal, licence narrowing and retention shortening are BREAKING and require prior notice under the published resolution guarantee.", "A version designation may use a date form as a human-facing release label, but a date is never identity; identity is the release identifier and the concept identifier. Consumers MUST resolve on identifiers, not on labels." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier: the identifier assigned by the system of record that owns the artifact — the registration authority's case or decision key, the evaluation engine's report run key, the holding institution's accession or specimen number. Record it verbatim together with the identifier of the issuing system, and prefer it over every locally minted alternative.", "Immutable digital-artifact content address, using a named digest algorithm together with the applicable canonical-form or exact-byte-stream mode and its version, when the artifact's own declared identity strategy selects content identity and no authoritative master-system identifier exists. This second tier identifies only that immutable artifact or rendition, never the concept, designation or referent; any canonical-content or retained-byte change creates a new artifact identity and a derivation link. Governed external identifiers and local UUID/ULID remain the following fallback tiers for artifacts whose declared strategy is not content-addressed.", "Governed global identifier or IRI: a persistent, resolvable identifier from a governed scheme, such as a concept scheme PURL or IRI, DOI, Handle, ARK, ISSN or ISBN for a cited publication. Record the scheme and the resolution service alongside the value.", "UUID (RFC 4122) or ULID minted by the adopting Dimension, used only where neither of the above exists. The minting event, minting authority and mint time are recorded so the identifier's origin remains auditable.", "Never identity: a date, timestamp, release label or version designation, a file name or path, a display label or title, a digest prefix, a row number or a position in a sequence. Any of these may appear as descriptive metadata but MUST NOT be used to identify an artifact." ], "timestamp_rule": "Every time value in WM-KNW-006 is an RFC 3339 date-time that includes seconds and an explicit numeric offset or the Z designator; fractional seconds are optional but preserved verbatim in the canonical form when present. The RFC 3339 unknown-local-offset form -00:00 MUST NOT be used in governed records: use Z where the value is genuinely UTC and a known numeric offset otherwise. Event time (when the governed act actually occurred: a decision taken, a deprecation effective, an attestation captured), effective time (when the change takes force for consumers, which may be prospective or retrospective) and observation or ingestion time (when this register captured, received or indexed the record) are stored as separate fields and MUST NOT be collapsed into one value; when they coincide, all three are still written. Intervals and durations are expressed with RFC 3339 date-times at both ends rather than open-ended text, and any ordering of governance events is by event time with the record identifier as deterministic tie-break.", "serial_naming_rule": "Serial artifacts are named artifact-kind / scope-discriminator / sequence, where the sequence is a monotonically increasing integer that is never reused, never renumbered and never gap-filled within its scope, and where the scope discriminator is the artifact kind's declared scope rather than a convenience. Sequences are held per (artifact kind, scope) pair; two kinds never share a counter. The complete serial inventory for WM-KNW-006 is: (a) ct-core-usage-attestation — designation-scoped, so the discriminator is the designation identifier, which already carries its concept and language tag; (b) ct-rel-art-mapping-set — scoped jointly to an ordered scheme pair and the bound release of both schemes, so the discriminator is the tuple (source scheme identifier, source scheme release, target scheme identifier, target scheme release), and a mapping set is never scoped by a single concept; (c) ct-rel-art-interchange-package — export-closure-scoped, so the discriminator is the export closure identifier, meaning the resolved set of schemes, releases, languages and filters that defined the export, and never a concept; (d) ct-gov-artifact-deprecation-notice, ct-gov-artifact-change-record, ct-gov-artifact-decision-record and ct-gov-artifact-validation-report — each concept-scoped, so the discriminator is the concept identifier and each of the four kinds keeps its own independent sequence. A date, timestamp, release label, ISO week or any other temporal token MUST NOT be used as the sequence or as any part of artifact identity, although a date may appear in a human-readable title. Non-serial artifacts are never numbered and MUST NOT be retro-fitted with a sequence: ct-rel-art-crosswalk-specification is bridge-model-scoped and retains its declared external identity — the crosswalk specification's own governed identifier or DOI — falling back to content identity where no external identifier exists; every other non-serial artifact likewise retains the identity strategy declared on it.", "integrity_rule": "Every artifact carries a digest that a holder of the payload can re-derive, recorded together with the named digest algorithm (for example SHA-256), the canonicalisation or byte-stream mode, and the version of that mode; a digest lacking any of these three is not an integrity claim and MUST be treated as unverifiable. (1) Structured artifacts — decision records, change records, deprecation notices, validation reports, mapping sets, crosswalk specifications and interchange manifests — are hashed over the versioned canonical semantic form defined in the canonicalisation rules, never over a stored file, and record mode canonical-semantic together with the canonical-form version tag. (2) Digital renditions — digital audio, raster image, vector image, video and screenshot — are hashed over the exact retained byte stream, recorded with the declared IANA media type and the byte length in octets; the retained byte stream, not a re-render or a re-export, is the hashed object. Any transcoding, re-encoding, resizing, cropping, redaction or format migration produces a new rendition with its own digest, media type and byte length plus a derivation link to its source rendition, and never updates the digest of the original. (3) A physical specimen or object is never hashed directly: hash the holding system's catalogue record as a structured artifact and each retained digital rendition of the specimen as a byte stream, and link both to the specimen's holding-system identifier, so the integrity claim is about the records and renditions rather than about the object. (4) Where a payload is restricted, embargoed or contains personal data, the algorithm, mode, mode version and digest are disclosed only to authorised parties; the model MUST NOT represent that an unauthorised third party can independently recompute a restricted digest, because recomputation requires authorised access to the canonical payload. A restricted artifact may expose a reference and a statement that a digest exists without exposing the value." }, "policies": [ "Concept identity is stable and label-independent: designations, definitions and mappings may change under governance, but the concept identifier never changes meaning, is never reused and is never deleted.", "Governance records are append-only and immutable once emitted. Corrections are made by adding a superseding record with a pointer to the original, which remains readable for audit.", "No progression without authority: a state transition beyond the recorded state requires steward sponsorship and registration-authority approval, recorded as a statement of authorisation and a decision record.", "Published releases are immutable and resolvable. A defect in a published release is fixed in a new release, and version designations are never reused.", "No conformance claim without evidence: an alignment to an external standard is recorded as an alignment with its clause and version. Conformance is asserted only where a retained validation report or equivalent evidence supports it, and conflicts are recorded rather than reconciled silently.", "Evidence that may identify a living person or carry third-party rights is not published without a completed privacy and rights review; where the evidence cannot be disclosed, a restricted reference is published in its place.", "This model owns declaration and record-keeping, not execution: constraint evaluation, policy enforcement, audit-log storage and disposition execution are performed by the referenced models and the adopting Dimension, and referencing them confers no ownership of their semantics." ], "crud": { "read": [ "Published concept records, their registration status, version chain, deprecation notices and successor pointers are readable by any consumer of the scheme release, subject to the licence recorded on each record part.", "A read MUST return the canonical-form version tag and the record state digest alongside the content so a consumer can verify what it received.", "Point-in-time reads are supported by reconstruction from change records and MUST state the time basis used (event, effective or ingestion time); a reconstruction with a gap or digest mismatch is reported as an integrity finding, never silently interpolated.", "Restricted or embargoed parts are omitted from a read for unauthorised callers and replaced by a restricted-reference stub that discloses the existence, the holding system and the access route, but no restricted content.", "Reading a retired identifier MUST resolve to its tombstone with the deprecation status and successor pointer for as long as the published resolution guarantee runs." ], "create": [ "A concept record is created only through a submitted proposal that carries a submitting agent, a warrant type and a duplicate-candidacy screening result; creation places the record in the initial pre-recorded state and asserts no published meaning.", "Identity is assigned by the priority order in artifact_rules.identity_priority: an authoritative master-system identifier where one exists, otherwise a governed IRI, otherwise a locally minted UUID or ULID with its mint event recorded.", "Creation MUST record event, effective and ingestion times separately and MUST allocate zone-correct local IDs; a record whose ID falls outside ct-core-, ct-rel- or ct-gov- is rejected.", "Creating a serial artifact allocates the next never-reused integer in its declared scope; allocation is durable, so an abandoned draft consumes its number permanently rather than releasing it for reuse." ], "update": [ "Updates are applied as reversible patches against a matching pre-image digest at a named canonical-form version; a mismatch is a conflict and MUST be re-derived rather than force-applied.", "Any update classified as BREAKING requires a decision record in force before it is applied and forces a major increment on the next release binding.", "A published designation, mapping or governance record is never updated in place: designations are retired and re-added, mappings are re-asserted under a decision, and governance records are superseded by later records.", "Every accepted update emits exactly one change record with its inverse operation set, causing activity, agent attribution and the three timestamps.", "Updates to a record under a legal hold are permitted for governance metadata but MUST NOT remove or alter content within the hold's scope." ], "delete": [ "Hard deletion of a concept record is prohibited. Withdrawal from active use is modelled as deprecation or retirement with an obsolescence reason and, where one exists, an authoritative successor; the identifier is entered in the reuse-exclusion register and is never minted again.", "Each record part carries a retention class reference, a retention period start event and a disposition instruction (retain permanently, review, restrict or dispose of payload). This model declares the instruction; it does not execute it.", "Execution of disposition — scheduling, approval, hold release and destruction — is owned by the adopting Dimension's records retention and disposition authority referenced in the composition ledger. This model issues a disposition request and records the returned execution confirmation; it asserts no destruction of its own.", "Where evidence payloads must be removed for privacy or rights reasons, minimisation and redaction produce a new rendition with its own digest and the prior rendition is disposed of by that authority; the change record documents the removal without reproducing the removed content.", "A tombstone MUST survive every disposition: the identifier, final registration status, deprecation status, successor pointer, disposition event time and the executing authority reference are retained so inbound references degrade to a documented dead end rather than an unexplained absence.", "Governance records themselves are retained at least as long as the concept record they explain, unless a superior retention or legal obligation identified by the adopting Dimension requires otherwise; that determination is the Dimension's, not this model's." ] }, "roles": [ { "name": "Registration authority", "responsibilities": [ "Approve progression of a concept record beyond the recorded state and confer registration status", "Issue statements of authorisation and hold the mandate recorded on decision records", "Approve retirement, merge, split and redirect, and maintain the reuse-exclusion register" ] }, { "name": "Concept steward", "responsibilities": [ "Sponsor a concept record for progression and maintain its editorial content and evidence references", "Classify proposed changes as editorial, additive or breaking and refer breaking changes for decision", "Respond to duplicate candidacy referrals and keep successor pointers accurate" ] }, { "name": "Submitter / proposer", "responsibilities": [ "Open a governance case with a proposed concept or change, its warrant type and evidence references", "Attach the duplicate-candidacy screening result before submission", "Respond to reviewer findings without editing published record states directly" ] }, { "name": "Editorial reviewer", "responsibilities": [ "Assess editorial completeness, definition maturity and quality measurements against the governed scales", "Record findings, dissent and rejected alternative scopings for the decision record", "Set and monitor the next-review-due instant" ] }, { "name": "Validation operator", "responsibilities": [ "Declare which constraint-set versions apply and submit record states for external evaluation", "Retain the returned validation report and link it to the exact validated state digest", "Report blocking failures and record any accepted waiver with its authorising decision" ] }, { "name": "Rights and privacy reviewer", "responsibilities": [ "Review evidence flagged as identifying a living person or carrying third-party rights before publication", "Direct minimisation or redaction and approve the restricted-reference stub where disclosure is refused", "Record the licence, access rights and embargo terms applied to each record part" ] }, { "name": "Namespace controller", "responsibilities": [ "Mint, reserve and exclude identifiers in the model's namespace and prevent collision or reuse", "Maintain the persistence and resolution commitment and publish its end conditions", "Execute namespace succession if the namespace is transferred, forked or discontinued" ] }, { "name": "Auditor", "responsibilities": [ "Reconstruct concept record states at a stated instant and verify digests, algorithms and mode versions", "Test that governance records are append-only and that timestamps distinguish event, effective and ingestion time", "Report integrity findings such as change-record gaps, digest mismatches or reused sequences" ] } ], "access": { "default_rule": "Published concept records, their registration status, version chain, change history, deprecation notices and successor pointers are readable by default under the licence recorded on each record part, because identifier resolution and change transparency are what a consumer depends on. Everything that is not published — draft proposals, unapproved decisions, restricted evidence, embargoed content and personal data — is closed by default and is exposed only as a restricted-reference stub. Write access is closed by default and granted per role and per record part.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "ct-core-usage-attestation: screenshots, corpus excerpts and appellations may identify a living person or contain third-party or otherwise private material. Publication therefore requires a completed privacy and rights review, minimisation or redaction where applicable, and a restricted reference in place of the underlying evidence when it cannot be disclosed. The review outcome, the reviewing role and the basis are recorded; the model records the flag and the review, it does not make a universal legal determination, and the applicable regime is jurisdiction-specific and declared by the adopting package.", "Embargoed record parts: content under embargo is withheld until the recorded embargo end instant or releasing event, with a stub disclosing existence and access route. If the releasing event never occurs, the fallback state recorded on the part governs, and silence is never treated as release.", "ct-gov-artifact-validation-report: a report may quote failing content, including restricted designations or attestation excerpts. Reports are readable to stewards, validation operators and auditors by default; external publication requires the same privacy and rights review as the underlying evidence.", "ct-gov-artifact-decision-record: recorded dissent and minority positions identify individuals. The outcome and rationale are published with the concept; participant-level dissent is disclosed to the registration authority, the steward and auditors, and more widely only where the deciding body's published rules require it.", "Definitions adopted verbatim from a commercially licensed source: the local record may be restricted to licensees even where the surrounding governance metadata is open, and the licence reference must be exposed even when the definition text is not.", "Records under a legal hold: read access may be widened to the holding authority and narrowed for others; the hold flag, imposing authority and release condition are visible even when the held content is not.", "Person-naming designation: an appellation, proper name or other designation that identifies or can single out a living person is not automatically open merely because its concept record is published. Before disclosure, the adopting package records the applicable jurisdiction, privacy and rights review, stated basis, necessity and minimisation decision; it redacts or restricts the designation when required while preserving a non-identifying concept reference where lawful. This is an access exception and recorded local determination, not a universal claim that every proper name is personal data." ], "audit_requirements": [ "Every state transition, decision, patch, validation run, deprecation and disposition request emits an append-only governance record carrying the acting agent, the role, and separate event, effective and ingestion timestamps in RFC 3339 with seconds and an explicit offset or Z.", "Every access to a restricted, embargoed or personal-data-flagged record part is logged with the requesting party, the authorisation basis and the scope returned; the log is held by the adopting Dimension's audit facility, whose storage and integrity semantics this model does not own.", "Serial allocation is auditable: an auditor must be able to show that no sequence within an (artifact kind, scope) pair has been reused, renumbered or gap-filled, and that no date has been used as identity.", "An auditor must be able to reconstruct any concept record at a stated instant and verify the reconstruction against a retained digest with its algorithm, mode and mode version; unverifiable digests are reported as findings.", "Waivers of blocking validation failures, overrides of the duplicate-review step and any disclosure of restricted evidence must each carry an authorising decision record reference; an unreferenced override is an audit finding." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Registry ID (vr.wm-knw-006) and Model ID (WM-KNW-006)", "Canonical-form version tag, digest algorithm and mode set", "Local-ID zones in use (ct-core-, ct-rel-, ct-gov-) and their projection bindings", "Registration authority, steward and rights-and-privacy reviewer contacts" ], "read_order": [ "AGENTS.md first: identify Name, Type and the four URLs before touching any record; an agent that cannot resolve all four MUST stop and report rather than guess a projection.", "Specification URL next: read the model scope, boundaries, out-of-scope list and the composition ledger so target-owned concepts are not re-implemented locally.", "Storage type URL: learn the concrete projection (for example Git tree, MongoDB collections, Markdown files or an MCP resource space) and confirm the three local-ID zones survive that projection intact.", "Interface URL: learn the read, create, update and delete operations actually exposed, and which are unavailable in this deployment.", "Processes URL last: read the governance workflow, required roles and approval gates before submitting a proposal or attempting a state transition.", "This order holds for every storage type, including MongoDB and MCP deployments where AGENTS.md is served as a resource rather than stored as a file." ] } }, "coverage": { "claim": "Single-provider (Claude) coverage of WM-KNW-006 spanning 9 bundles, 19 layers, 40 findings, 173 questions, 11 artifacts and 24 functions over 31 cited sources (30 primary, 22 at authority tier 1-2). Coverage is explicitly bounded and is not a completeness claim: no ISO clause text was read (1087:2019, 25964-1/-2, 30042:2019, 24613, ANSI/NISO Z39.19 are paywalled and are surrogated through the OMG MVF RDF rendering, NISO and DCMI descriptions and the iso-thes namespace); DatCatInfo was unreachable so no data-category persistent identifiers are pinned; the privacy status of person-naming designations and the structure for pre-coordinated compound concepts remain declared gaps; and SSSOM alignment, probabilistic mapping confidence, faceted citation order, non-written designation modalities and multilingual governance partition are unmodelled. Twenty standards-level tensions are recorded rather than resolved. No clause-level conformance to any external standard is asserted, and 21 of 24 checklist dimensions marked \"covered\" include at least one (lifecycle) whose support this audit downgrades.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Identifier priority ordered from authoritative master system through governed IRI to locally minted UUID or ULID; notation and preferred label explicitly excluded as identifiers; designation-level identity handled separately (SRC-001, SRC-002, SRC-008)." }, { "dimension": "language and script", "status": "covered", "notes": "BCP 47 subtag order, IANA registry validation including Suppress-Script, ISO 15924 script codes, transliteration provenance and a declared language fallback contract (SRC-009, SRC-010)." }, { "dimension": "classification", "status": "covered", "notes": "Concept kind (general versus individual), designation type, definition type, note type, audience and register, and referenced subject-field values (SRC-005, SRC-006)." }, { "dimension": "privacy", "status": "gap", "notes": "Appellations and proper names may identify living persons, and attestation artifacts may capture personal data. The model flags the sensitivity and defers handling, but no primary source consulted here settles whether a designation record constitutes personal data in a given jurisdiction." }, { "dimension": "spatial", "status": "covered", "notes": "Territory of currency for a designation via region subtags and named usage communities; no geometry or coordinate modelling is in scope (SRC-009)." }, { "dimension": "relationships", "status": "covered", "notes": "Direct hierarchical assertion versus derived closure, refined generic/partitive/instantial kinds, associative relations with symmetry and disjointness, grouping constructs, compound composition and cross-scheme mappings are each modelled separately with their governing source and formal properties cited." }, { "dimension": "interoperability", "status": "covered", "notes": "Cross-scheme mapping types with their formal properties, mapping sets with cardinality and release binding, conservative chain composition, alignment to ontology terms with declared entailment scope, crosswalk specifications, closure rules, out-of-closure reference handling and lossy-construct declarations are all modelled, with format neutrality grounded in the RDF abstract syntax." }, { "dimension": "scheme membership", "status": "covered", "notes": "The zero-scheme, single-scheme and multi-scheme cases are all modelled, membership is required to be asserted rather than derived from relations, and top concepts are treated as declared entry points rather than derived roots." }, { "dimension": "mapping semantics", "status": "covered", "notes": "Transitivity, symmetry and disjointness are taken directly from the SKOS Reference, including the awkward consequence that broad and narrow matches are simultaneously hierarchical properties and the fact that same-scheme mapping is not formally inconsistent." }, { "dimension": "multilingual", "status": "covered", "notes": "Language independence of the concept node, graded cross-lingual equivalence, BCP 47 subtag scoping with canonicalisation, and the explicit rule that matching language tags are not evidence of semantic equivalence." }, { "dimension": "compound concepts", "status": "gap", "notes": "Modelled from ISO 25964-2 compound equivalence, the iso-thes CompoundEquivalence and SplitNonPreferredTerm constructs and the OntoLex decomp module, but the SKOS Primer states that established patterns for pre-coordination have not emerged in the SKOS community. There is therefore no standard-native construct, and the local structure is marked provisional rather than canonical." }, { "dimension": "formal alignment", "status": "covered", "notes": "Alignment target kind, predicate and declared entailment scope are modelled from OWL 2 and OntoLex, with the reasoning environment referenced rather than owned." }, { "dimension": "lifecycle", "status": "covered", "notes": "Proposal, review, approval, publication, deprecation, retirement and succession are modelled as states with entry criteria, permitted transitions and required authority, aligned to registration-status categories and status vocabularies." }, { "dimension": "temporal", "status": "covered", "notes": "Event, effective and observation or ingestion times are separate mandatory fields in RFC 3339 with seconds and explicit offset or Z; -00:00 is prohibited locally; point-in-time reconstruction states its time basis." }, { "dimension": "provenance", "status": "covered", "notes": "Authoritative source with version, derivation mode, role-qualified attribution, delegation and custody-change statements, plus causing activity and decision references on every change record." }, { "dimension": "ownership", "status": "covered", "notes": "Owning organisation, named steward with effective period, delegated versus reserved actions, escalation on steward lapse, and ownership transfer without identifier discontinuity. Party identity itself is referenced, not reproduced." }, { "dimension": "validation", "status": "covered", "notes": "Constraint-set version declaration, conformance flag, per-result severity, blocking versus advisory thresholds and waivers with authorising decisions. Evaluation and engine semantics stay with the referenced constraint model." }, { "dimension": "access", "status": "covered", "notes": "Default open for published records under recorded licence, closed for drafts and restricted content, with four access scopes and six exceptions including the mandated ct-core-usage-attestation privacy and rights exception." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Hard deletion prohibited; deprecation plus successor, retention class reference, disposition instruction, legal hold and a mandatory surviving tombstone. Execution is explicitly assigned to the adopting Dimension's records authority, not to this model." }, { "dimension": "authority and decision", "status": "covered", "notes": "Decision body mandate, workflow steps with required roles, options considered, dissent, appeal and non-destructive supersession are all modelled as first-class governance content." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Warrant typing, evidence references with disclosure state, counter-evidence, editorial completeness criteria, maturity code, dimension-scoped quality measurements and review cycle." }, { "dimension": "duplication, merge and split", "status": "covered", "notes": "Signal-based candidacy with thresholds and mandatory human confirmation, survivorship rule, redirect entries, split scopes and coded obsolescence reasons for merged and split terms." }, { "dimension": "namespace stewardship", "status": "covered", "notes": "Namespace controller, identifier scheme, persistence and resolution commitment, minting and reservation procedure, and succession if the namespace is transferred, forked or discontinued." }, { "dimension": "security", "status": "not-applicable", "notes": "Authentication, authorisation enforcement, transport security and tamper-evident logging belong to the adopting Dimension's platform and to the referenced audit facility. This model specifies what must be logged and restricted, not how it is enforced." } ], "known_omissions": [ "Clause text of ISO 1087:2019, ISO 704, ISO 12620-1:2022, ISO 30042:2019 and ISO 24613 (LMF) is paywalled and was not read. ISO 1087 notions are grounded through the publicly retrievable OMG rendering (SRC-005) and no ISO clause is quoted.", "The DatCatInfo data category repository was unreachable during research (connection refused), so no data-category persistent identifiers for part of speech, term type or administrative status are cited; grammatical category values are declared as registry-referenced without naming specific identifiers.", "Sign-language designations, tactile designations and other non-written, non-audio modalities are only partially covered by the designation type and symbol artifact; no primary source consulted specifies their representation.", "No treatment of derived representations such as embeddings, ranked synonym expansion or automatically induced senses.", "The clause-level normative text of ISO 25964-1 and ISO 25964-2 and of ANSI/NISO Z39.19 was not read; those standards are behind paywalls or downloads that could not be retrieved, so their content is taken from the standards bodies' own published descriptions and from the iso-thes RDF expression. Specific clause numbers are deliberately not cited.", "The ISO 1087:2019 catalogue page blocks automated retrieval, so no ISO 1087 clause text was read; it corroborates the generic/partitive distinction only, and no structural node rests on it alone.", "SSSOM (Simple Standard for Sharing Ontological Mappings) and comparable mapping-exchange formats used in life sciences were not researched, so the mapping-set artifact is not aligned to them; adopters in those domains should treat that as an open alignment.", "Confidence, similarity scoring and probabilistic mapping justification are not modelled; only a free-text strength basis is carried, which is weaker than what several mapping-exchange formats support.", "Faceted classification and citation-order rules beyond node labels and facet indicators are not modelled.", "The ISO 25964 XML exchange schema is referenced only through the crosswalk finding; its element-level structure was not enumerated.", "No treatment of concept collections as query-time facets, or of collection-driven display ordering beyond the ordered member position.", "Local value sets for registration status, change class, obsolescence reason, warrant type, maturity, retention class and disposition are specified as required governed code systems but not enumerated, because their canonical names differ per registration authority.", "Signature and non-repudiation mechanics beyond digest recording, and any key management, are omitted; they belong to the platform.", "Multilingual governance divergence — where different language communities steward the same concept under different authorities — is not modelled and would need a dedicated stewardship-partition structure.", "Machine-actionable expression of the workflow itself, as opposed to the records it emits, is left to the Processes URL referenced from AGENTS.md." ], "conflicts": [ "SKOS condition S14 permits at most one skos:prefLabel per language tag, while terminology practice grounded in ISO 1087 and TBX allows several admitted terms and, in some termbases, more than one term rated preferred per language for different registers. A profile decision is required and is recorded rather than resolved.", "Plain SKOS labels and reified designations (SKOS-XL, iso-thes preferred and non-preferred term classes, TBX term sections) are not interchangeable: projecting a reified designation to a plain literal silently drops rating history, source and grammatical data, which is why a loss report is mandatory.", "OntoLex defines LexicalConcept as a subclass of skos:Concept, which invites treating a lexicalised concept as a terminological concept; ISO 1087 keeps concept and designation strictly apart. The model records the assertion level of any equivalence claim to keep the two apart.", "The SKOS Primer states that OWL DL users cannot treat SKOS concepts as classes, yet many domain vocabularies do exactly that through punning. Any ontology projection must declare the OWL flavour assumed, and conformance claims that do not are rejected.", "BCP 47 Suppress-Script guidance conflicts with the common practice of always emitting a script subtag; tags carrying a suppressed script do not match consumer expectations and are treated as a validation finding, not silently normalised.", "The iso-thes namespace documentation lists custom term, concept and note attributes as unmodelled, so extension attributes carried in ISO 25964 XML have no agreed RDF form; such attributes are reported as loss rather than mapped by guesswork.", "SKOS declares broadMatch and narrowMatch as sub-properties of both skos:broader/skos:narrower and skos:mappingRelation, so a cross-scheme mapping also enters the within-scheme transitive hierarchical closure. This cuts against the clean separation of semantic and mapping relations that the SKOS Primer presents, and the model records the leak explicitly rather than resolving it.", "The SKOS Reference states that restricting mapping properties to different schemes is a convention and supplies no integrity condition against same-scheme mapping, while common practice and the Primer treat cross-scheme use as the rule. The model records the convention and permits the local rule to be stricter.", "SKOS defines no integrity condition preventing a declared top concept from also asserting a broader concept in the same scheme, whereas thesaurus practice generally treats top terms as roots. The model treats top concepts as declared entry points and flags the coexistence rather than rejecting it.", "ISO 25964 supports compound equivalence and split non-preferred terms, and XKOS supports reified many-to-many associations; SKOS has no native construct for either, so consumers reading plain SKOS lose the structure silently unless the loss is declared.", "XKOS and iso-thes both refine broader, but with different property sets (specializes/isPartOf versus broaderGeneric/broaderPartitive/broaderInstantial); a scheme using one is not automatically interpretable by a consumer expecting the other, and neither maps cleanly onto ISO 1087 terminology-science relation typing.", "OntoLex-Lemon is a Community Group Report and explicitly not a W3C Standard, so its constructs carry lower normative weight than SKOS or OWL 2 even though they are the best available model for the lexical bridge and for decomposition.", "SKOS defines skos:Concept and documentation properties including historyNote and changeNote but supplies no status, deprecation or versioning vocabulary at all. Status and version machinery therefore comes from ADMS, DCAT and registration standards, and no SKOS conformance is claimed for it.", "ADMS, the source of adms:status, prev/next/last and versionNotes, is a W3C Working Group Note that was retired in August 2023 and is now maintained by SEMIC. Alignment targets a moving reference and must be re-verified per release.", "OBO Foundry Principle 4 prefers date-based version identifiers of the form YYYY-MM-DD, while Vercy prohibits a date as an identifier. Resolved locally by permitting a date-formed version designation as a human-facing release label while identity remains the release identifier; this is a local policy decision, not a claim that OBO is wrong.", "Semantic Versioning's MAJOR/MINOR/PATCH semantics are API-oriented and do not map cleanly to vocabulary change: a definition narrowing breaks consumers without changing any structural interface. The local EDITORIAL/ADDITIVE/BREAKING classification is used instead, with SemVer cited only for the increment and immutability discipline.", "RFC 3339 permits -00:00 to signal an unknown local offset. This model prohibits that form in governed records, which is a local restriction of the standard rather than a conformance claim.", "ISO 25964 statuses attach primarily at the term level while ISO/IEC 11179-6 registration statuses attach to an administered item. This model attaches registration status to the stable concept and treats designation-level status as lexical-split content; adopters bridging to a thesaurus management system will need an explicit mapping.", "Three distinct deprecation idioms coexist — owl:deprecated with term-replaced-by in OBO practice, adms:status or dcat:status codes in catalogue practice, and dcterms:isReplacedBy in DCMI. This model records the local flag plus successor pointers and maps outward, rather than adopting one idiom as canonical." ], "regional_assumptions": [ "Language, script and region values assume the IANA Language Subtag Registry and the ISO 15924 registry are available and that the adopting Dimension pins a snapshot version; jurisdictions with national terminology or language authorities may impose a preferred-term authority that overrides scheme defaults.", "Bilingual and multilingual jurisdictions may make a preferred designation in more than one official language mandatory; this model records the requirement as a reference and does not enforce it.", "Data-protection regimes differ on whether appellations and proper names identifying living persons are personal data; treated as an open gap rather than assumed either way.", "Subject-field classifications are frequently national or sectoral; the model references the classification and its version rather than assuming a single global scheme.", "Language identification is assumed to follow BCP 47. Vocabularies that use ISO 639-2/B codes, national locale codes or ad hoc language strings must be canonicalised before comparison, and the canonicalisation rule must be recorded.", "Script and region subtags are assumed to be significant, not decorative: cases such as Simplified versus Traditional Chinese and Latin versus Cyrillic Serbian must not be collapsed when scoping a cross-lingual assertion.", "ISO 25964 practice is strongest in European and library-sector thesauri; XKOS correspondence practice reflects statistical-agency and DDI usage. A deployment outside those sectors may find neither refinement set idiomatic.", "No jurisdiction-specific legal constraint on mapping or on redistribution of third-party vocabularies is assumed beyond the general licence exception in the access rules; adopters must check the licence of every referenced scheme.", "Right-to-left and bidirectional text handling in labels is a lexical-area concern and is not assumed to be solved by the language tag alone.", "Retention periods and disposition obligations derive from the adopting organisation's jurisdiction and sector; no default period is asserted here.", "Third-party rights in corpus excerpts, including copyright, database rights and moral rights, vary by jurisdiction and by the exception relied on, so the quotable extent of an attestation is a local determination.", "Language tags are assumed to follow BCP 47, but which languages a scheme must support, and whether any is legally privileged, is a regional policy of the adopting package.", "The default-open posture for published concept records assumes the adopting package operates a public or shared vocabulary; a closed internal register would invert the default rule without changing the structure." ], "adversarial_checks": [ "Tested whether a preferred label could serve as the identifier; rejected because SKOS permits one preferred label per language tag, labels are language-scoped and mutable, and the same string recurs across schemes and subject fields. The policy layer now forbids resolving or merging on label equality.", "Searched for a counterexample to the concept and designation split: non-linguistic symbols and appellations are designations with no lexical entry, which is why lexical form is attached at the designation boundary rather than at the concept, and why the designation-type code is mandatory.", "Checked whether multilingual equivalence smuggles in cross-scheme mapping ownership; it does not — equivalence here holds between designations of a single concept, and concept-to-concept mapping is excluded in scope and boundary notes.", "Audited every function against the no-enforcement rule: the validation function returns findings and explicitly disclaims remediation, enforcement and audit-record writing, and the resolve function is declared read-only with a no-designation signal instead of a coined fallback.", "Checked whether SKOS forbids a declared top concept from also having a broader concept in the same scheme. It does not - the Reference states there is no such integrity condition - so top concepts are modelled as declared entry points, not as derived roots, and the coexistence is flagged rather than rejected.", "Checked whether skos:broader is transitive before allowing any finding to store ancestor sets. It is not; only skos:broaderTransitive is. Closure is therefore modelled as a derived view that is never written back as an authored assertion.", "Checked whether scheme membership propagates along semantic relations. The SKOS Reference explicitly denies the entailment and gives a counterexample, so membership must be asserted per concept and any derivation is marked as a local rule.", "Checked whether exact-match chains and close-match chains may be composed together. closeMatch is explicitly not transitive, so heterogeneous and non-transitive chain composition is rejected by the chain function rather than merely discouraged.", "Checked whether mapping properties are formally restricted to different concept schemes. They are restricted only by convention, and same-scheme mapping produces no inconsistency, so the model records this as an exception case caused typically by merging sources rather than asserting a prohibition the standard does not make.", "Checked whether the OntoLex decomp module supports a claim that a compound concept is the semantic composition of its parts. It decomposes lexical entries, not concepts, so decomposition basis is recorded as lexical or semantic and a non-inference statement is required.", "Checked whether an alignment to an ontology term may default to owl:sameAs or owl:equivalentClass. OWL 2 gives both strong extensional consequences and distinguishes individual identity from class equivalence, so the alignment predicate and its entailment scope must be declared and the weaker predicate is the default.", "Falsifiability test — is any node unsupported? Every bundle, layer, finding and function cites sources. The weakest support is the registration state model, whose category split relies on a paywalled standard read through catalogue and summary material; that limitation is recorded as a known omission and the confidence is set to medium rather than high, and no clause-level conformance is claimed.", "Counterexample test — does a stable concept identity always survive? It does not in every real vocabulary: concepts are sometimes silently re-scoped in place, and some registries do reuse identifiers. The model treats that as a defect to be detected rather than accommodated, forcing deprecation plus successor, which is a normative local choice and is stated as such.", "Serial-scope test — does the naming rule respect the real scopes? Mapping sets are scoped to a scheme pair plus both bound releases and interchange packages to an export closure, not to a concept; only the four governance artifacts and the usage attestation are concept- or designation-scoped; the crosswalk specification remains non-serial with external or content identity.", "Integrity test — is every digest re-derivable per media form? Structured artifacts hash the versioned canonical semantic form; audio, raster, vector, video and screenshot renditions hash the exact retained byte stream with media type and byte length; transcoding mints a new rendition; physical specimens are never hashed directly, only their holding-system record and retained renditions; and restricted digests carry no promise of third-party recomputation." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "entity", "status": "accepted", "rationale": "Concept / Term is a persistently identified unit of thought carrying its own lifecycle, stewardship, versioning and non-value identity, so 'entity' is the correct subject-model kind; it is not an event, a process, a relationship or a value object, and the model correctly refuses to be a class, a lexical entry, a sense, a referent or a keyword. The registry's entry_kind 'standalone-mm' sits on the record-plane axis, not the subject-model axis, so the two values are not a contradiction and must be published side by side rather than silently reconciled. The strongest counter-argument is that the reified Designation behaves as a second aggregate root: it carries its own identifier, its own retire-and-replace patch rule, designation-to-designation relations, and it is the scope discriminator for the ct-core-usage-attestation serial. That is answered, not dismissed, by the fact that no designation is created, resolved or retained without a governing concept identifier and every designation-level act is published through concept-scoped governance artifacts; the dual-root reading is therefore recorded as a standing reservation for a possible future Designation split rather than actioned now. Acceptance is as a reviewable draft only: registry status is candidate, review_state is boundary-review-required, and the frozen relationship contract is empty, so no contract-backed ownership line exists between this model and parent WM-KNW-002." }, "decisions": [ { "concept": "Aggregate root: Concept as sole root, reified Designation as subordinate", "disposition": "accepted with recorded reservation", "rationale": "The model name 'Concept / Term', designation-level identifiers, designation-to-designation relations, the retire-and-replace patch rule for published designations and the designation-scoped attestation serial all give Designation entity-like behaviour. Accepted as one aggregate because no designation exists or resolves without a concept identifier and all designation-level governance is published through concept-scoped artifacts; the dual-root reading is recorded as a reservation, not resolved." }, { "concept": "Entry kind: research 'entity' versus frozen registry 'standalone-mm'", "disposition": "accepted as non-contradictory, both values published", "rationale": "The registry value classifies the record plane (a standalone meta-model rather than a component), while the research value classifies the subject model. They answer different questions and neither invalidates the other, but publishing only one would misrepresent the record, so the synthesizer must carry both and keep review_state boundary-review-required visible." }, { "concept": "Access scope granularity versus the exceptions it must enforce", "disposition": "rejected as written; amendment required before publication", "rationale": "access.scopes is declared as bundle, layer, finding and artifact, but two mandated exceptions operate below that level: the person-naming designation exception restricts an individual designation, and the commercially licensed definition exception restricts a single definition value while leaving surrounding governance metadata open. Neither is expressible at the declared scopes. A record-part or element scope must be added, or the exceptions must be explicitly delegated to the adopting package with that limitation stated." }, { "concept": "Serial sequence as artifact identity versus the never-identity rule", "disposition": "accepted with mandatory clarifying wording", "rationale": "artifact_rules.identity_priority lists 'a position in a sequence' as never identity, while serial_naming_rule makes an allocated integer part of the identifier for seven serial artifact kinds. The two are reconcilable — a durably allocated, never-reused, never-gap-filled counter within a declared scope is an allocated identifier, not a positional index — but the reconciliation is currently implicit and an auditor reading only the never-identity clause would score the serial scheme as non-conformant. The distinction must be stated in the text, not inferred." }, { "concept": "Three overlapping validation surfaces produced by three merged passes", "disposition": "accepted with required disambiguation", "rationale": "ct-core-fn-validate-core-record checks structural constraints locally, ct-rel-fn-check-relation-integrity checks relation and mapping integrity locally, and ct-gov-function-validate-concept-record submits state to an externally owned evaluation. Only the third produces the retained ct-gov-artifact-validation-report. The draft must state that the first two return transient findings that are non-authoritative for any conformance claim, otherwise three competing validation surfaces exist and the no-conformance-without-evidence policy is unenforceable." }, { "concept": "Mandatory interchange loss report has no declared home", "disposition": "deferred; must be resolved before identifier freeze", "rationale": "The conflicts list makes a loss report mandatory when reified designations are projected to plain literals, ct-core-fn-project-interchange promises an explicit report of what the target cannot carry, and several inline_only_rationale statements justify inlining precisely to support loss reporting. Yet no artifact carries that report in the ct-core zone and ct-rel-art-interchange-package is export-closure-scoped in a different zone. Whether the loss report is a retained governed record or a transient response is unspecified." }, { "concept": "Empty relationship contract against roughly a dozen outbound composition references", "disposition": "deferred pending contract entries", "rationale": "The frozen relationship contract is an empty array and registry contains_ids is empty, yet the service layers repeatedly reference a composition ledger and target-owned models: a party model, a rights policy model and evaluator, a records retention and disposition authority, a constraint evaluation engine, an audit facility, a lexicon, domain entity models, a subject-field classification registry, a data-category registry, a metric catalogue and a namespace resolution service. These are honest boundary declarations, but none is contract-bound, so the composition boundary is asserted rather than agreed." }, { "concept": "Ownership of the topConceptOf / hasTopConcept inverse pair with parent WM-KNW-002", "disposition": "deferred pending a relationship-contract entry", "rationale": "The boundary note assigns membership, top-concept designation and scheme versioning to the scheme, while in_scope claims concept scheme membership and top-concept status and ct-rel-find-top-concept models the declaration on the concept side. SKOS makes the two properties inverses, so this is one fact with two candidate homes and no contract deciding which model is system of record. Left unresolved, adopters will double-master it." }, { "concept": "Coverage checklist marks 'lifecycle' as covered", "disposition": "rejected as written; downgrade to partial", "rationale": "The model's own falsifiability check names the registration state model as its weakest support, resting on a paywalled ISO/IEC 11179-6 read through catalogue and summary material, and its own conflicts list records that the ADMS status vocabulary is a retired W3C Note. A dimension whose primary support the author concedes is the weakest in the model should not carry the same status label as dimensions grounded in fully read W3C Recommendations." }, { "concept": "Intra-zone identifier token inconsistency across the three merged passes", "disposition": "deferred to pre-freeze normalization", "rationale": "The three-zone rule is satisfied, but the passes use different internal tokens: ct-core findings carry no type token at all, ct-rel uses find/art/fn, and ct-gov uses finding/artifact/function. A model whose central discipline is identifier stability should not publish an inconsistent identifier grammar. Normalization is free while status is candidate and costs a deprecation cycle afterwards, so it must happen before the identifiers are frozen." }, { "concept": "MVF 1.1 beta and its RDF rendering used as the ISO 1087 surrogate", "disposition": "accepted conditionally; re-verification and re-pinning required", "rationale": "SRC-005 is an OMG-published RDF file retrieved on a single date and SRC-006 is explicitly a beta specification, yet together they carry the concept/object/designation distinctions that the whole core bundle rests on. The model correctly avoids quoting ISO clause text, but a beta artifact can change without notice, so both must be re-resolved and version-pinned at publication and the surrogate status must remain visible in the draft." }, { "concept": "ADMS as the basis for registration status and version pointers", "disposition": "accepted with per-release re-verification", "rationale": "SRC-029 is a W3C Working Group Note retired in August 2023 and now maintained by SEMIC, so the alignment targets a moving reference. The model already records this in its conflicts list and claims no SKOS conformance for status machinery, which is the right posture; the residual requirement is that the alignment be re-verified on each release rather than treated as settled." }, { "concept": "Compound concept and pre-coordination structure", "disposition": "accepted as provisional, must remain labelled provisional", "rationale": "The SKOS Primer states that established pre-coordination patterns have not emerged, so the local structure is authored rather than sourced. The finding correctly declines to invent an artifact and the checklist marks the dimension a gap; the synthesizer must not let that provisional label be dropped when the draft is rendered for publication." }, { "concept": "Tombstone survival versus erasure of person-naming designations", "disposition": "accepted with a recorded residual risk", "rationale": "Hard deletion is prohibited and a tombstone must survive every disposition. The mandated tombstone content is minimised and excludes designations, and redaction is modelled as a new rendition with the change record documenting removal without reproducing content, which is the right construction. Residual risk remains where a concept's only designation identified a living person and the surviving identifier stays linkable; this is flagged rather than solved." }, { "concept": "Function named 'Execute merge or split' against the declaration-not-execution policy", "disposition": "accepted with a scope-clarifying note", "rationale": "The policy layer states this model owns declaration and record-keeping, not execution, and ct-gov-function-apply-retention-disposition correctly hands off. The merge/split function applies an approved outcome to this model's own records, which is in scope, but the verb collides with the policy wording and invites a reader to assume enforcement capability. A one-line scope clarification removes the ambiguity without changing the function." }, { "concept": "Referent exemplar artifact may hold a locally owned media file", "disposition": "accepted with an added constraint", "rationale": "in_scope holds referents as references to external entity records, but ct-core-referent-exemplar falls back to a content hash of the exemplar file when no holding system exists, which permits local custody of referent-side media. The declared identity strategy addresses only identifier substitution. An explicit constraint is needed that the exemplar illustrates the concept and must never carry referent master data, otherwise the model drifts into asset management it declares out of scope." } ], "publicationHolds": [ "SINGLE-PROVIDER HOLD (owner-authorized): the repository owner waived Grok on 2026-08-29T09:06:27Z after repeated structured-output failures, so no independent second-provider review of WM-KNW-006 exists. Every publication artifact must carry a visible statement that this is a Claude-only result reviewed by a separate no-tools adversarial audit, and the result remains a reviewable draft rather than a corroborated finding.", "LIVE SOURCE AND VERSION VERIFICATION HOLD: all 31 source URLs must be re-resolved and re-pinned immediately before publication. Priority targets are SRC-006 (MVF 1.1 beta, April 2026), SRC-005 (OMG RDF rendering, retrieved 2026-09-02), SRC-029 (ADMS, retired August 2023, now SEMIC-maintained), SRC-010, SRC-012, SRC-027 and SRC-028 (retrieval-dated pages with no stable version pin), and SRC-031 (the single non-primary, tier-3 source). Any source that fails to resolve or whose version has moved must be re-cited or the dependent nodes downgraded.", "PAYWALLED-STANDARD HOLD: no ISO or ANSI/NISO clause text was read. The published draft must state that ISO 1087:2019, ISO 25964-1 and -2, ISO 30042:2019, ISO 24613 and ANSI/NISO Z39.19 are cited through public descriptions, RDF expressions and catalogue material only, and must make no clause-level conformance claim against any of them.", "REGISTRY-STATE HOLD: the frozen registry record carries status 'candidate' and review_state 'boundary-review-required', and its entry_kind 'standalone-mm' sits on a different axis from the research entry_kind 'entity'. Both values and the outstanding boundary review must be shown in the published draft rather than reconciled to one value.", "COMPOSITION-CONTRACT HOLD: the frozen relationship contract is empty and contains_ids is blank, while the service layers reference a composition ledger and roughly a dozen target-owned models (party, rights policy and evaluator, records disposition authority, constraint engine, audit facility, lexicon, domain entity models, classification and data-category registries, metric catalogue, namespace resolver). Publication must state that these boundaries are declared, not contract-bound, and that only parent_ids WM-KNW-002 is registered.", "ACCESS-SCOPE AMENDMENT HOLD: the person-naming designation exception and the licensed-definition exception cannot be enforced at the four declared access scopes (bundle, layer, finding, artifact). The draft must not present the access model as complete until a record-part scope is added or the limitation is stated explicitly.", "DECLARED-GAP HOLD: the privacy status of person-naming designations and the absence of a standard-native pre-coordination construct must remain visibly labelled as gap and provisional respectively, and the 'lifecycle' checklist dimension must be downgraded from covered to partial to match the model's own weakest-support admission.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Obtain licensed access to ISO 1087:2019, ISO 25964-1 and -2, ISO 30042:2019 (TBX), ISO 24613 (LMF) and ANSI/NISO Z39.19, read the clause text, and re-derive the support for the registration state model, the generic/partitive/instantial hierarchy kinds and compound equivalence rather than relying on surrogate renderings.", "Retry DatCatInfo or an equivalent data-category repository and pin persistent identifiers for part of speech, term type and administrative status, which ct-core-q-lex-grammar currently leaves as an unnamed registry reference.", "Research SSSOM and comparable mapping-exchange formats and either align ct-rel-art-mapping-set to them or record the non-alignment as a permanent open item; add confidence, similarity and probabilistic justification, which the model currently reduces to a free-text strength basis.", "Determine, per jurisdiction, whether a designation record naming a living person constitutes personal data, and reconcile any erasure obligation with the mandatory surviving tombstone and the never-reuse identifier rule.", "Resolve where the mandatory interchange loss report is held: whether it is a retained governed artifact in the ct-core zone, a section of ct-rel-art-interchange-package, or an explicitly transient response, and record the decision before identifiers are frozen.", "Settle system-of-record ownership for the topConceptOf / hasTopConcept inverse pair and for inScheme membership between WM-KNW-006 and parent WM-KNW-002, and register the outcome as a relationship-contract entry so the composition ledger stops referencing entries that do not exist.", "Model multilingual governance divergence, where different language communities steward the same concept under different authorities, and cover sign-language, tactile and other non-written, non-audio designation modalities that the current designation-type and symbol artifact only partially reach." ] }, "statistics": { "sources": 31, "bundles": 9, "layers": 19, "findings": 40, "questions": 173, "artifacts": 11, "functions": 24 } }