Synced automatically from infinity-project/rulebook (
main) at build time – edit the source repository, not this file.
Becoming part of the INFINITY ecosystem
What is an Ecosystem component?
Any resource produced by or used in the research activity. See the reference documentation for a list of component types.
What is an Ecosystem container?
Components can be grouped in containers, representing a research activity (e.g. a project). See the reference documentation for a list of container types.
INFINITY Ecosystem Website
A repository contains the development work for at least one component in the INFINITY Ecosystem. One markdown text file should expose annotations (metadata) relative to a single component included in the repository — for example, a component-name.md file using the INFINITY Ecosystem annotation schema (the file can have any name). A repository can include multiple annotated files, hence expose multiple components. Those annotations will be used by the INFINITY Ecosystem website, which provides a user interface for navigating through the Ecosystem (with aggregation pages, tags, etc). Note that the INFINITY Ecosystem website uses the content of Codeberg repositories as-is, hence the need for good quality annotations/documentation.
Developing Schema Components Annotations
The annotations should be written at the top of the markdown file, between two --- lines. The markup format is YAML (mostly a “key: value” format — see the schema given in Repository requirements). Developers can use this YAML validator to test the YAML code.
Process towards ecosystem releases
- Champions plan releases with project-specific frequency and rationale.
- Internal agreement (in the repository) when the release is ready.
- The Technical Board (TB) is informed of a planned release.
- Champions specify a new version number and expected deadline.
- Champions ensure component metadata is accurate.
- TB tests and validates the release candidate.
- Testing and validation are usually planned at a TB meeting, to be completed by the next TB meeting, unless there is project-specific urgency.
- Champion makes the new release following the guidelines of this rulebook:
- Linked to a Zenodo entry
- Updated citation file
- The Ecosystem website is updated with the new component metadata
Ecosystem minimal requirements
Software: Components admitted to the INFINITY ecosystem must meet the DS4CH and ECCCH onboarding criteria as defined by those platforms (links to be provided). Interoperability is expected to be mediated by the use of RESTful APIs and, where applicable, by plugins for existing Collection Management Systems.
Datasets: Data formats, vocabularies and schema should always align as much as possible with existing standards and specifications in use by CHIs, especially those used with DS4CH and ECCCH.
Knowledge graphs and ontologies: Where possible, INFINITY reuses and extends existing cultural heritage ontologies — in particular the CIDOC CRM and the Europeana Data Model. For outputs intended for publication within the ECCCH knowledge base, INFINITY plans to align its ontological representations with the Heritage Digital Twin Ontology (HDTO), the ontological framework developed and maintained by the ECHOES consortium as the semantic infrastructure of the ECCCH platform. Alignment with the HDTO is a requirement for interoperability with the ECCCH knowledge graph.
Current ECCCH technical interoperability requirements and guidelines may be found at zenodo.org/records/18656368, Chapters 3 and 4.
← Previous: Semantic layer development and documentation · Back to index · Next: Ethical guidelines →