Docs/Packages

schema-org

The pinned, complete schema.org vocabulary with full inheritance and provenance — the source of truth for what could describe any entity.

@0xintuition/schema-org answers the first question in the data model — what exists? It is the pinned, complete schema.org vocabulary, shipped as a package: every type, every property, and the full inheritance graph connecting them. It is the foundation layer; it depends on nothing, and everything above it points back into it.

schema.org tells us what exists. Intuition decides what it recommends. This package is the "what exists" half — the superset that classifications and predicates curate from.

Every field knows where it came from#

schema.org types inherit: Book inherits from CreativeWork, which inherits from Thing. Because the package knows the inheritance graph, getPropertiesFor answers not just which properties a type has, but where each one was defined — every property is tagged with its originType:

properties-for.ts
import { getPropertiesFor } from "@0xintuition/schema-org";

// schema.org says Book inherits from CreativeWork and Thing.
// So one call resolves the full property set, each tagged
// with the type it actually came from.
const props = getPropertiesFor("Book");

props.find((p) => p.name === "name").originType;   // "Thing"
props.find((p) => p.name === "author").originType; // "CreativeWork"
props.find((p) => p.name === "isbn").originType;   // "Book"

That provenance is what keeps the layers above honest. When a classification recommends the name field for its book type, it isn't claiming name belongs to Book — provenance still comes from here, and it says Thing.

The superset, not the surface#

A full type resolves to a large set of inherited properties — for Book, far more than any builder needs by default:

superset.ts
import { getPropertiesFor } from "@0xintuition/schema-org";

const available = getPropertiesFor("Book");
// name · author · isbn · sameAs · bookEdition · numberOfPages
// · genre · datePublished · publisher · … (the full inherited set)

That breadth is the point. It is the menu Intuition curates from, and the source of truth that keeps the curation honest. Builders see the curated columns — the four recommended fields of the book classification, say — while the full vocabulary stays available as the escape hatch when a curated shape isn't enough.

The validation source#

Nothing downstream copies this package's property model. Classifications reference schema.org properties by name; a build-time validator confirms every referenced type and property actually resolves against this package. Define once, point to it — nothing is duplicated, so nothing can drift.

The dependency graph stays one-directional and acyclic:

code
schema-org ──▶ classifications.fields
                 (atom data, via property-name references)

schema-org ──▶ predicates ──▶ classifications.metadataPredicates
                 (triples, via predicate references)

// schema-org depends on nothing.

Pinned on purpose. schema.org evolves upstream; this package pins a complete snapshot so that validation, provenance, and the shapes derived from them are reproducible. schema.org can inform which predicates Intuition adds, but it never auto-creates them — promotion is a deliberate act (see predicates).

When you'd reach for it#

Most builders never import this package directly — the curated path through classifications and @0xintuition/primitives builders covers the default cases. Reach for schema-org when you need the full property set for a type, when you're proposing a new classification or predicate and want to ground it in the vocabulary, or when you're building tooling that validates shapes against the source of truth.