[dweindl]

Adds a machine-readable, PEtab-version-independent metadata file problems/<ProblemID>/metadata.yaml for each problem. For now, it holds a single required field, short_description: one plain-ASCII sentence (20–160 characters) stating the model type (reaction network, compartmental epidemiological model, cell population model, ...), the biological system and, where informative, the data. It's kept short so it can later go into the overview table. The name leaves room for a later free-form description field for longer text (hints, experiences, additional references, ...). Further fields (e.g., a structured model type, DOI) are planned and will be added separately.

Example (Boehm_JProteomeRes2014):

short_description: Reaction network model of Epo-induced STAT5A/STAT5B phosphorylation and homo- and heterodimerization, fitted to quantitative mass spectrometry data.

The metadata is kept out of problem.yaml so it isn't duplicated across v1/ and the upcoming v2/, and doesn't interfere with PEtab YAML validation.

Changes:

• metadata.yaml with a short description for all 35 problems. Descriptions were written based on the publications and model files; please check the ones for problems you know well.
• Pydantic model ProblemMetadata defining the metadata format. Unknown fields are rejected, so each new field requires a model change.
• JSON schema benchmark_models_petab/schemas/metadata.schema.json, generated from ProblemMetadata via write_metadata_schema() and included in the package via MANIFEST.in; a test checks that it is up to date.
• get_metadata(id_), returning a ProblemMetadata, and a bmp-check-metadata CLI that validates all metadata files; added as a step to the "Tests" workflow.
• pydantic and pyyaml added as explicit dependencies (both are already transitive dependencies of recent petab versions).
• CONTRIBUTING.md and the PR template updated.

🤖 Drafted with AI assistance

[dilpath]

• short_description instead of description? In future, I think all information that is normally stored in the github issues will be inside the metadata file so there is a single-source of information, and then we will need some generic description field where a lot of hints/tips/experiences/additional references/longer descriptions etc. can go
• implement an object model for metadata, e.g. with pydantic and possibly mkstd? Will simplify things a bit I think, e.g. adding new fields and validating files.

[dilpath]

Suggested change

	# version-independent metadata (`<MODELS_DIR>/<ProblemID>/metadata.yaml`)
	METADATA_FILENAME: str = "metadata.yaml"
	METADATA_FILENAME: str = "metadata.yaml"

[dweindl]

• short_description instead of description? In future, I think all information that is normally stored in the github issues will be inside the metadata file so there is a single-source of information, and then we will need some generic description field where a lot of hints/tips/experiences/additional references/longer descriptions etc. can go

  • implement an object model for metadata, e.g. with pydantic and possibly mkstd? Will simplify things a bit I think, e.g. adding new fields and validating files.

Changed to short_description, using pydantic now but keeping the pydantic-derived jsonschema for external validation.