Questions and answers on data modeling, schemas, governance, and interoperability.
Showing questions 301-400 of 1000
The minItems and maxItems keywords bound the length of an array, while uniqueItems enforces that no two elements are equal under JSON-level equality. Together they express common business rules such as tag lists with one to five unique values, ordered lists with at least one entry, or collections capped at a known maximum. All three are cheap to check and catch real bugs like duplicate tag submissions.
The type number keyword accepts any numeric value, including decimals, while type integer restricts the value to whole numbers. Integer validation is stricter and should be used whenever fractional values have no business meaning, such as counts, identifiers, or priorities. Note that JSON itself has only one numeric type, so integer validation is a schema-level constraint rather than a JSON-level distinction.
The propertyNames keyword applies a subschema to every property name in an object, allowing you to restrict key format — for example, requiring all keys to match a pattern, be within a length range, or avoid reserved words. This is useful for maps with dynamic keys such as localized labels or configuration dictionaries, where the shape of the key itself matters.
In earlier drafts, dependencies combined two features: making certain properties required when another was present, and applying additional schemas conditionally. Draft 2019-09 split these into dependentRequired, a clearer property-to-required-list mapping, and dependentSchemas, for conditional subschemas. The split improves readability and tooling support significantly.
JSON Schema handles nullability through the explicit null type. A nullable field is typically declared with type as an array like string plus null, or in newer drafts by composing with anyOf. Unlike some programming languages, JSON Schema does not have a separate nullable keyword; null is a first-class JSON value that must be explicitly permitted.
Typical patterns include missing required fields, type mismatches, values outside minimum or maximum bounds, patterns that fail to match, additional properties in strict objects, and composition failures where one branch of allOf or oneOf fails. Good validator libraries surface the instance path and the failing keyword so errors are actionable rather than cryptic.
Each draft adds expressiveness and refines semantics. Draft-07 is widely deployed and feature-complete for most use cases; 2019-09 introduced $defs, dependentRequired, and unevaluatedProperties; 2020-12 improved $dynamicRef and tuple validation via prefixItems. The main trade-off is tool support: newer drafts have richer features but slightly fewer mature validators across all languages.
Migrate when you need features only the newer draft provides, when your tooling fully supports the target draft, or when your schema registry mandates it. Do not migrate casually; the benefits are real but the blast radius spans every consumer. A well-planned migration with parallel validation is the safe path.
CoreModels parses the JSON Schema and converts each object type into a Type node, each property into an Element, and each enum or constrained list into a Taxonomy. Validation rules become Mixins attached to the relevant nodes, combination keywords become rules in the Rule Builder, and $ref links resolve into graph relations — preserving the semantic structure for visual editing.
CoreModels serializes the graph back into JSON Schema by mapping Types to object schemas, Elements to properties, Taxonomies to enums, Relations to nested or referenced structures, and Mixin-based rules to the corresponding JSON Schema keywords. The Rule Builder preserves complex combinations and conditionals so round-tripping does not drop expressiveness.
The $ref keyword references another subschema by URI, either within the same document or across documents. It enables reuse by letting you define a shape once — for example, an Address schema — and refer to it from every Type that needs one. Without $ref, schemas quickly devolve into copy-paste duplication that is hard to keep consistent.
Circular references are valid in JSON Schema and necessary for recursive structures like trees, but they can trip up tooling that tries to fully expand every reference. Avoid accidental cycles by carefully scoping what you reference, and handle intentional ones by using validators that support lazy resolution. CoreModels' graph model handles recursion natively.
The $ref keyword resolves statically at schema definition time, always pointing at the same target. The $dynamicRef keyword, introduced in 2020-12, resolves dynamically based on the nearest enclosing $dynamicAnchor, letting downstream schemas override what a reference points to. It enables extensible base schemas where descendants can plug in their own specialized shapes.
The $defs keyword holds a map of named subschemas that are referenced from elsewhere in the same document via $ref. It replaces the older definitions keyword and is the recommended place for shared fragments — address shapes, identifiers, common enums. Putting reused structures in $defs keeps the main schema readable and makes reuse explicit.
The allOf keyword requires an instance to satisfy every schema in its list simultaneously. It is useful for composition — adding constraints on top of a base schema, or requiring a value to match multiple independent rules. A common pattern is allOf with a base reference plus local additions, which mimics inheritance and lets you extend shared shapes.
Use anyOf when an instance must match at least one schema, where multiple matches are fine. Use oneOf when an instance must match exactly one schema, where multiple matches are a validation error. anyOf is more permissive and faster to validate; oneOf enforces mutual exclusivity, which is important for discriminated unions.
In practice, anyOf permits overlapping schemas — a value might be both a number and an integer, and both matches are fine. oneOf forbids overlaps and is the correct choice when variants should be mutually exclusive, like a PaymentMethod that is either credit card, bank transfer, or wallet but never two at once. Using oneOf where anyOf is intended causes false-negative validation.
The not keyword requires the instance to fail validation against the given schema. It is useful for expressing exclusions — a product name must not be empty, a status must not be one of a reserved list, a nested object must not have a particular key. The not keyword composes with allOf to express common constraints like required-and-not-empty.
If the instance matches the if schema, the then schema must also apply; otherwise the else schema applies if provided. This enables conditional structures such as requiring additional fields when a type discriminator has a certain value. Used carefully, if/then/else makes schemas much more expressive without sacrificing readability.
Common patterns include a typed discriminator field combined with oneOf or if/then/else, where each branch requires a specific discriminator value, or allOf with a base schema plus type-specific additions. Always pair discriminator values with the full set of constraints that distinguish each variant so validators can produce clear error messages.
Define a discriminator field with a const or enum value for each variant, and use oneOf where each branch requires the specific discriminator value plus that variant's additional constraints. This produces clean validation, clear error messages, and tools like OpenAPI can use it to generate typed client code. CoreModels' Rule Builder assembles this pattern visually.
The unevaluatedProperties keyword, introduced in 2019-09, applies after all composition keywords like allOf, anyOf, and $ref have contributed their own property validations. additionalProperties applies only within the immediate schema and misses properties contributed by composed schemas. unevaluatedProperties solves the long-standing problem of strict property validation across inheritance chains.
The unevaluatedItems keyword is the array counterpart of unevaluatedProperties: it applies to array items not already validated by prefixItems, items, or composed schemas. It lets you extend tuple-like structures while keeping strict validation on trailing items, which was very difficult to express cleanly in earlier drafts.
The patternProperties keyword applies a subschema to all properties whose names match a regex. Use it for maps with key patterns such as locale codes or typed prefixes. Pitfalls include overlapping patterns producing ambiguous validation and combining patternProperties with additionalProperties in confusing ways — always document the intent and test with concrete examples.
The contains keyword requires at least one array item to match the given subschema; minContains and maxContains bound how many items must match. Together they express rules like an array must contain between one and three items of a given type, which is cleaner than trying to express it with filtering plus length constraints.
The prefixItems keyword, added in 2020-12, validates array items positionally — the first against the first subschema, the second against the second, and so on. It replaces the older tuple form of items and is the correct way to validate fixed-structure arrays like coordinate pairs, color tuples, or argument lists. Items beyond prefixItems are governed by items or unevaluatedItems.
Combine a properties map of known keys with additionalProperties as either true or a looser schema that constrains shape without listing names. This lets consumers add custom metadata while core fields remain validated. For strict cases, use unevaluatedProperties after composition to catch typos in shared field sets.
When you compose a base schema via allOf and then set additionalProperties to false in the outer schema, the base schema's properties are treated as additional because additionalProperties only sees the outer schema's own properties. Properties defined in the base will be rejected. The fix is unevaluatedProperties set to false, which correctly respects composition.
Annotations are not overridden by composition — each contributing schema can attach its own annotations, and validators collect them all. Documentation tooling typically merges or displays them with provenance. This means a composed schema can inherit and add to parent descriptions without losing information, but you need to curate what consumers see.
The 2020-12 draft formalizes the vocabulary mechanism: a meta-schema can declare which vocabularies it uses, and validators can advertise which vocabularies they support. This lets organizations define custom keywords for their domain while remaining standards-compliant. It is the future-proof extension path for JSON Schema.
Maintain one authoritative schema, and compose strictness layers via allOf — a base with core rules plus an environment-specific overlay that tightens or loosens constraints. Alternatively, configure validators to run in different modes. Avoid forking the schema: divergent schemas drift and mislead consumers about what is truly required.
Coerce during parsing before validating, or validate the string form with pattern and format keywords and coerce after. Coercing before validation is cleaner but requires discipline at every entry point. For domains like dates, numbers-as-strings, and booleans-as-strings, explicit parsing plus strict schema validation catches bugs that lenient coercion would hide.
The Rule Builder exposes allOf, anyOf, oneOf, not, if/then/else, and nested combinations through a visual interface, so modelers can construct complex conditional rules without writing JSON Schema by hand. Rules are stored as structured data on the relevant Types or Elements and serialize cleanly to the corresponding JSON Schema keywords on export.
Each combination keyword becomes a rule node in the graph attached to the Type or Element it constrains, with child rules representing the branches. Semantics are preserved exactly: the graph structure matches the schema's logical structure, so import-export round-trips produce equivalent JSON Schema output.
CoreModels resolves $ref links during import, creating graph relations that correspond to the reference structure. External references become links to imported nodes; internal references to $defs become connections to shared Element or Type nodes. The result is a fully connected graph where the reference semantics are preserved but expressed as first-class relations.
Validate with a tool that reports the full validation path and failing keyword, isolate the failing subschema by testing each branch independently, provide concrete positive and negative examples, and simplify the schema until the failure point is obvious. Visual tools like CoreModels' Rule Builder make the logic easier to trace than raw JSON.
Maintain a test suite pairing each schema with fixtures — one set expected to validate, one set expected to fail. Run the suite in CI on every change, include edge cases and boundary values, and treat a broken fixture as a breaking schema change until proven otherwise. Good coverage turns the schema into a self-documenting specification.
Extract reused shapes into $defs, name subschemas intentionally, add title and description on non-obvious keywords, break large files into per-domain modules, and prefer composition over deeply nested inline definitions. When raw JSON Schema becomes hard to read, visual tools like CoreModels pay for themselves quickly.
Use stable $id URIs, publish shared fragments as versioned artifacts, lock consumers to specific versions, and use a schema registry or monorepo for cross-team sharing. Document which schemas depend on which, automate compatibility checks in CI, and plan changes with cross-team impact analysis.
CoreModels preserves every imported construct as first-class graph data: Types, Elements, Taxonomies, Relations, Mixins, and Rule Builder rules all map back to their JSON Schema equivalents on export. Combination keywords, conditional rules, references, and annotations all survive round-trip, which is the baseline requirement for a trustworthy modeling platform.
JSON-LD is JSON extended with an @context that maps short local terms to globally unique identifiers (IRIs), turning an ordinary JSON document into linked data. The key difference is semantic interoperability: two JSON-LD documents from different systems can be merged, queried, and understood by any consumer that knows the shared context.
The @context maps short property names to their full IRIs, declares datatypes for values, and establishes shortcuts for commonly used vocabularies. It is what transforms a local JSON document into a portable piece of linked data, because every term becomes unambiguous in the global web of data.
The @id provides the globally unique identifier, typically an IRI, for a node in the graph; @type declares what kind of thing the node is, often mapping to schema.org or a custom ontology class; @graph bundles multiple nodes into a single document. Together they turn JSON into addressable, typed linked data.
JSON-LD is a serialization format for RDF. Every JSON-LD document can be expanded into RDF triples, where each subject, predicate, and object triple describes a single fact. This relationship lets JSON-LD participate in the broader Semantic Web ecosystem — SPARQL queries, OWL reasoning, and triple stores all work with JSON-LD data after expansion.
A default graph contains triples with no explicit graph label; a named graph is a set of triples identified by an IRI, allowing you to attach metadata to the graph itself — when it was produced, by whom, under what license. Named graphs are essential for provenance, versioning, and federated data across sources.
Schema.org provides a massive shared vocabulary — classes like Article, Product, Event, Recipe — that JSON-LD documents reference through the @context. Search engines and AI assistants extract schema.org-marked JSON-LD to understand entity types, relationships, and properties, enabling rich results and accurate knowledge-graph population.
An IRI (Internationalized Resource Identifier) is a URL-like identifier that can include non-ASCII characters, used to name everything in RDF — classes, properties, instances. JSON-LD encourages IRIs because they make every term unambiguous across systems; two documents using the same IRI truly mean the same thing, which local string names can never guarantee.
Define each local term in the @context as a key pointing to its full IRI, for example mapping name to http://schema.org/name. You can also declare datatypes, container types like lists, sets, or language-tagged values, and term abbreviations. A well-designed @context lets authors write natural-looking JSON while producers and consumers still share precise semantics.
Because every node has an IRI, JSON-LD documents can reference nodes in other documents by IRI, creating a web of linked data. Dereferencing an IRI can fetch the remote description, enabling federated queries, entity resolution, and knowledge graphs that span organizational boundaries. This is the core idea behind the Linked Data movement.
RDF (Resource Description Framework) models information as triples of subject, predicate, and object. Subjects and predicates are IRIs; objects are IRIs or literal values. A collection of triples forms a directed graph where nodes are resources and edges are predicates, and that graph is the foundational data model for semantic web applications.
RDFS (RDF Schema) adds basic vocabulary for describing classes, properties, and their hierarchies such as subClassOf, subPropertyOf, domain, and range. OWL (Web Ontology Language) adds far richer constructs — cardinalities, equivalences, inverse properties, disjointness, and formal reasoning. Together they let you define ontologies that go beyond pure data description into knowledge representation.
Practical uses include SEO through schema.org markup, structured data for AI assistants, content interoperability between systems, knowledge graph construction, data publishing through dataset catalogs like DCAT, and API payloads that need to be meaningful outside any particular application context.
Embedding JSON-LD in web pages lets search engines extract entities, relationships, and facts explicitly — article authors, product prices, event dates, FAQ question-answer pairs. This structured data powers rich results, featured snippets, and AI search citations far more reliably than prose inference. Most modern SEO strategies include JSON-LD as a first-class deliverable.
Expanded form resolves every term to its full IRI — maximally explicit and machine-friendly. Compacted form applies an @context to shorten terms — maximally human-friendly. Framed form reshapes linked data into a specific nested JSON structure the consumer wants. Tools convert between forms losslessly, letting authors and consumers each work in their preferred shape.
Framing applies a template to a JSON-LD graph, producing nested output that matches the consumer's desired shape. This is powerful for consumers of federated data — they can reshape messy inputs into their expected structure without asking publishers to change format. It turns JSON-LD from a publishing format into a consumption format as well.
A controlled vocabulary is a formal, curated set of terms for classifying or describing things, such as schema.org, Dublin Core, or FOAF. JSON-LD references one through @context mappings or prefix declarations, so local terms resolve to vocabulary-specific IRIs. This is how a document can declare its author field as FOAF's maker property or Dublin Core's creator.
Datatypes can be declared per property in the @context or inline on values using @value and @type together. Common XSD datatypes — xsd:string, xsd:integer, xsd:dateTime — are recognized by RDF tooling. Explicit datatyping prevents ambiguity when, say, a numeric value needs to be treated as a decimal rather than an integer.
The rdfs:subClassOf predicate declares that one class is a specialization of another — a ScientificArticle is a subClassOf Article. The rdfs:subPropertyOf predicate declares that one property is a specialization of another. These hierarchies power inference: anything declared as a ScientificArticle is automatically recognized as an Article by reasoners, without duplicating data.
SKOS (Simple Knowledge Organization System) is an RDF vocabulary for representing taxonomies, thesauri, and controlled vocabularies. It provides concepts, hierarchies through broader and narrower, alternative labels, and mappings across vocabularies. In CoreModels, Taxonomies export cleanly to SKOS for interoperability with other semantic systems.
SHACL (Shapes Constraint Language) defines shapes — structural and value constraints that RDF data must satisfy. It brings JSON Schema-style validation to the semantic web, letting you enforce that every Person has a name, that publication dates are valid dates, and so on. SHACL and JSON Schema solve similar problems in their respective ecosystems.
Turtle and N-Triples are RDF-native text formats optimized for triple-store use; JSON-LD is RDF that looks like everyday JSON, optimized for web and application developers. All three represent the same data model, and tools convert between them losslessly. Teams typically choose JSON-LD for API and content contexts, Turtle for ontology authoring.
Choose JSON-LD when semantic interoperability matters — linking data across organizations, participating in the open web of data, or feeding knowledge graphs. Choose JSON Schema when validation and structural contracts are primary. Many systems use both: JSON-LD for meaning, JSON Schema for validation. CoreModels supports both natively and can export to either from the same source model.
CoreModels parses the @context, mapping each term to its IRI; imports classes as Type nodes with their IRIs preserved; imports properties as Elements; imports SKOS concepts as Taxonomy terms; and establishes relations based on subClassOf, domain, and range declarations. The result is a graph that preserves the original semantic structure exactly.
CoreModels serializes Types, Elements, Taxonomies, and Relations into a JSON-LD document with a generated @context that maps local names to IRIs. Inheritance becomes subClassOf, references become typed relations, and Taxonomies export as SKOS concepts. The export is valid JSON-LD that any semantic web tool can consume directly.
AI agents benefit enormously from structured, typed data with explicit relationships — exactly what JSON-LD provides. When enterprise data is published as JSON-LD, agents can reason about entity types, follow relationships, and cite sources precisely. This is a major reason knowledge graphs and LLM grounding strategies are converging on JSON-LD and RDF-based representations.
Schema evolution is hard because schemas are contracts with many invisible consumers, each of which may have its own tolerance for change. Data produced under an old schema persists for years; code written against a previous version may still be deployed. Evolving a schema without breaking something requires careful policy, tooling, and coordination that most teams underestimate until something breaks.
Backward compatibility means that data produced under the new schema can still be consumed by clients expecting the old schema. Typical backward-compatible changes include adding optional fields, loosening constraints, or providing new enum values while keeping old ones. The old client ignores what it does not understand and keeps working.
Forward compatibility means old data can be consumed by new clients expecting the new schema. It is harder because new clients may require fields that old data does not have, or assume constraints that old data does not satisfy. Supporting forward compatibility usually requires the new schema to tolerate missing optional fields and to handle legacy values gracefully.
Full compatibility is both backward and forward compatibility — the schema can evolve in both directions without breaking anyone. It is required when you cannot coordinate producer and consumer deployment, as in widely deployed APIs, public event streams, or long-lived data stores. Full compatibility is the strictest discipline and limits the changes you can make.
Additive changes introduce new fields, new enum values, or new optional constraints without altering existing contracts — generally backward-compatible. Breaking changes rename, remove, retype, or tighten existing fields in ways that invalidate previously valid data or code. The former are safe with proper defaults; the latter require coordinated migration.
Common breaking changes include removing a required field, renaming a field without providing an alias, changing a field's type, tightening constraints such as a narrower enum or stricter pattern, removing an enum value, and changing additionalProperties from true to false. Each of these can invalidate data or code that previously worked fine.
Publish a clear changelog per version, flag breaking versus non-breaking changes, provide migration guides for breaking changes, maintain deprecation notices ahead of removals, and proactively notify known consumers. Schema changes communicated only through Git diffs surprise consumers and erode trust over time.
Semantic versioning uses MAJOR, MINOR, and PATCH numbers to signal compatibility: MAJOR changes break compatibility, MINOR changes add backward-compatible features, PATCH changes fix issues non-functionally. Applied to schemas, it sets clear expectations: consumers can upgrade within a MAJOR version without concern, and MAJOR bumps demand explicit attention and possibly a migration.
A schema registry stores versioned schemas, enforces compatibility policies at publish time, makes schemas discoverable by consumers, and often integrates with serialization formats like Avro, Protobuf, and JSON Schema. Popular registries include Confluent Schema Registry and Apicurio. The registry is the source of truth that keeps producers and consumers aligned.
Mark the field as deprecated in the schema annotation, continue populating it for a transition period, communicate the deprecation clearly with a timeline, provide a replacement field, and only remove after consumers have migrated. Skipping any of these steps turns a planned deprecation into a surprise break.
Inline markers travel with the schema and reach every consumer automatically; external release notes give more context but require consumers to read them. The best practice is both: inline deprecated annotations for machine readability, and release notes for human context. Neither alone is sufficient for professional schema stewardship.
Keep both old and new field names valid for a transition period, populate both on the producer side, declare the relationship in documentation, and schedule removal of the old name. Tools can often auto-map during reads via aliases. Hard renames without transition windows break consumers silently and erode trust in the schema.
Document the alias in the schema metadata as an x-alias annotation or equivalent, have the producer emit both names, and have validators accept either. Some schema registries support aliases natively. Planning the transition with a fixed end date prevents aliases from becoming permanent schema clutter.
Contract tests verify that producer and consumer agree on the schema at runtime, catching incompatible changes before deployment. They codify the assumption that a given producer satisfies a given consumer's needs as executable tests, preventing silent breakage when schemas evolve. Tools like Pact and native schema-registry compatibility checks make this routine.
Keep historical example payloads validated against the current schema in CI, deploy test consumers running previous code against new data, and include compatibility checks in the release pipeline. This catches regressions that schema-only compatibility checks miss, such as semantic shifts in enum values or tightened business rules.
Internal APIs can coordinate deployment across teams, so breaking changes are feasible with planning. External APIs have unknown consumers who cannot be coordinated, so schemas must evolve additively or through explicit versioning in the URL or content type. The cost of a breaking change scales with audience size, and external APIs almost always pay it fully.
Each format offers compatibility modes: Avro schemas embed evolution rules per field; Protobuf uses field numbers for backward compatibility on add and remove; JSON Schema relies on $ref, versioning, and registry tooling. Event-driven systems pair the format with a registry that enforces compatibility per topic, preventing incompatible producers or consumers from joining the conversation.
Compatibility modes (BACKWARD, FORWARD, FULL, and TRANSITIVE variants) define what changes are allowed between versions on a per-subject basis. The registry rejects incompatible schema updates at registration time, before they can reach production. Choosing the right mode per subject is a governance decision that reflects how the data will be consumed.
Version explicitly via URL or content type, run old and new versions in parallel for a transition period, publish clear migration guides, provide tooling to help consumers migrate, and set a firm end-of-life date for the old version. Breaking changes are expensive but survivable with transparent process; the damage comes from pretending they are optional.
A migration plan documents the motivation for the change, the scope of affected consumers, the sequence of producer and consumer updates, testing and rollback strategy, communication timeline, and success criteria. Good plans treat schema changes as a coordinated product launch, not a quiet commit.
Use a schema registry as the source of truth, enforce compatibility at publish time, version APIs clearly, run integration tests across service boundaries, and make schema ownership explicit. Services that depend on each other should consume from the registry rather than from hardcoded local copies, so updates propagate predictably.
CoreModels persists the full edit history, shows diffs between versions, attaches authorship and timestamps to every change, and supports rollback to any prior state. Combined with Git integration, this gives teams a complete audit trail and the ability to reason about when and why a schema changed.
CoreModels can synchronize its model with a Git repository, producing text-based representations like JSON Schema and JSON-LD that work with pull requests, code review, branching, and CI. Schema changes then flow through the same governance as code changes — review, approval, deployment, rollback — bringing schema evolution into standard software engineering practice.
Establish a shared registry or modeling platform, define ownership and approval paths per schema, run compatibility checks in CI, enforce style and naming standards, schedule cross-team reviews of canonical schemas, and periodically audit deployed schemas against the registry. Drift is prevented by making the right path easier than the wrong one.
Identify remaining consumers, communicate the retirement timeline well in advance, provide migration assistance, monitor usage and delay retirement if key consumers have not migrated, and only remove after confirmed migration. A hard retirement date enforced without grace is how a schema steward loses consumer trust, even when the technical change is justified.
Reusability reduces duplication, enforces consistency, and lowers the cost of change — a shared Element or Component updated once propagates everywhere it is used. Without reuse, every similar concept gets redefined slightly differently across the schema, causing drift, integration friction, and maintenance debt that compounds over time.
Inheritance establishes an is-a relationship where a specialized Type extends a more general one, inheriting its Elements and rules. Composition establishes a has-a relationship where a Type is built from reusable parts without implying specialization. Composition is usually more flexible; inheritance is more structural. Most robust models use both deliberately.
Inheritance is elegant when the is-a relationship is stable, the subclass genuinely extends rather than conflicts with the parent, and the hierarchy is shallow. It becomes fragile when business rules demand specializations that violate parent assumptions, when the hierarchy is deep, or when multiple inheritance produces ambiguity. At that point, composition often serves better.
Symptoms include deep hierarchies that no one can navigate, parent Types with fields only some subclasses need, constant refactoring of the tree to accommodate new cases, and subclasses that override rather than extend parent behavior. These signal that the model is treating inheritance as the default when composition would be cleaner.
SubClassOf is a built-in RelationGroup that links a specialized Type to its parent. The subclass inherits the parent's Elements and rules and can add its own. In the graph view, SubClassOf edges make hierarchies immediately visible, and tools like Neo Agent can reason about the inheritance chain when suggesting edits or generating schemas.
Composition in CoreModels is expressed by attaching the same Element to multiple Types through the domainIncludes RelationGroup. One Title Element, for instance, can belong to Article, Product, and Page without inheritance between those Types. This keeps the model flat and explicit while still eliminating duplication.
Deep chains centralize shared behavior but make individual Types harder to understand in isolation, complicate validation, and slow schema navigation. Changes to top-level Types ripple unpredictably through every descendant. Flatter hierarchies with more composition are usually easier to evolve; reserve deep inheritance for genuinely stable, tree-like domains.
Mixins attach reusable behavior, rules, or metadata to a Type or Element without requiring a hierarchical relationship. They provide the benefit of inheritance, which is shared behavior, without forcing the structural lock-step of a hierarchy. In CoreModels, Mixins let you apply validation, annotations, or custom rules broadly without forcing Types into an inheritance tree.
Promote a property to a reusable Element when it appears in multiple Types with the same name and meaning, has consistent validation rules, and changes together across contexts. Do not promote properties that happen to have the same name but different semantics; shared names with different meanings create worse problems than duplication.
Extract a Component when the same cluster of fields appears in multiple Types, has a name authors and developers would recognize like Byline, CallToAction, or ProductCard, and changes as a unit. If the cluster is only used once, or its parts evolve independently, keeping fields in the parent Type is simpler.