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 KiB
2 KiB
Reference Model Review
What PiCo contributes
PiCo is the most relevant reference because it stays small while still handling provenance, source anchoring, and interpretation.
Useful PiCo lessons:
- Reuse external ontologies aggressively instead of inventing bespoke top-level classes.
- Keep the conceptual centers explicit:
PersonObservation,PersonReconstruction, andSource. - Treat provenance as structural, not optional decoration.
- Allow the engineering/data layer to be richer than the conceptual layer.
- Use documentation, diagrams, and examples as part of the ontology product.
What to copy from PiCo
- A small number of stable conceptual hubs.
- A strong observation/reconstruction pattern where evidence and interpretation are separated.
- Use of existing vocabularies such as Schema.org, PROV-O, and domain-specific vocabularies.
- Human-readable documentation that explains modeling intent rather than only listing terms.
What not to copy blindly
- PiCo is person/history centered; the GLAM custodian domain is institution, holdings, access, provenance, and record-oriented.
- PiCo's class list should inspire modeling discipline, not determine class names.
- The parsimonious GLAM ontology must preserve room for archives, museums, libraries, and hybrid custodians.
Additional parsimonious ontology principles
- Prefer semantic hubs over large taxonomies.
- Push local specialization into mappings and engineering refinements.
- Use object properties for real semantic relations; use datatype properties for compact descriptive facts.
- Prefer a few reusable generic predicates over many narrow bespoke predicates.
Consequence for this project
The parsimonious ontology should function like a conceptual facade over the engineering ontology:
- small enough for comprehension and UML browsing
- rich enough to express custodians, collections/record sets, provenance, access, identifiers, place, time, and classification
- explicit enough to explain how conceptual hypernyms are realized in the engineering model