CEDAR Embeddable Editor (CEE) Overview

• CEDAR Embeddable Editor (CEE) is a lightweight, interoperable web component that dynamically renders metadata entry forms from machine-actionable JSON Schema templates.
• It integrates ontology-assisted and authority-backed value selections to produce semantically rich JSON-LD metadata, ensuring semantic consistency and reusability.
• CEE decouples template management and metadata storage from central infrastructure, enabling seamless integration into diverse host platforms.

Searching arXiv for the CEDAR Embeddable Editor and its foundational CEDAR Workbench paper. Searching arXiv for related CEDAR metadata-authoring papers. The CEDAR Embeddable Editor (CEE) is a lightweight, interoperable Web Component for embedding standards-based, ontology-linked metadata authoring and visualization directly into third-party research platforms. Within the broader CEDAR ecosystem, it extends the template-driven metadata model of the CEDAR Workbench into external workflows by dynamically rendering forms from machine-actionable templates and producing semantically rich metadata in JSON-LD format. Its design is centered on portable deployment, ontology-aware value entry, and host-platform control over template lifecycle and metadata storage rather than on a centralized authoring portal (O'Connor et al., 16 Jul 2025).

1. Origins and problem setting

CEE emerged from a long-running CEDAR effort to improve the authoring of metadata that describe scientific experiments. The earlier CEDAR Workbench was introduced as a suite of Web-based tools and REST APIs for constructing metadata templates, filling those templates to generate high-quality metadata, and sharing and managing these resources. That system provided ontology-assisted metadata authoring, JSON, JSON-LD, and RDF representations, and REST-based submission and validation pathways for external repositories (Gonçalves et al., 2019).

The immediate problem addressed by CEE is workflow separation. In the CEDAR model, metadata standards are encoded as machine-actionable metadata templates that specify structure, datatypes, requiredness, vocabulary bindings, and related constraints. Before CEE, metadata entry typically required moving from a repository or submission system into the CEDAR Workbench or the centralized CEDAR Metadata Editor. The 2025 CEE work identifies that separation as a source of friction that limited adoption and reframes the contribution as a new delivery model rather than a new metadata model: standards are authored once as CEDAR templates and then reused across multiple external systems under the slogan “author once, publish everywhere” (O'Connor et al., 16 Jul 2025).

This positioning is important because CEE is not an isolated form renderer. It inherits a model-driven approach developed in the Workbench, where templates can be assembled from reusable fields and elements, semantically annotated with ontology terms and properties, and used to generate browser-based metadata-entry forms. A plausible implication is that CEE should be understood as the externalization of capabilities that were already present in the CEDAR platform at the template and service layers, rather than as a complete break from the Workbench architecture (Gonçalves et al., 2019).

2. Component architecture and deployment model

CEE is implemented as a standards-compliant Web Component exposed through the custom HTML tag cedar-embeddable-editor. It is distributed as a framework-agnostic package via npm, has no external dependencies from the host perspective, and is designed to work across modern frontend environments including React, Angular, Vue, and plain or static HTML contexts. It may be embedded either directly in the DOM or within an iframe (O'Connor et al., 16 Jul 2025).

At minimum, the component expects a CEDAR metadata template in JSON Schema format together with a configuration object controlling language, display mode, and interface features. A host may also provide an existing metadata instance for editing or display. At runtime, the component interprets the template client-side, renders the corresponding form, validates input in real time, constructs a metadata instance conforming to the template, and exposes the completed result through its API for local storage, backend submission, CEDAR submission, or export (O'Connor et al., 16 Jul 2025).

A central architectural property is runtime decoupling from CEDAR’s live infrastructure. Templates are typically authored in CEDAR tooling, exported as standalone JSON Schema documents, and then stored and version-managed by the embedding platform. Metadata created through CEE are usually returned to the host application, stored by the host, and linked or indexed by the host. CEDAR does not store or archive metadata created through the CEE unless explicitly configured to do so. This places version control, backward compatibility policy, and persistence semantics under host-platform governance rather than under a shared CEDAR runtime (O'Connor et al., 16 Jul 2025).

The background for that deployment model is the Workbench’s modular service architecture. The 2019 Workbench paper describes a highly modular microservice-based architecture with loosely coupled services, a browser-based AngularJS front end, Java microservices implemented using Dropwizard, and REST services that provide full access to the CEDAR ecosystem. It explicitly states that the architecture is intended to let users employ individual services in their applications or workflows. CEE can therefore be situated as a packaged client-side realization of a modular, API-accessible platform that had already been designed for external integration (Gonçalves et al., 2019).

3. Template model, rendering behavior, and validation

CEE is driven by CEDAR’s machine-actionable metadata templates. These templates encode field definitions, datatypes, requiredness, constraints, controlled vocabulary links, display settings, and language-specific labels, and may be assembled from reusable template elements that capture recurring metadata structures such as specimen descriptors, instrumentation settings, or study design attributes. The templates use a formal, JSON Schema-based model, and CEE interprets them at runtime rather than relying on hand-written schema-to-UI mappings (O'Connor et al., 16 Jul 2025).

The rendering model is fully dynamic. When a field becomes required, an ontology binding changes, a value set is updated, or a new field is added, the form rendered by CEE reflects that change without manual synchronization. Supported field types include text, number, date/time, Boolean, checkboxes, image, and video. Fields may be single-valued or multi-valued, and templates may contain complex nested elements and repeated metadata sections. The same template specification also carries display specifications, language-localized labels, and field visibility conditions (O'Connor et al., 16 Jul 2025).

Validation is template-driven and interactive. CEE supports required fields, datatype enforcement, allowed values, ontology term constraints, term hierarchies, and single- versus multi-valued cardinality. Validation feedback is presented in real time through color-coded prompts and a collapsible validation ribbon listing outstanding problems. The system can also generate structured data quality reports that flag missing values, unselected controlled terms, and inconsistencies across the record (O'Connor et al., 16 Jul 2025).

The limitations of the current form logic are explicitly stated. CEE supports field visibility conditions, nested elements, repeated sections, and multi-valued fields, but it does not currently support advanced conditional logic such as dynamic field branching or question-skipping behavior based on prior responses. It also does not yet support cross-field validation rules involving dependencies among multiple fields. The paper further notes that default values are not described (O'Connor et al., 16 Jul 2025).

These behaviors are continuous with the earlier Workbench model. The Workbench used JSON Schema and JSON-LD to encode a common, standards-based format for templates, fields, and metadata; represented templates, fields, and metadata as JSON-LD documents; generated a streamlined, form-based acquisition interface from metadata template definitions; and validated metadata against the corresponding template’s JSON Schema model, providing immediate structural feedback. The move from Workbench editor to embeddable editor therefore preserves the original model-to-form pipeline while altering its deployment context (Gonçalves et al., 2019).

4. Semantic integration, ontologies, and persistent identifiers

CEE’s semantic model is organized around JSON-LD output. Completed metadata instances are serialized as JSON-LD, which the paper presents as machine-readable, semantically structured, compatible with linked data principles, and suitable for downstream reuse, indexing, validation, and transformation. For ontology-controlled fields, CEE preserves both the user-facing label and the corresponding IRI, so the resulting record captures semantic identifiers rather than plain text alone (O'Connor et al., 16 Jul 2025).

Ontology-based value selection is built around BioPortal. Fields in a template can be linked to entire ontologies, ontology branches, or value sets hosted on BioPortal. During data entry, the editor offers suggestions derived from labels and synonyms in those configured resources. The paper names Cognitive Atlas, MeSH, and OpenNeuro Vocabulary as examples of ontologies used in deployments. Because the editor records both labels and IRIs, ontology selection becomes a mechanism for semantic grounding rather than merely a convenience autocomplete feature (O'Connor et al., 16 Jul 2025).

CEE also supports external authority systems. The currently supported authorities listed in the paper are ORCID for individual researchers, ROR for research organizations, and the EPA CompTox API for PFAS chemical identifiers. For these fields, the editor performs REST-based searches to autocomplete user input and validate selections. Those requests are routed through a CEDAR-provided intermediating microservice that handles authentication, standardizes request formats, and normalizes responses across external APIs. The result is stored as an authoritative, globally resolvable identifier (O'Connor et al., 16 Jul 2025).

This semantic stack extends mechanisms already present in the Workbench. The earlier platform supported BioPortal lookup for ontology annotation, allowed template designers to add type and property assertions using ontology classes and properties, permitted field-value constraints that require ontology terms, and supported design-time creation of new terms and value sets mapped to existing BioPortal terms using SKOS properties. The Workbench also included an Intelligent Authoring capability in which a value recommender learned associations among metadata values and ranked suggestions according to field applicability. This suggests that CEE’s semantic authoring is best seen as a deployment of existing ontology-assisted and recommendation-oriented CEDAR semantics into host platforms rather than as a wholly new semantic subsystem (Gonçalves et al., 2019).

5. Integration into host platforms and deployment examples

The host integration model is deliberately minimal. A platform installs the package, inserts the cedar-embeddable-editor element, provides a template and configuration object, optionally injects an existing instance, and retrieves JSON-LD output through the component API. The configuration object controls template and instance injection, form mode such as edit or view-only, language and localization paths, the display of headers, footers, and validation ribbons, and styling integration through scoped CSS classes and slot-based layout hooks. The component visually integrates by inheriting local styles, while still allowing CSS overrides for fonts, spacing, colors, and layout (O'Connor et al., 16 Jul 2025).

The phrase “no custom user-interface development” has a specific meaning in this context. It indicates that the host platform does not need to hand-code metadata forms field by field, build custom ontology widgets, write bespoke validation logic for each standard, or rework form UIs when templates change. It does not imply zero integration effort. The deployer still designs templates in CEDAR, exports and manages template versions, decides when updates are rolled out, stores and indexes metadata output, and connects the editor’s results to backend workflows (O'Connor et al., 16 Jul 2025).

Most deployments do not fetch templates live from CEDAR at runtime. Instead, templates are exported from the CEDAR Workbench, stored locally, and maintained in a host-controlled versioned registry. This strategy keeps the deployment lightweight and places template lifecycle management under repository control. It also aligns with the more general Workbench philosophy that individual services and resources can be incorporated into external applications and workflows (O'Connor et al., 16 Jul 2025).

The paper reports successful deployment in several research platforms and consortia.

Platform	Integration mode	Reported use
Open Science Framework	Embedded in project registration and dataset submission workflows	Psych-DS Official Template, Human Cognitive Neuroscience Data, Generic Dataset Metadata Template
Dryad	Embedded in dataset submission workflows	Neuroscience, high-throughput biology, later HuBMAP assay/sample/tissue workflows
RADx	Read-only mode	Presentation of metadata for COVID-19 diagnostic projects
HuBMAP	Read-only mode	Public interface for viewing consortium metadata templates

Within OSF, users complete general metadata and then select a discipline-specific template, after which CEE renders the corresponding form inside the platform interface. Dryad uses the editor to collect richer metadata in domains such as neuroscience and high-throughput biology, including fields such as experimental paradigm, participant demographics, imaging modality, cognitive domain, and data acquisition protocols, and later adopted HuBMAP templates for assay workflows, sample characteristics, and tissue metadata. RADx and HuBMAP primarily use the component in read-only mode for metadata display rather than interactive authoring (O'Connor et al., 16 Jul 2025).

6. Interoperability, impact, and boundaries of the system

CEE’s main interoperability claim is format and semantics preservation across platforms. Because it outputs JSON-LD and preserves ontology and authority links, the same metadata records can be indexed, transformed, reused across repositories, federated into other systems, and processed by search and analytics pipelines. The paper emphasizes that HuBMAP-developed templates were integrated into both Dryad and OSF without modification, presenting practical portability at the template level rather than merely at the serialization level (O'Connor et al., 16 Jul 2025).

The reported impact is qualitative and workflow-oriented. The paper argues that embedding authoring within systems researchers already use improves metadata completeness, consistency, semantic validity, and alignment with community standards by combining required-field enforcement, ontology-controlled selection, persistent identifier resolution, and template-driven guidance. It also reports complete keyboard operability, screen reader compatibility through WAI-ARIA roles, multilingual support using language maps and fallback logic, and testing across all major browsers and a selection of mobile devices (O'Connor et al., 16 Jul 2025).

The evidence base is explicitly limited. The deployment record covers OSF, Dryad, HuBMAP, and RADx, and the paper states that researchers and platform administrators reported improved metadata quality, enhanced user experience, and reduced maintenance costs, with Dryad staff noting lower barriers for specialized domain-specific submissions. At the same time, the evidence is described as deployment-oriented and qualitative rather than as a formal quantitative usability study. The paper also reports no benchmark data or formal performance measurements (O'Connor et al., 16 Jul 2025).

Several misconceptions are addressed by the publication history itself. First, CEE should not be conflated with the original CEDAR Workbench. The 2019 Workbench paper describes a browser-based metadata authoring environment with modular REST services, ontology-assisted template design, and generated form entry, but it does not describe a JavaScript editor package, plugin architecture, or reusable embeddable widget. Its relevance to CEE lies in service modularity, template semantics, JSON Schema and JSON-LD modeling, and repository-facing workflows rather than in a packaged client-side component (Gonçalves et al., 2019).

Second, the acronym “Cedar” or “CEDAR” appears in unrelated arXiv literatures. It names an authorization policy language and its verification methodology, an agentic data-science application, and a vision-language embedding disentanglement method, none of which concern metadata authoring or the CEDAR Embeddable Editor (Cutler et al., 2024, Disselkoen et al., 2024, Roy et al., 10 Jan 2026, Kubaty et al., 21 May 2026). This distinction matters because only the metadata-authoring papers describe the template-driven, ontology-linked, JSON-LD-producing editor denoted by CEE.

The remaining boundaries of the current editor are therefore well defined. CEE provides schema-driven form generation, ontology-based and authority-backed value selection, semantically rich JSON-LD output, and low-friction embedding into existing research workflows. It does not yet provide advanced branching logic, cross-field dependency validation, fully integrated spreadsheet-oriented workflows, or automatic metadata extraction from primary data files. Those omissions identify the frontier of the current system rather than a contradiction in its design (O'Connor et al., 16 Jul 2025).