Skip to content

Define the initial HDMF → LinkML mapping conventions #1487

Description

@rly

Part of the "Read and write LinkML schema for HDMF (CSRMatrix / base.yaml)" epic

Decide and document how a limited subset of HDMF Schema Language (HDMFSL) constructs map to LinkML. The deliverable is a mapping-conventions document; translating the schemas and building the reader are later issues that depend on this one. The conventions are defined against the specific constructs used by base.yaml and CSRMatrix (sparse.yaml).

The document defines a LinkML representation, with rationale, for:

  • data_type_def / data_type_inc — defined types and inheritance, and how the reader tells a GroupSpec from a DatasetSpec.
  • The group / dataset / attribute distinction — must survive in the LinkML so the reader can rebuild the right Spec subclass.
  • Object naming and identity — fixed name, default_name, and unnamed types.
  • dtypes — HDMFSL dtypes to LinkML ranges without losing precision, plus the no-dtype case.
  • Arrays (dims / shape) — fixed, unspecified (null), and multiple-allowed shapes via the arrays metamodel; dimension naming.
  • quantity1 / ? / * / + to required / multivalued.
  • Namespace level — how an HDMFSL namespace.yaml (its name, version, metadata, and list of schema files) maps to LinkML, including how the per-file schemas relate to the namespace. Cross-namespace imports are out of scope here.

Acceptance criteria

  • Mapping-conventions document committed to docs/source/linkml-mapping.rst, covering the constructs above with rationale and noting that this is not a complete mapping of all HDMFSL constructs.
  • Shows the conventions support faithful reconstruction of the Spec objects HDMF loads from the test namespace (base.yaml and sparse.yaml) via the namespace/catalog path.

Metadata

Metadata

Assignees

Type

No fields configured for Task.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions