kempersc/glam
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
glam/docs/plan/semantic_ontology/04-engineering-mapping-strategy.md
kempersc ab5ad23699 Add parsimonious LinkML package and metadata 
- 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.
2026-03-13 16:48:32 +01:00

2.8 KiB
Raw Blame History

Engineering Mapping Strategy

Core requirement

The mapping between the parsimonious ontology and the engineering ontology is a core deliverable because it explains how broad semantic concepts become concrete operational data structures.

Mapping pattern

For every parsimonious concept, document:

  • the semantic intent of the parsimonious class/slot
  • the engineering classes it covers
  • the engineering slots it covers
  • the engineering enums or type classes it depends on
  • whether each relation is exact, broad, narrow, close, or related

Expected asymmetry

The mapping is intentionally asymmetric:

  • parsimonious classes are often hypernyms
  • engineering classes are often narrower data-ready realizations
  • many engineering structures may map upward into one parsimonious node

Example pattern:

Parsimonious class: Custodian
  -> broad semantic parent of AcademicArchive, Museum, Library, PlatformCustodian, ParishArchive, etc.

Parsimonious slot: holds
  -> realized by engineering slots such as hold, hold_record_set, has_custodian, has_member, is_or_was_holder_of, depending on context

Mapping rules that must remain active

  • exact vs broad vs narrow mappings must be explicit
  • class-to-class and slot-to-property distinctions must be preserved
  • external ontology mappings must be verified against data/ontology/
  • generic predicate discipline must be preserved even in the parsimonious layer

New mapping deliverables

Planned outputs under schemas/20251121/linkml/parsimony/modules/mappings/:

  • class alignment matrix
  • slot alignment matrix
  • type-system bridge across classes, enums, and typing predicates
  • hypernym-to-engineering realization notes
  • UML-friendly conceptual-to-engineering bridge views

Verified external ontology anchors should be added directly to parsimonious classes and slots using LinkML mapping fields such as broad_mappings, narrow_mappings, close_mappings, and related_mappings.

Current anchor examples include:

  • schema:Organization, schema:CreativeWork, schema:Place, schema:url, schema:startDate
  • dcterms:source, dcterms:accessRights
  • prov:Entity, prov:Activity, prov:Agent, prov:wasDerivedFrom, prov:wasGeneratedBy, prov:generated, prov:used
  • crm:E39_Actor, crm:E41_Appellation, crm:E53_Place, crm:E55_Type, crm:E78_Curated_Holding, crm:P1_is_identified_by, crm:P4_has_time-span
  • rico:Agent, rico:RecordSet, rico:Identifier, rico:isOrWasHolderOf, rico:hasOrHadIdentifier
  • skos:Concept, skos:prefLabel, skos:note
  • pico:PersonObservation, pico:PersonReconstruction

Why this matters

Without this bridge, the parsimonious layer risks becoming only a simplified diagram. With the bridge, it becomes an explanatory semantic interface for databases, extraction pipelines, and engineering-level knowledge graph modeling.