DDS or Define.JSON

How are the Define.JSON and the DDS related?

Intended purposes

TeMeta/define-json is the model/standard repository — it defines what Define-JSON (the Data Definition Specification) is. It positions Define-JSON as a data contract format covering both "demand" (what an analysis or transfer requires) and "supply" (what a provider promises to deliver), complementing USDM and Dataset-JSON. It's deliberately broader than regulatory Define-XML: the LinkML schema declares prefixes for FHIR, OMOP, SDMX, RDF Data Cube (qb), PROV-O, DCAT, and OpenStudyBuilder, framing itself as a "Rosetta Stone" across those ecosystems. The mixin architecture (Identifiable, Labelled, Governed) and concepts like ReifiedConcept, ConceptProperty, and nested ItemGroup "slices" for context-specific/value-level definitions are all defined here.

cdisc-org/data-definition-engine is the implementation/tooling repository — official 360i software (Define-XML Generation Project Team) that consumes the DDS model to produce study artifacts. Architecturally it's loaders + generators around the DDS JSON: the USDM loader (create_define_json.py) reads a USDM study design, pulls Biomedical Concepts and Dataset Specializations via the CDISC Library API, and populates DDS; the generator (define_generator.py, built on odmlib) turns that into Define-XML v2.1, with planned outputs including ODM CRFs, Dataset-JSON shells, and Trial Design datasets. It ships the LZZT pilot study as test data (USDM protocol JSON plus SDTM/ADaM metadata spreadsheets) and an alternative Excel-template loader to match how organizations manage metadata today.

Similarities

Beyond the shared schema, both include the Define-XML 2.1 stylesheet for HTML rendering, both are MIT-licensed Python, both are explicitly 360i deliverables, and both treat USDM as the upstream source of study design truth. There's clearly shared authorship/coordination — DDE is in the process of consolidating code currently spread across TeMeta/define-json, cdisc-org/360i, swhume/template2define, and Lex Jansen's POC repos.

Differences

• Standard vs. engine. TeMeta's repo is where the model evolves (schema, generated Pydantic classes, JSON Schema, MkDocs documentation site, versioning architecture). DDE is where the production pipeline lives (it copies the schema in rather than defining it).

• Scope of tooling. TeMeta includes bidirectional XML↔JSON conversion, round-trip validation, a data cube engine with SDMX support, and a "dataset deconstructor" that reverse-engineers Define-JSON metadata from Dataset-JSON data — experimental, semantic-web-leaning capabilities. DDE's tooling is narrower and submission-oriented: USDM → DDS → Define-XML 2.1, organized into a heavily modularized generator (separate modules for ItemGroups, ItemRefs, WhereClauses, ValueLevel, codelists, methods, comments, etc.) with pytest fixtures.

• VLM representation. DDE's loader notes a deliberate divergence: it organizes value-level metadata as "slices" within each ItemGroup rather than as separate child "DataSpecialization" ItemGroups — a sign the model is still being negotiated between the two efforts.

• Governance and maturity. DDE sits under cdisc-org with CONTRIBUTING/Code of Conduct and an "under development" badge, flagged as entering 360i Phase 2 (ADaM define.xml exploration ahead). TeMeta is a personal/incubator repo, but it's the more actively iterated of the two right now (last commit June 10, 2026 by Jeremy Teoh vs. May 28 by Lex Jansen), with a future home signposted at cdisc-org/DataExchange-DDS.

So the practical framing: if you want to understand or extend the Define-JSON model itself, TeMeta/define-json is the source of truth; if you want to run the 360i pipeline that generates a Define-XML from a USDM study, DDE is the tool — and expect the schema copies to converge once consolidation into DataExchange-DDS happens. Want me to drill into any specific area, like the slice-vs-DataSpecialization VLM divergence or how the DDE loader maps USDM SoA → BCs → DSS?