Schema.org

Schema.org types are organized in a multi-level hierarchy where more specific types inherit properties from broader parent types. For example:

• Thing (the root type with name, description, url)
• → CreativeWork (adds author, datePublished, publisher)
• → → Article (adds articleBody, wordCount)
• → → → NewsArticle (adds dateline, printPage)

This inheritance model allows parsers to understand that a NewsArticle is always a valid CreativeWork, enabling semantic reasoning across granularity levels without redundant markup.

Schema.org is syntax-agnostic, supporting three W3C-recommended serialization formats for embedding structured data in HTML:

• JSON-LD: A JavaScript object notation injected into <script type="application/ld+json"> tags, isolated from the visual DOM. This is Google's preferred format.
• Microdata: HTML5 attributes (itemscope, itemprop, itemtype) woven directly into existing markup tags.
• RDFa: Attribute-based syntax that extends HTML5 to express rich metadata using terms from multiple vocabularies simultaneously.

This flexibility allows developers to choose the format that best fits their rendering architecture without changing the underlying semantic model.

Unlike keyword-based metadata, Schema.org models real-world entities and their relationships. An organization is not just a string—it is a structured node with:

• Identifiers: @id for URI-based disambiguation, sameAs for linking to Wikidata or Wikipedia entries
• Attributes: legalName, taxID, foundingDate, numberOfEmployees
• Relationships: parentOrganization, subOrganization, member, alumni

This entity-first design enables search engines to perform entity reconciliation across disparate web pages, merging mentions of the same corporation into a unified knowledge graph node.

Schema.org provides hosted extensions for specialized industries that require vocabulary beyond the core specification. These extensions are reviewed and hosted on schema.org but remain separate namespaces:

• bib.schema.org: Bibliographic extensions for academic citations
• auto.schema.org: Automotive-specific properties like vehicleEngine, mileageFromOdometer
• health-lifesci.schema.org: Medical and life science types including Drug, MedicalCondition, ImagingTest

Extensions prevent vocabulary bloat in the core while allowing deep domain modeling. Implementers reference them via the @context property in JSON-LD.

Beyond static entity description, Schema.org defines an Action sub-hierarchy that models potential interactions. Types like OrderAction, ReserveAction, and ListenAction describe verbs that users can perform on entities. When combined with the potentialAction property, this enables:

• Email markup: Gmail parses FlightReservation and EventReservation to surface interactive cards
• Voice assistant triggers: Google Assistant uses Action types to understand executable intents
• Rich result interactivity: Search result snippets with direct booking or ordering capabilities

This transforms structured data from passive description to active capability declaration.

The process of mapping ambiguous text mentions to canonical identifiers in a knowledge base. Schema.org markup provides the @id and sameAs properties to explicitly declare entity identity.

• sameAs: Links a local entity to its Wikidata or DBpedia URI
• Disambiguation: Prevents merging distinct entities (e.g., "Washington" the city vs. the person)
• Critical for: Building a Golden Record across systems

Schema.org provides a hierarchical type system (Thing > Organization > LocalBusiness). Aligning your internal taxonomies to this structure enables interoperability.

• Subclassing: Corporation is a subtype of Organization
• Domain-specific extensions: Schema.org supports hosted and external extensions
• Ontology alignment: Mapping your proprietary categories to Schema.org types bridges internal and external semantics

Schema.org markup is the ingestion layer for building enterprise knowledge graphs. Crawlers parse structured data to populate graph databases with entities and their relationships.

• Nodes: Entities defined by @type (Person, Product, Event)
• Edges: Properties linking entities (author, manufacturer, location)
• Output: A queryable graph supporting SPARQL or Cypher queries for semantic search and reasoning