LOKF copy of gist_core.yaml
datasets/gist-lokf-copyNobody 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
- Regenerate the schema and its artefacts (references)
- Release the gist Python package (references)
- 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
LOKF copy of gist_core.yaml
Section titled “LOKF copy of gist_core.yaml”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.
PersonbecomesGistPerson,OrganizationbecomesGistOrganization, andname,descriptionandlicensebecomegist_name,gist_descriptionandgist_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 outAny. So a concept may name any gist class except theGistThingmixin andAnyas itstype, for exampletype: Requirement. A slot ranged over a gist class then takes the IRI of the concept it names, andlokf validate --check-refschecks that the concept exists. - It imports
lokfbesidelinkml:types, and names the schemagist_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.