ab5ad23699
- Created manifest.json for the parsimonious LinkML package. - Added metadata.yaml with detailed information about the Heritage Custodian Parsimony Ontology. - Established directory structure for classes, enums, mappings, and slots with corresponding README files. - Each module directory includes a brief description of its purpose and planned scale.
2.7 KiB
2.7 KiB
Rule Updates for Parsimony
Why rule work is required
The current .opencode/rules/linkml/ set is optimized for the engineering ontology. Much of it remains correct for the parsimonious package, but several rules need extension so the parsimonious layer is not forced into engineering-scale detail.
Rules to keep as-is
- verified ontology mappings
- ontology detection from actual ontology files
- mapping specificity: exact vs broad vs narrow
- centralized slots
- no inline class-file slots
- generic slots over bespoke predicates
- LinkML YAML hygiene and import discipline
Rules that need extension or clarification
1. Engineering parsimony vs semantic parsimony
Current rule: engineering-parsimony-and-domain-modeling-rule.md
Needed extension:
- distinguish the engineering ontology from a semantic facade ontology
- allow a parsimonious package to intentionally collapse multiple engineering classes into one conceptual hypernym
- clarify that this is not a violation of semantic consistency when the downward mapping is explicit
2. Semantic consistency over simplicity
Current rule emphasis is strongly pro-structure for engineering migrations.
Needed extension:
- clarify that semantic consistency across layers can sometimes justify fewer classes in the parsimonious package
- state that engineering richness is preserved in mappings rather than duplicated in the parsimonious layer
3. Slot usage minimization
Needed extension:
- permit sparse, meaningful
slot_usagein the parsimonious layer when it serves conceptual narrowing or bridge documentation - keep redundant overrides prohibited
4. Ontology-to-LinkML mapping convention
Needed extension:
- add a dedicated section for parsimonious-to-engineering internal mappings
- distinguish external ontology alignment from internal cross-layer alignment
Proposed new rule themes
- parsimonious layer as hypernym layer
- mandatory concept-to-engineering realization mapping
- no silent semantic collapse: every collapsed concept must list covered engineering refinements
- dashboard-first documentation for parsimonious schemas
- parsimonious slots must prefer hypernym predicates over copied engineering slot names with implementation suffixes
- parsimonious classes should avoid redundant
Conceptsuffixes and use semantically informative names - parsimonious slot names should avoid over-binding to one source type or one implementation mechanism when a broader evidential or process relation is intended
- every external class/property mapping in the parsimonious package must be verifiable in
data/ontology/with zero tolerance for unverified references
Delivery implication
Rule editing should be treated as part of ontology implementation, not post hoc cleanup.