What is the purpose of schema.org?
Extract from https://schema.org/docs/faq.html
Schema.org is a joint effort, in the spirit of sitemaps.org, to improve the web by creating a structured data markup schema supported by major search engines. On-page markup helps search engines understand the information on web pages and provide richer search results. A shared markup vocabulary makes easier for webmasters to decide on a markup schema and get the maximum benefit for their efforts. Search engines want to make it easier for people to find relevant information on the web. Markup can also enable new tools and applications that make use of the structure. - Extract from
Current version of Schema.Org
Schema.org version 29.3, released 4th of September 2025, has been transformed to markdown files with YAML-LD frontmatter for editing with Obsidian and publishing with Quartz. (see https://schema.org/docs/releases.html)
A collaborative community activity
Extract from https://schema.org/
Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond.
As of 2024, over 45 million web domains markup their web pages with over 450 billion Schema.org objects. Many applications from Google, Microsoft, Pinterest, Yandex and others already use these vocabularies to power rich, extensible experiences.
Founded by Google, Microsoft, Yahoo and Yandex, Schema.org vocabularies are developed by an open community process, using the public-schemaorg@w3.org mailing list and through GitHub.
Data model
Organization of Schemas
Extract from https://schema.org/docs/schemas.html
The schemas are a set of ‘types’, each associated with a set of properties. The types are arranged in a hierarchy. The vocabulary currently consists of:
- 827 Types
- 1528 Properties
- 14 Datatypes
- 94 Enumerations
- 522 Enumeration members.
Architecture
Extract from https://schema.org/docs/datamodel.html
The data model used is very generic and derived from RDF Schema (which in turn was derived from CycL, see History section for details …).
- We have a set of types, arranged in a multiple inheritance hierarchy where each type may be a sub-class of multiple types.
- We have a set of properties:
- each property may have one or more types as its domains. The property may be used for instances of any of these types.
- each property may have one or more types as its ranges. The value(s) of the property should be instances of at least one of these types.
The decision to allow multiple domains and ranges was purely pragmatic. While the computational properties of systems with a single domain and range are easier to understand, in practice, this forces the creation of a lot of artificial types, which are there purely to act as the domain/range of some properties.
Like many other systems, the schema presented here can be extended (with a few types like Class and Property and a few properties like domainIncludes and rangeIncludes) to allow for reflection, i.e., for the schema to be represented in terms of itself. (see schema.org section: meta)
The canonical machine representation of schema.org is in RDF/Turtle. See the “developers” page for more information on machine-readable views of schema.org.
The type hierarchy presented on this site is not intended to be a ‘global ontology’ of the world. When founded in 2011 it was strictly focused around the types of entities for which the project’s founders (Microsoft, Yahoo!, Google and Yandex), could reasonably expect to provide some special treatment for via search engines. As the project has evolved, introducing more community collaboration and extension mechanisms, its scope has expanded gradually. However it is still the case that schema.org is not intended as a universal ontology. We expect it to be used alongside other vocabulary that shares our basic datamodel and our use of underlying standards like JSON-LD, Microdata and RDFa.
Data and Datasets overview
Extract from https://schema.org/docs/data-and-datasets.html
Schema.org as a project, and as a collection of terms, is entirely devoted to data. In other words, it always provides, characterises, describes, or encodes some form of data. Schema.org defines particular types such as Event, NewsArticle, Review, Person, as well as properties that characterize and interlink instances of these types. For example, the alumni property links people with educational organizations. The alumni property exists to provide information about people being alumni of organizations; Volcano exists to provide information about volcanoes, and so on.
Enumerations
With schema.org we aim to find a balance, by providing a core schema that covers lots of situations, alongside extension mechanisms for extra detail. There are many situations where the use of existing controlled vocabularies, standards and datasets would improve schema.org markup. This is the role of the schema.org “external enumerations” mechanism.
We introduce “external enumerations” with a simple example – countries – and encourage implementors to join the schema.org community in W3C’s ‘Web Schemas‘ group where the full details are being discussed.
Each schema.org type (such as Person, PostalAddress) is associated with a set of properties, such as “nationality”, “addressCountry”. In turn, each property has one or more expected types; in this case, both the “nationality” of a Person, and the “addressCountry” of a PostalAddress expect to have a Country value. Rather than adding large lists of specific countries to schema.org, instead we encourage the use of external lists. We will publish a set of well-known authority lists, linked to the types and properties they are used with. To get started, we take simple Wikipedia links as an example of such an authority. Other more specialist examples (such as IPTC codes) will follow.
Extension Mechanisms
Extract from https://schema.org/docs/extension.html
Over the years, we have experimented with a couple of different extension mechanisms (see 2011-2014 and 2014-2018 docs for details).
The primary motivation behind these models was to enable decentralized extension of the vocabulary. However, we have come to realize that for adoption, we need a simpler model, where publishers can be sure that a piece of vocabulary is indeed part of Schema.org. Until April 2019, we relied primarily on the ‘hosted extensions’ mechanism that used hosted subdomains of schema.org (such as bib.schema.org for the bibliography extension and autos.schema.org for the autos extension). Going forward, the content of these hosted extensions are being folded into schema.org, although each will retain an “entry point” page as before.
External extensions, where a third party might want to host a broadly applicable extension themselves (e.g., http://gs1.org/voc) will continue as before.
Types of Extensions
Extract from https://schema.org/docs/old_extension_2015.html
There are two kinds of extensions: reviewed/hosted extensions and external extensions. Both kinds of extensions typically add subclasses and properties to the core. Properties may be added to existing and/or new classes. More generally, they are an overlay on top of the core, and so they may add domains/ranges, superclasses, etc. as well. Extensions have to be consistent with the core schema.org. Every item in the core (i.e., https://schema.org/) is also in every extension. Extensions might overlap with each other in concepts (e.g., two extensions defining terms for financial institutions, one calling it FinancialBank and other calling it FinancialInstitution), but we should not have the same term being reused to mean something completely different (e.g., we should not have two extensions, one using Bank to mean river bank and the other using Bank to mean financial institution).