Bioschemas is a community specification effort that extends schema.org with types and usage profiles tailored to life-science resources — datasets, samples, genes, proteins, taxa, training materials, and computational tools — so that this content becomes machine-readable and discoverable by search engines and aggregators in the same way schema.org already makes recipes, products, and events discoverable. It has been developed as an open community initiative since November 2015 and is a flagship policy of ELIXIR, the intergovernmental organisation coordinating life-science data infrastructure across Europe. For research-data managers and repository operators in the life sciences, Bioschemas matters because it gives a concrete, implementable answer to the FAIR data principles’ Findable requirement: structured, standardised markup that a search engine, aggregator, or harvester can actually parse, rather than a page of prose a human has to read to figure out what a resource contains.
What Is Bioschemas?
Bioschemas makes two related contributions. First, the community proposes new types and properties to schema.org itself where the life sciences need vocabulary schema.org doesn’t already have — on 7 July 2021, schema.org’s release incorporated five Bioschemas-originated types (Gene, Protein, Taxon, and related terms) directly into the core vocabulary. Second, and more central to day-to-day use, Bioschemas defines profiles over both those new types and existing schema.org types (Dataset, DataCatalog, Course, SoftwareApplication, and more). A profile is a usage specification: it identifies which properties of a type are mandatory, recommended, or optional for describing a given kind of life-science resource, with cardinality guidance, so that two independent repositories marking up the same kind of resource converge on comparable, predictable markup rather than each choosing a different subset of schema.org’s very large general-purpose vocabulary.
This profile layer is Bioschemas’ real practical value: schema.org alone is broad enough to describe almost anything on the web, which makes it easy for two sites to mark up “the same” kind of resource in incompatible ways. Bioschemas narrows that space for specific life-science resource types so that markup produced by different repositories, institutes, and tools is actually interoperable in practice, not just theoretically expressible.
Core Type Profiles
Bioschemas maintains profiles at several maturity levels — Release (stable, recommended for production use), In Development (draft, subject to change), and Deprecated. As of the current specification, released profiles include:
- Dataset and DataCatalog — describing a life-science dataset and the catalog/repository that hosts it, the profiles most directly relevant to research data management.
- Sample — describing a physical or biological sample used in or produced by research (a BioSample profile is under active development for more specialised biosample description).
- Gene, Protein, MolecularEntity, and ChemicalSubstance — describing molecular-level entities.
- Taxon and TaxonName — describing taxonomic classification.
- ComputationalTool and ComputationalWorkflow, with an accompanying FormalParameter profile — describing software tools and workflows and their inputs/outputs.
- Course, CourseInstance, and TrainingMaterial — describing life-science training and educational resources, an area with its own dedicated Bioschemas training-profiles specification work.
A larger set of profiles — including BioSample, Study, Disease, Phenotype, ProteinStructure, RNA, SequenceAnnotation, and profiles for people, organizations, and scholarly articles — exists in draft/in-development status; a handful of earlier profiles (including Beacon and DataRecord) have been deprecated as the specification has matured. Anyone implementing Bioschemas markup should confirm a given profile’s current status and property list directly at bioschemas.org/profiles rather than assuming a version cited elsewhere is still current — profiles do get revised as the community’s understanding of a resource type improves.
How Bioschemas Supports FAIR Data Practice
Bioschemas is not itself a FAIR-compliance framework or a repository platform — it is a markup convention. But it operationalises the Findable (F) criterion of FAIR unusually directly: F1-F2 call for data to be described with rich, structured metadata using a globally unique, resolvable identifier; F4 calls for that metadata to be registered or indexed so it can be searched. Bioschemas markup embedded in a repository’s own web pages, using schema.org/JSON-LD, is exactly the kind of structured, indexable description search engines and life-science-specific aggregators are built to consume — including Google Dataset Search, which indexes schema.org Dataset markup generally, and life-science-specific discovery tools that specifically look for Bioschemas profiles. A repository can satisfy A (Accessible), I (Interoperable), and R (Reusable) through other means — access protocols, controlled vocabularies, licensing — but without machine-readable, standardised description on the page itself, a life-science resource is effectively invisible to the automated discovery tools FAIR’s Findable criterion assumes exist.
Bioschemas, RO-Crate, Croissant, and Plain schema.org/Dataset: How They Differ
Bioschemas is easy to conflate with other schema.org-adjacent, FAIR-oriented specifications CASRAI covers elsewhere. They solve related but distinct problems and are frequently used together rather than as alternatives:
- Plain schema.org/
Datasetis the general-purpose vocabulary any dataset page can use for basic web/search-engine discovery. It works for any domain but leaves most life-science-specific detail (which gene, which taxon, which sample type) unexpressed because schema.org’s core vocabulary doesn’t have those terms. - Bioschemas is that same schema.org foundation, narrowed and extended with life-science-specific types and profiles, embedded directly in a resource’s own web page as JSON-LD (or other schema.org-supported markup) so search engines and life-science aggregators can find and understand it. Its scope is discovery on the open web, for life-science resource types specifically.
- RO-Crate is a packaging specification: it bundles a dataset, workflow, or software release together with a metadata file (also JSON-LD, also grounded in schema.org) describing what’s inside and how the parts relate, for deposit or transfer as a self-contained unit. It is domain-agnostic and solves a different problem — describing the internal structure of a package a user downloads or deposits — rather than making a page discoverable on the open web. The two are complementary: an RO-Crate’s root entity is typically a schema.org
Dataset, and a life-science RO-Crate could in principle use Bioschemas profile properties within that same JSON-LD structure. - Croissant extends schema.org/
Datasetin a different direction again — toward machine-learning consumption specifically (record sets, train/validation/test splits, feature roles), maintained by MLCommons. It is not life-science-specific and does not compete with Bioschemas’ scope.
The practical takeaway for a life-science data manager: if the goal is making a dataset, sample, or tool page discoverable by search engines and domain aggregators, Bioschemas profiles are the relevant specification. If the goal is packaging a composite research output for deposit, RO-Crate is the relevant one. If the output is specifically an ML-training dataset, Croissant may also apply. All three can, in principle, coexist on the same resource, because all three build on the same underlying schema.org/JSON-LD foundation.
Adoption in Practice
Bioschemas markup has been deployed across a substantial number of life-science web resources — documented at over 70 sites and more than 11 million marked-up pages as of a November 2019 community count, with adoption continuing to grow through ELIXIR’s implementation studies since. Markup is consumed both by general search engines (Google Dataset Search indexes schema.org Dataset markup, including Bioschemas-profiled instances) and by life-science-specific discovery infrastructure built specifically to look for Bioschemas types. Because adoption is driven by individual repositories and resource providers choosing to implement the profiles on their own pages, coverage is uneven across sub-disciplines and institutions rather than universal — a research-data manager should treat “does our target community actually consume Bioschemas markup” as a question to confirm for their specific domain rather than assume.
Implementing Bioschemas: Practical Considerations for Research Data Managers
- Start with the profile that matches your resource, not the whole specification. A repository exposing datasets only needs the Dataset and DataCatalog profiles; a tool registry needs ComputationalTool; a training portal needs Course/CourseInstance/TrainingMaterial. Implementing the full profile catalogue speculatively is rarely necessary.
- Check profile maturity before building against it. Release-status profiles are considered stable for production implementation; in-development/draft profiles may change. Confirm current status at bioschemas.org before committing engineering effort.
- Markup lives on the page, not in a separate deposit file. Unlike RO-Crate’s
ro-crate-metadata.json, Bioschemas markup is typically embedded as JSON-LD directly in the HTML of the resource’s own web page (or via microdata/RDFa, though JSON-LD is the pattern the community documents and recommends), which is what makes it consumable by web-scale search-engine crawlers. - It complements, rather than replaces, a repository’s existing metadata schema. A repository already exposing DataCite, Dublin Core, or a domain-specific schema for its own catalogue or API can add Bioschemas markup to its public-facing pages specifically to improve search-engine and aggregator discoverability, without changing its internal or API-level metadata model. See CASRAI’s guide on choosing a metadata schema for a dataset for how Bioschemas fits alongside repository-level schema choices, and the FAIR checklist for the broader compliance picture.
- Governance is community-based, not a formal standards body. Bioschemas specifications are developed openly on GitHub by the Bioschemas community, with ELIXIR support (including funding through ELIXIR-EXCELERATE and ELIXIR Implementation Studies); it is not an ISO or W3C Recommendation, though its foundation (schema.org, JSON-LD) draws on W3C-adjacent web standards.
Frequently Asked Questions
Is Bioschemas the same thing as schema.org?
No. Schema.org is the general, cross-domain vocabulary. Bioschemas is a community layer on top of it: some new types proposed to and accepted into schema.org itself (Gene, Protein, Taxon, and related terms), plus usage profiles that specify which schema.org properties to use, and how, for specific life-science resource types. A page can use plain schema.org markup without following any Bioschemas profile; Bioschemas exists specifically to make life-science markup consistent across independent implementers.
Does using Bioschemas markup guarantee my dataset is FAIR?
No. Bioschemas markup directly supports the Findable criterion of FAIR by making a resource’s description machine-readable and search-engine-indexable. Accessibility, interoperability, and reusability still depend on other factors — access protocols, licensing, controlled vocabularies, and documentation — that Bioschemas markup alone does not provide.
Do I need to choose between Bioschemas and RO-Crate?
Not necessarily. They address different layers of the same problem: Bioschemas is about making a resource’s own web page discoverable via search engines; RO-Crate is about packaging a composite research output (dataset, workflow, software) with self-contained metadata for deposit or transfer. A life-science research object could reasonably use both, since both build on schema.org/JSON-LD.
Who maintains the Bioschemas specifications?
Bioschemas is developed as an open community initiative, active since November 2015, with representatives from a range of life-science institutions, and is a flagship policy of ELIXIR, the European life-sciences infrastructure organisation. Specification development and profile governance happen openly on GitHub rather than through a formal standards body such as ISO or W3C.
Where can I find the current list of Bioschemas profiles?
The authoritative, current list — including each profile’s maturity status (Release, In Development, or Deprecated) and its full property specification — is maintained at bioschemas.org/profiles. Profile status and properties are revised as the specification matures, so implementers should check there directly rather than relying on a snapshot cited in secondary material, including this guide.
