Proposal: a _leadership collection (the governing people behind each foundation)
Shane, this is the leadership dataset you mentioned. Opening it as an issue first per CONTRIBUTING, since it adds a new collection.
What it is
A companion collection, _leadership/.md, keyed by the same identifier as the foundation record, holding the board directors, officers, and paid staff of each foundation. The foundation model already carries boardSize, boardType, numberOfEmployees and teamurl, the counts and the roster URL, but not the named individuals. This fills that gap.
Why it fits the directory as it stands
It sits as a sibling collection alongside _entities, _sponsorships and _reports, keyed on the same identifier, so it cross-references foundations with no change to the foundation model.
The record derives from Schema.org Person, matching your use of Schema.org Organization for foundations.
It ships a _data/leadership-schema.json that mirrors foundations-schema.json (draft-06, the same title / description / section field style), plus a leadership-template.md in the style of foundation-template.md, so schema_utils and a future OpenAPI endpoint cover it the same way.
It answers your open metadata-freshness question
CONTRIBUTING asks: "how do we annotate when various metadata fields were last updated/verified?" Every leadership record carries an asOf date, every source carries a retrieved date, and every individual fact carries a confidence (1.0 only for facts stated verbatim, lower with a note when inferred). Nothing is guessed; absent data is null with a note in the body. Every person carries a sourceUrl to the foundation's own page, which also satisfies the validation rule that factual changes trace to a link.
What I have ready to contribute
Full current rosters for 86 foundations (76 publish a roster; 1,161 individuals total), already crawled and schema-valid.
A deterministic, no-AI refresh check as a GitHub Action: it fetches each roster page weekly, hashes the visible text, and opens an issue listing only the foundations whose pages actually changed, so re-verification stays a handful of pages, not all 85.
A short cross-foundation governance analysis for _reports (board-size distribution, paid-versus-volunteer split, how many foundations even publish their leadership).
Also contains the freshness tool
assets/python/leadership_refresh.py — deterministic no-AI detector (fetches each roster page, hashes the visible text, diffs against saved state, emits only changed/new/unreachable).
.github/workflows/leadership-refresh.yml — the GitHub Action that runs it weekly and opens an issue listing the foundations whose pages actually changed.
The one call for you
Companion collection (_leadership/.md, my lean, keeps roster churn out of the foundation record and leaves room for a future history dataset), or fields on the foundation record itself. Your directory, your maintenance, so your call.
All of it is Apache-2.0, per CONTRIBUTING.
Proposal: a _leadership collection (the governing people behind each foundation)
Shane, this is the leadership dataset you mentioned. Opening it as an issue first per CONTRIBUTING, since it adds a new collection.
What it is
A companion collection, _leadership/.md, keyed by the same identifier as the foundation record, holding the board directors, officers, and paid staff of each foundation. The foundation model already carries boardSize, boardType, numberOfEmployees and teamurl, the counts and the roster URL, but not the named individuals. This fills that gap.
Why it fits the directory as it stands
It sits as a sibling collection alongside _entities, _sponsorships and _reports, keyed on the same identifier, so it cross-references foundations with no change to the foundation model.
The record derives from Schema.org Person, matching your use of Schema.org Organization for foundations.
It ships a _data/leadership-schema.json that mirrors foundations-schema.json (draft-06, the same title / description / section field style), plus a leadership-template.md in the style of foundation-template.md, so schema_utils and a future OpenAPI endpoint cover it the same way.
It answers your open metadata-freshness question
CONTRIBUTING asks: "how do we annotate when various metadata fields were last updated/verified?" Every leadership record carries an asOf date, every source carries a retrieved date, and every individual fact carries a confidence (1.0 only for facts stated verbatim, lower with a note when inferred). Nothing is guessed; absent data is null with a note in the body. Every person carries a sourceUrl to the foundation's own page, which also satisfies the validation rule that factual changes trace to a link.
What I have ready to contribute
Full current rosters for 86 foundations (76 publish a roster; 1,161 individuals total), already crawled and schema-valid.
A deterministic, no-AI refresh check as a GitHub Action: it fetches each roster page weekly, hashes the visible text, and opens an issue listing only the foundations whose pages actually changed, so re-verification stays a handful of pages, not all 85.
A short cross-foundation governance analysis for _reports (board-size distribution, paid-versus-volunteer split, how many foundations even publish their leadership).
Also contains the freshness tool
assets/python/leadership_refresh.py — deterministic no-AI detector (fetches each roster page, hashes the visible text, diffs against saved state, emits only changed/new/unreachable).
.github/workflows/leadership-refresh.yml — the GitHub Action that runs it weekly and opens an issue listing the foundations whose pages actually changed.
The one call for you
Companion collection (_leadership/.md, my lean, keeps roster churn out of the foundation record and leaves room for a future history dataset), or fields on the foundation record itself. Your directory, your maintenance, so your call.
All of it is Apache-2.0, per CONTRIBUTING.