kempersc/glam
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
glam/.opencode/rules/engineering-parsimony-and-domain-modeling-rule.md
kempersc 554fe520ea Add comprehensive rules for LinkML schema management and ontology mapping 
- Introduced Rule 42: No Ontology Prefixes in Slot Names to enforce clean naming conventions.
- Established Rule: No Rough Edits in Schema Files to ensure structural integrity during modifications.
- Implemented Rule: No Version Indicators in Names to maintain stable semantic naming.
- Created Rule: Ontology Detection vs Heuristics to emphasize the importance of verifying ontology definitions.
- Defined Rule 50: Ontology-to-LinkML Mapping Convention to standardize mapping practices.
- Added Rule: Polished Slot Storage Location to specify directory structure for polished slot files.
- Enforced Rule: Preserve Bespoke Slots Until Refactoring to prevent unintended migrations during slot updates.
- Instituted Rule 56: Semantic Consistency Over Simplicity to mandate execution of revisions in slot_fixes.yaml.
- Added new Genealogy Archives Registry Enrichment class with multilingual support and structured aliases.
2026-02-15 19:20:09 +01:00

2.3 KiB
Raw Blame History

Rule: Engineering Parsimony and Domain Modeling

Critical Convention

Our ontology follows an engineering-oriented approach: practical domain utility and stable interoperability take priority over minimal, tool-specific class catalogs.

Rule

  1. Model domain concepts, not implementation tools.

    • Reject classes like ExaSearchMetadata, OpenAIFetchResult, ElasticsearchHit.

  2. Prefer generic, reusable activity/entity classes for operational provenance.

    • Use classes such as ExternalSearchMetadata, RetrievalActivity, SearchResult.

  3. Capture tool/vendor details in slot values, not class names.

    • Record with generic predicates like has_tool, has_method, has_agent, has_note.

  4. Digital platforms acting as custodians are valid domain classes.

    • Platform-as-custodian classes (for example YouTube-related custodian classes) are allowed.
    • Data processing/search tools are not ontology class candidates.

  5. Avoid ontology growth driven by transient engineering stack choices.

    • New class proposals must be justified by cross-tool, domain-stable semantics.

Rationale

  • Tool names are volatile implementation details and age quickly.
  • Domain-level abstractions maximize reuse, query consistency, and mapping stability.
  • This aligns with an engineering ontology practice where strict theoretical parsimony in candidate theories is not the only optimization criterion; practical semantic interoperability and maintainability are primary.

Examples

Wrong

classes:
  ExaSearchMetadata:
    class_uri: prov:Activity

Correct

classes:
  ExternalSearchMetadata:
    class_uri: prov:Activity
    slots:
      - has_tool
      - has_method
      - has_agent

References

  1. Liefke, K. (2024). Natural Language Ontology and Semantic Theory. Cambridge Elements in Semantics. DOI: 10.1017/9781009307789. URL: https://www.cambridge.org/core/elements/abs/natural-language-ontology-and-semantic-theory/E8DDE548BB8A98137721984E26FAD764

  2. Liefke, K. (2025). Reduction and Unification in Natural Language Ontology. Cambridge Elements in Semantics. DOI: 10.1017/9781009559683. URL: https://www.cambridge.org/core/elements/abs/reduction-and-unification-in-natural-language-ontology/40F58ABA0D9C08958B5926F0CBDAD3CA