Title slide. No header bar here; the deck introduces itself first.

Orientation act target: ~2 minutes. Comic: comic-orientation, caption above.

Meet the protagonist. Hold on the portrait for a beat before the first line lands.

Reveal 1 of 4. She introduces herself.

Reveal 2 of 4. She writes software for a living.

Reveal 3 of 4. The thing she wants to build: a Pokémon app.

Reveal 4 of 4. The call to action that opens the build.

Reveal 1 of 3. Zelda moves to the left; the right half stays empty until the data model arrives.

Reveal 2 of 3. First real decision: the data model. A Species, the Moves it knows, the Abilities it has.

Reveal 3 of 3. Three entities, two relationships. Nothing clever.

The data store needs a model and a schema before it can hold anything. A small app skips that question: build it with Django and the framework's own model class is the de facto schema. Django turns that one file into the SQL tables, the Python objects, and the frontend forms. One owner, one source of truth. No schema background needed for the rest of this talk.

Comic: comic-success, 3-panel strip, captions baked into the art. Deploy, crowd adopts it, money follows.

Panel 1 of 3. She's drowning in notifications, bug reports, and feature requests, alone. The empty cells hold the other two panels' places, so nothing shifts as they appear.

Panel 2 of 3. The idea lands: she can't do this alone anymore.

Panel 3 of 3. Zelda, Amy, Ned and James, each at their own desk with room to work — a small team now builds the Pokédex app together.

Growing Pains act target: ~3 minutes. The team splits the app: React on the front, FastAPI in the middle, Postgres at the back.

Four places now describe the same Species. Nobody agreed which one is the schema.

Frontend (React), backend (FastAPI/Pydantic), and the database each own a different version of the same Species record, and each team is certain its layer is the one that should define the model. Three definitions of one record, drifting the moment any one of them changes.

Comic: comic-complication-argument, different teams each insisting their model is the real one.

Comic: comic-loudest-wins. Everybody else translates, by hand, forever.

Same beat, different winner. Which model wins is an accident of who argued hardest, not of which one is right.

Third winner, same losers. Rotate the winner and nothing improves — the model still lives in one team's head.

Short divider. The product, the team and the surfaces all expand from here.

More growth. The product spreads, a wet lab opens to actually grow the creatures, and outside partners plug in. Each of those is a new surface with its own idea of what a Species is.

Same diagram as before, now buckling. The web app and the Android control panels are two separate surfaces, both talking HTTP to the backend. The backend talks SQL to Postgres and RPC to the wet lab, where LIMS and the sequencer belong to contractors and process control is firmware on the bioreactors.

Same diagram, now with the cost named: every new surface is another place the model gets redefined. The web app and the Android control panels are two separate surfaces, both talking HTTP to the backend. The backend talks SQL to Postgres and RPC to the wet lab, where LIMS and the sequencer belong to contractors and process control is firmware on the bioreactors.

A mobile Pokédex app joins (Android, Java). The API becomes a product other apps integrate against (OpenAPI). Firmware on the actual scanning hardware ships its own wire format (Protobuf). Each one wants its own model, in its own language, under its own control. Who owns the Species record now?

Comic: comic-schema-change. A real schema change lands: height becomes a min-max range in millimetres, not a bare float. Every one of the six independent models — Django, Pydantic, TypeScript, SQL, Java, OpenAPI, Protobuf — needs to catch up by hand.

One change lands. The strip builds up panel by panel as the background warms toward anger.

Seven codebases, and every one of them has to be edited by hand.

Something still breaks: a 400 Invalid Response, because one of the seven definitions didn't get the memo in time.

The argument scrolls off. Nobody owns the model, so nobody can fix it.

Rock bottom. Lowest morale of the talk — hold the beat here before the turn.

The background snaps back to paper the moment LinkML walks in.

One YAML file, every target generated from it.

schema/sample.yaml is the one file that says what a record is. Pydantic model, SQL table, validation rule, Scala, SHACL, GraphDB, Protocol Buffers — all generated, not hand-written.

Every team gets its own generated artifact from the one schema. Nobody hand-translates anymore.

Real excerpts from github.com/vladistan/linkml-pokemon, trimmed for the slide. Left: the LinkML schema. Right: the generated Python dataclass.

Real excerpt from the Pydantic generator target. Same schema, a different Python shape than the dataclass generator: slot_uri aliases (hasColour) and looser typing on ranges the generator doesn't model as classes.

Real excerpt from the SQL DDL generator target. hasHeight and hasWeight become foreign keys into a Quantity table, because the schema marks them inlined ranges, not bare scalars.

Real excerpt from the Protobuf generator target. Same slots, wire format this time — firmware's bytes-on-the-wire model, generated from the same file instead of hand-maintained.

Real excerpt from the TypeScript generator target. The frontend's interface, generated, with the schema's own description text carried over as doc comments.

Live page: the linkml-pokemon generated data dictionary, QuantityValue entry. Same NFR-005 exception as the generators-index iframe — needs network, blanks in static exports or offline, accepted as a risk.

LinkML is bigger than ten minutes. Validators, data loaders, Schema Automator (infer a schema from data), Data Harmonizer, and more all live in the same ecosystem. This talk stays on schema-to-artifact generation; the rest is worth its own talk.

Walkthrough reused from the ISMB 2024 LinkML tutorial.

LinkML grew out of a concrete need inside the Monarch Initiative: too many ad hoc schemas describing the same biomedical data. BBOP is Berkeley Lab's Berkeley Bioinformatics Open-source Projects group.

Monarch itself is a multi-institution collaboration. LinkML inherited that institutional backing rather than starting from a single company or grant.

Numbers checked live against github.com/linkml/linkml. A GitHub repo's counts move daily — state them as a snapshot, not an eternal fact.

MIxS: minimum information standards for genomic and environmental samples. Monarch: cross-species disease and phenotype data. BioLink: a shared vocabulary for biomedical knowledge graphs.

The same schema/sample.yaml that generates code also generates a browsable data dictionary. No separate documentation tool, no drift between the docs and the code.

The presenter has contributed to LinkML's documentation and tooling and is glad to pair with a first-time contributor. Contributors photo from the ISMB 2024 LinkML tutorial.

Four ways in, lowest commitment first: a good-first-issue PR, then office hours, then the recurring community call, then the mailing list and Slack for ongoing conversation.

Demo and Outlinks act target: ~2 minutes. This act compresses first: when the slot runs short, cut straight to the data-dictionary slide and the outlinks slide, dropping both live demos.

Questions divider.

Closing divider.