As the page title suggests, this is a confusing subject as terminology differs across modeling frameworks; so do the underlying concepts. Here we limit the comparison to the frameworks known to be used by CDM members, or likely candidates.

EXPRESS is a powerful data modeling language, widely used in engineering and manufacturing (notably STEP/ISO 10303 standards). Its constraint capabilities include:

• Simple Types and Multiplicities: EXPRESS supports basic types (INTEGER, REAL, STRING, etc.) and allows specifying multiplicities (e.g., cardinality constraints on sets/lists).
• References and Subtypes: EXPRESS can define entities and relationships, including constraints on referenced entities and their subtypes. It supports subtype constraints, allowing you to restrict which subtypes are valid in a given context. Multiple subtype constraints can be applied to a supertype, and these are additive, allowing fine-grained control over inheritance and references.
• Complex Constraints: EXPRESS supports assertions, WHERE rules, and derived attributes, enabling the expression of complex business rules and inter-entity constraints, far beyond what is possible in most schema languages.

JSON Schema is widely used for validating JSON documents. Its constraint capabilities include:

• Simple Types and Multiplicities: JSON Schema can express constraints on simple types (string, number, boolean, etc.) and multiplicities (e.g., minItems, maxItems for arrays).
• References: JSON Schema allows referencing other schemas using $ref. You can base a new schema on a referenced type and further constrain its properties locally (e.g., add a minimum to a referenced numeric property). However, JSON Schema does not provide a direct way to constrain the type of the referenced object beyond what is specified in the referenced schema. The referenced schema defines the type, and you can only add further constraints in the referencing schema.
• Subtype Constraints: JSON Schema supports constructs like oneOf, anyOf, and allOf to combine schemas, but does not natively support subtype hierarchies or explicit subtype constraints as in EXPRESS. Advanced polymorphism is possible but less expressive and more verbose than in EXPRESS.
• Limitations: JSON Schema references are typically resolved at the schema level, and constraining the “type” of a referenced object is usually done by referencing a schema that already defines the desired constraints. There are also some known limitations in certain implementations regarding how references are resolved.

TypeSpec is a newer, code-like schema language designed for describing APIs and data models, with features inspired by TypeScript (a superset of JavaScript including static typing):

• Simple Types and Multiplicities: TypeSpec supports basic types and allows modeling arrays, optionals, and required properties, similar to JSON Schema.
• References and Extensibility: TypeSpec allows referencing and extending models. You can use templates and the extends keyword to impose constraints on template parameters, including restricting them to specific types or models.
• Subtype and Union Constraints: TypeSpec can constrain union types to ensure all variants share a base type, and the extends clause can be used to document and enforce such relationships. However, this does not imply subclassing but rather enforces that all union members conform to a base type.
• Decorators and Custom Constraints: TypeSpec uses decorators to add custom constraints and metadata, which can be leveraged by emitters (e.g., to generate JSON Schema or OpenAPI definitions with specific constraints).
• Polymorphism: While TypeSpec can express some polymorphic relationships (especially for API specs), its expressiveness for complex subtype constraints is currently less than EXPRESS but more structured and maintainable than JSON Schema.

OWL2 provides the strongest expressiveness for semantic constraints but is fundamentally distinct from data-shaping languages like JSON Schema or TypeSpec.

1. Ontological Reasoning: OWL2 excels at expressing semantic constraints (e.g., “Parent is the inverse of hasChild”), enabling automated inference of new facts from existing data. This contrasts with JSON Schema’s syntactic validation.
2. Constraint Mapping Challenges: While JSON Schema constraints (e.g., minLength, maximum) can be translated to OWL2 using datatype facets (e.g., xsd:minLength), complex inter-property rules require custom OWL property chains or SWRL rules.
3. Validation vs. Inference: OWL2 reasoners (e.g., Pellet, HermiT) validate consistency of data against ontological rules rather than syntactic correctness. For example:

• A JSON "age": -5 fails in JSON Schema via "minimum": 0.
• In OWL2, it violates an xsd:nonNegativeInteger range restriction, triggering inconsistency.

Feature	EXPRESS	JSON Schema	TypeSpec	OWL2
Simple type constraints	Yes	Yes	Yes	Yes (via xsd datatypes)1
Multiplicity/cardinality	Yes	Yes	Yes	Yes (via minCardinality, maxCardinality)
Reference constraints	Yes (rich)	Limited	Yes (templates)	Yes (via owl:ObjectProperty restrictions)
Subtype constraints	Yes (native)	Limited	Partial	Yes (via rdfs:subClassOf, owl:equivalentClass)
Complex business rules	Yes (WHERE, assertions)	No	Partial (decorators)	Yes (via property chains, class expressions)
Inter-property dependencies	Yes	Limited 2	Partial	Yes (via owl:propertyChainAxiom, owl:hasValue)
Polymorphism	Yes (subtypes)	Limited	Partial	Yes (via class unions, intersections)
Formal semantics	No	No	No	Yes (description logic)

¹ restrictions on xsd datatypes are fully supported by OWL2 Full, DL, and RL profiles.

² JSON Schema supports basic dependencies (e.g., dependencies keyword) but not value equality constraints without extensions.