Skip to content

LOKF copy of gist_core.yaml

Datasetreferencedatasets/gist-lokf-copy

Nobody has checked this yet

still a draft

Written 2026-10-28 by ktl-librarian (automation).

The full record
Checks
none recorded
Sources
References
Derived from
Pointed to by
Graph
Open this concept in the knowledge graph
IRI
https://w3id.org/lmodel/gist/knowledge/datasets/gist-lokf-copy
Licence
CC BY 4.0
Files
MarkdownJSON-LDSource on GitHubHistory on GitHub

LinkML merges every imported element name into one namespace, and keeps the definition from the last import. A LOKF domain schema imports LOKF’s lokf.yaml, and the classes its concepts name must descend from LOKF’s Concept. The gist LinkML schema shares five names with lokf.yaml (Person, Organization, name, description and license), and none of gist’s classes descends from Concept. So a domain schema cannot import gist_core.yaml as it is.

The LOKF copy is gist_core.yaml as lokf adapt rewrites it. adapt is in lokf from 0.9.0, the floor that .lokf/pyproject.toml sets. It makes these changes, and lists them in a note in the copy’s header:

  • It renames the five shared names. Person becomes GistPerson, Organization becomes GistOrganization, and name, description and license become gist_name, gist_description and gist_license. Each keeps its gist IRI and its title, and lists its old name as an alias.
  • It re-roots gist’s 19 top classes on Concept. These are the classes with no parent that are not a mixin, leaving out Any. So a concept may name any gist class except the GistThing mixin and Any as its type, for example type: Requirement. A slot ranged over a gist class then takes the IRI of the concept it names, and lokf validate --check-refs checks that the concept exists.
  • It imports lokf beside linkml:types, and names the schema gist_core_lokf.

Save the copy beside lokf.yaml as gist_core_lokf.yaml, and import gist_core_lokf from the domain schema. gist_core.yaml already holds the SSSOM mappings, so the copy carries them.

just gen-lokf-copy [out] builds the copy into out, which defaults to dist/lokf. The recipe runs lokf adapt on src/gist/schema/gist_core.yaml with --prefix gist, and passes one --root for each top class, which it reads from the schema. gist declares no identifier slot, so adapt cannot find the top classes by itself. adapt checks the copy against the lokf.yaml that the .lokf sidecar locks, and writes nothing when the check fails. CI runs the same recipe in the Python 3.14 job of .github/workflows/main.yaml. So if a lokf upgrade breaks the copy, its pull request fails, rather than a release that is already tagged.

.github/workflows/lokf-copy-release.yaml attaches the copy to a GitHub Release as gist-linkml-lokf-<tag>.yaml, with a .sha256 checksum beside it. semantic-release dispatches it for every tag it releases (release playbook), and it also runs when a person publishes a release by hand. A person can run it for an existing tag to repair that tag’s asset. Its build job has a read-only token. Only the attach job can write: it checks the file against its checksum before it uploads it, and in a public repository it also attests the file’s build provenance.