Frequently Asked Questions
401. How do multiple inheritance scenarios behave in CoreModels?
CoreModels supports multiple inheritance naturally because its graph metamodel allows a Type to have more than one SubClassOf relation. When inherited Elements overlap, the child inherits the union; when rules conflict, the child can override with its own Mixin. This flexibility is powerful but demands discipline — most multiple-inheritance patterns are clearer as composition plus mixins, reserving true inheritance for genuine is-a relationships.
402. What is the 'diamond problem', and how do graph models avoid it?
The diamond problem occurs when a class inherits from two parents that share a common ancestor, causing ambiguity about which inherited behavior wins. Graph models avoid it structurally: a node is simply the set of its relations, so merging contributions from multiple parents is explicit. Each inherited Element appears once in the graph regardless of how many paths reach it, eliminating the duplication that causes the ambiguity in class-based languages.
403. How do you design an abstract Type that should never be instantiated directly?
Mark the Type with a Mixin or naming convention that signals abstractness (an Abstract prefix, or a Mixin of abstract: true), document the intent explicitly, and rely on downstream tooling to enforce it — JSON Schema exports can include a discriminator that excludes the abstract Type from valid values. The abstract Type still holds shared Elements and rules that concrete subclasses inherit.
404. How do you handle optional versus required attributes in an inheritance chain?
Required-ness is expressed via the required Mixin at the point where the Element is attached, which means a parent can require an Element and a child can inherit that requirement or override it. CoreModels' Mixin model keeps required status flexible per Type even when the Element is inherited, avoiding the rigidity of languages where required status is baked into the class definition.
405. How do you expose only some inherited properties to specific consumers?
Use Views to scope which Elements are visible to which audiences, export different Views to different targets, or define facet Types that reference the base Type but expose a limited Element set. Hiding fields at the consumer boundary is cleaner than forking the underlying Type, because the source of truth stays singular.
406. How do aliasing and overriding work when composing from multiple sources?
CoreModels handles naming collisions explicitly: when two composed sources contribute an Element with the same name, you choose which wins, create an alias, or rename one for clarity. Overrides are first-class — a child Type can replace an inherited rule with a tighter or looser one via a new Mixin. Both operations are visible in the graph, so intent is traceable.
407. What is the impact of reuse on testability of a schema?
Reuse improves testability: a shared Element tested once applies everywhere it is used, and a shared Component tested once guarantees consistent structure across consumers. Conversely, it also means a single broken shared piece fails every consumer at once, which makes CI for shared definitions essential. The net effect is higher leverage in both directions.
408. How do you discover reusable patterns in an existing, tangled model?
Look for Elements with similar names or definitions across Types, clusters of fields that appear together repeatedly, validation rules duplicated with small variations, and Types that share most of their structure. CoreModels' Types Grid makes this kind of structural audit much faster than eyeballing JSON Schema files, and Neo Agent can surface candidate extractions automatically.
409. How do you refactor a sprawling schema toward better reuse?
Start by identifying duplicated patterns such as shared Elements, shared validation, and shared structural clusters; extract them into reusable Elements or Components; migrate Types one at a time; preserve backward compatibility for active consumers; and document every extraction. Refactoring a schema is incremental — trying to boil the ocean usually produces a parallel schema that no one migrates to.
410. How do you ensure reusable components don't leak domain-specific assumptions?
Name shared pieces for their universal meaning (Address, ContactInfo, Author) rather than their origin (BlogPostAuthor), avoid baking in validation rules specific to one consumer, document intended use clearly, and review additions through a shared owner. When a shared piece accumulates conditional rules, that is the signal to split it or move the condition to the consumer.
411. How do you govern ownership when multiple teams depend on a shared Element?
Assign a clear owner, either individual or team; require reviews from the owner for any change; document the Element's purpose and non-goals; publish a change process with notice periods; and use CoreModels' role system to enforce who can modify what. Shared Elements without owners drift into incoherence quickly; shared Elements with clear owners stay valuable for years.
412. How does reuse in a schema impact downstream API contracts?
Reuse amplifies both consistency and risk in downstream contracts: a well-managed shared Element ensures every API using it behaves the same way, while an unmanaged change can break multiple APIs simultaneously. Version shared pieces explicitly, test compatibility across every consumer in CI, and communicate changes widely. Shared definitions raise the stakes of every edit.
413. How do you balance granularity and composition overhead?
Create reusable pieces at the level where they are actually reused — no finer. A cluster of three fields that always appear together is a good Component; a single widely-used field is a good Element; a field used once is not a reuse candidate at all. Over-decomposition creates scaffolding no one uses; under-decomposition creates duplication. The evidence of real reuse is the guide.
414. How can Components in CoreModels encapsulate reusable structures cleanly?
Components bundle a named set of Elements and relationships into a reusable unit that can be referenced by many Types. They encapsulate structure in the way Elements encapsulate fields, at a higher level of granularity. Because Components are first-class graph nodes, they participate in governance, versioning, and documentation just like Types and Elements.
415. How does reuse in schemas contribute to long-term architectural health?
Schemas built on reusable pieces age more gracefully: shared concepts update once, inconsistencies are impossible to introduce by accident, and new systems can adopt the model quickly. Over a multi-year horizon, this discipline pays off as the organization's data landscape stays coherent instead of fragmenting into incompatible local dialects.
416. What is a Project in CoreModels, and what does it represent?
A Project is the highest-level container in CoreModels, representing a distinct initiative, product, customer engagement, or domain that requires its own modeling workspace. Projects define team membership, permissions, and access boundaries; they contain one or more Spaces that hold the actual schemas. Think of a Project as the organizational unit that wraps a body of modeling work.
417. When should an organization create a new Project rather than reuse an existing one?
Create a new Project when the work has a distinct team, different access controls, separate governance, or covers an unrelated domain. Reuse an existing Project when the new work shares collaborators, access policies, and is part of the same initiative. A rough heuristic: if the roster of people who should see the schemas differs, it is a new Project.
418. What is a Space, and how does it relate to a schema?
A Space represents a single coherent schema within a Project. All the Types, Elements, Taxonomies, and Relations inside a Space collectively define one data model. Spaces are where the actual modeling happens, and a Project can contain multiple Spaces — one per schema standard, integration, or domain slice.
419. Why can a single Project contain multiple Spaces?
Organizations often need to model multiple related but distinct schemas. A healthcare Project might hold HL7 FHIR, a clinical trials schema, and a patient registry in separate Spaces; a publishing Project might hold separate Spaces for blog content, marketing pages, and product catalog. Each Space is self-contained, but Projects keep them organizationally together.
420. How are the terms 'Space' and 'Schema' used interchangeably in CoreModels?
Because each Space holds exactly one schema, documentation and conversations often treat the terms as synonyms. Space is the platform term — a workspace containing the schema and associated state; Schema is the conceptual term for the model itself. Either term is fine in most contexts — what matters is that they refer to the same boundary of coherent modeling.
421. When should you model several related schemas as separate Spaces within one Project?
Use separate Spaces when each schema has its own identity, validation rules, or external consumers, but the schemas share context such as a canonical mapping, integration targets, or governance policies. Keeping them in one Project makes cross-schema work — mappings, shared taxonomies, comparison views — much easier than splitting them across unrelated Projects.
422. How do Spaces help manage multiple data standards (like HL7 FHIR, schema.org) side by side?
Each standard lives in its own Space with its own Types, Elements, and Taxonomies, so imports and exports stay aligned with the standard's native semantics. Mappings between standards are then expressed as relations across Spaces, letting you build a canonical layer on top of multiple industry schemas without forcing any of them into a compromised shared shape.
423. How does the Space selector let you work across or within schemas?
The Space selector in the CoreModels interface lets you focus on one Space to work deeply within a single schema, or select multiple Spaces to view, search, and edit across schemas simultaneously. This flexibility matters for cross-schema mapping work, comparison reviews, and cases where a canonical model spans several source Spaces.
424. What role do Projects play in access control and team membership?
Projects are the primary access boundary: membership and roles are defined at the Project level and propagate to all Spaces inside. Different Projects can have entirely different teams, which is how organizations run sensitive initiatives alongside public ones. Within a Project, CoreModels' role system then controls what each member can do with the schemas.
425. How do you organize Projects for a multi-brand or multi-product organization?
Common patterns include one Project per brand or product line (strong isolation, independent teams), one Project per functional domain across brands (shared modeling language), or a hybrid where shared canonical schemas live in one Project and brand-specific extensions live in others. The right structure follows your team and governance boundaries.
426. How can Projects be created from templates, and why is that useful?
Templates pre-configure a Project with conventions your organization uses: common Mixins, canonical Taxonomies, validation rule sets, naming standards, default Views. Creating Projects from templates ensures every new initiative starts from the same baseline rather than reinventing the wheel, which is how teams scale modeling practice without central bottlenecks.
427. How do Projects relate to billing, plan limits, and collaboration seats?
Plan limits such as the number of Projects, Spaces, seats, and feature access are typically scoped to the account or organization rather than the individual Project. Billing covers the overall usage. Specific limits depend on the CoreModels plan tier — Free, Pro, or Custom — and your account page shows the current plan and its boundaries.
428. What governance practices help keep Projects tidy over time?
Establish naming conventions for Projects and Spaces, archive or delete Projects that are no longer active, review Project ownership regularly, document each Project's purpose, and ensure every Project has an accountable owner. Without these practices, Projects accumulate like abandoned repos — visually present but creating confusion for new members.
429. How do you migrate content between Projects or Spaces?
Export the source Space to JSON Schema or JSON-LD, import into the destination, and re-establish any cross-Space relations or mappings. For large migrations, work iteratively: move one logical cluster at a time and validate each step. CoreModels preserves semantic content through export and import, but references across Spaces may need re-linking at the destination.
430. How does the CoreModels home screen surface the Projects a user can access?
The home screen lists every Project the current user is a member of, with key metadata like last-modified date, Space count, and collaborators. Users can open a Project to see its Spaces, create new Projects, or join invitations. It is the starting point for every session and the primary navigation anchor.
431. How do you decide on naming conventions for Projects and Spaces?
Use names that describe the initiative or schema scope in words the team will recognize a year from now, avoid internal codenames that age poorly, keep Project names broader than Space names, and use consistent prefixes or suffixes if many Projects share a theme such as Client-X or Domain-Y. Naming conventions are cheap to establish and expensive to change after adoption.
432. What happens to related Types, Elements, and Taxonomies when you reorganize Spaces?
Within a Space, reorganizing Types and their relations is a local operation. Moving content between Spaces typically requires re-import because Spaces are independent schemas, and cross-Space references need to be re-established at the destination. Plan reorganizations with a clear target and perform them in atomic batches where possible.
433. How do you handle cross-space references or mappings?
Model mappings between Spaces as relations at the Project level or through a dedicated canonical Space that references entities from multiple source Spaces. Some organizations use a dedicated mapping Space that holds alignment rules between HL7 FHIR and schema.org, for example. CoreModels supports this pattern natively through its graph model.
434. How do Projects support separation between production and experimental schemas?
You can keep production and experimental work in separate Projects (strongest isolation), separate Spaces within one Project (lighter separation with shared team context), or use branches in Git-backed workflows for iterative changes to a single schema. Each approach trades isolation against collaboration cost; most teams use a combination.
435. What CoreModels features depend on the Project/Space boundary?
Access control, billing, team membership, imports and exports, Git synchronization, and search scope all respect the Project/Space boundary. Views, Mixins, and Taxonomies are typically Space-scoped. Understanding the boundary helps you plan modeling work that spans multiple schemas without accidentally creating coupling you did not intend.
436. What is a Type in CoreModels, and what real-world concept does it represent?
A Type represents an entity, class, or concept in your data model — the things your business talks about, such as Person, Article, Product, or Disease. Types are the fundamental building blocks that define what kinds of things exist in your schema. Every data record ultimately corresponds to one or more Types, and Types organize the fields (Elements) that describe them.
437. How does a Type correspond to a class in object-oriented design or a table in a database?
Conceptually, a Type is to a schema what a class is to object-oriented code or a table is to a relational database. All three describe a shape that instances conform to, with attributes and relationships. A Type differs in that it is technology-neutral: the same Type can export to a database table, a JSON Schema object, a JSON-LD class, or a code class, each generated from the same source.
438. How do you create a new Type in CoreModels?
Open a Space, add a new Type through the Types Grid or Graph view, give it a name, optionally set a parent Type for inheritance, and attach Elements either by creating new ones or linking existing reusable ones. Documentation, Mixins, and validation rules can be added at any time. Neo Agent can also suggest Types and Elements based on descriptions of your domain.
439. How do you choose between representing something as a Type versus an Element?
Represent something as a Type when it has its own identity, lifecycle, or is referenced as a standalone entity such as Author or Product. Represent it as an Element when it is a descriptive property of another Type such as firstName or publicationDate. A common test: if you would ever fetch just this thing by ID, it is a Type; if it only makes sense as part of something else, it is an Element.
440. What does it mean for a Type to be a 'normal type' versus a 'data type'?
A normal type (IsNormalType flag) represents a domain entity — Person, Article, Order — that has structure and relationships. A data type (IsDataType flag) represents a primitive or value shape such as string, integer, or date, used as the type of Elements rather than as a standalone entity. CoreModels distinguishes them so tooling can treat entities and values appropriately.
441. How does inheritance via 'SubClassOf' behave among Types?
When a Type is linked to another by SubClassOf, the child inherits all of the parent's Elements and rules and can extend them with its own. Inheritance is transitive: a ScientificArticle that SubClassOf Article, which SubClassOf Content, inherits everything up the chain. CoreModels' graph model makes these chains visible in the Graph view and makes them queryable.
442. How do you build a Type hierarchy for a domain like publishing or healthcare?
Start with a broad parent (Content for publishing, ClinicalResource for healthcare), add common Elements like identifier, title, created, and modified, then create specialized children (BlogPost, Article, Newsletter in publishing; Patient, Condition, Observation in healthcare). Add shared controlled vocabularies as Taxonomies. Keep hierarchies shallow and meaningful — no more than three or four levels deep in most real domains.
443. What is an abstract Type in CoreModels, and when is it useful?
An abstract Type is a Type intended to be inherited from but never instantiated directly — it holds shared Elements and rules for its concrete subclasses. Marking a Type as abstract is useful for base definitions like Content or Resource that exist only to factor out common structure. CoreModels supports this pattern through Mixins and documentation conventions.
444. How do Types relate to JSON Schema objects on import?
During JSON Schema import, each object schema (type object with properties) becomes a Type in CoreModels, its $id or JSON pointer becomes the Type's external Id, and its properties become Elements. Nested objects become nested Types, and $ref links become relations. The result is a faithful graph representation of the source schema that can be edited visually.
445. How do Types relate to JSON-LD '@type' values on import?
When importing JSON-LD, each class referenced as an @type becomes a Type in CoreModels, with its IRI preserved as an external identifier. Inheritance declared through rdfs:subClassOf becomes SubClassOf relations in the graph. Properties (predicates) become Elements attached to Types based on domain and range declarations.
446. How do you refactor two similar Types into a shared parent?
Identify the shared Elements and rules, create a parent Type containing them, link both existing Types to the parent via SubClassOf, remove the shared Elements from the children (they now inherit), and verify the export produces equivalent schemas. CoreModels' graph view makes the before-and-after structure easy to compare, and Neo Agent can propose candidate extractions from analysis.
447. How do you configure which Elements belong to a Type?
In the Types Grid or the Type detail view, add Elements to a Type either by creating new ones or by attaching existing reusable Elements via the domainIncludes relation. Elements attached to a Type become its fields; removing the attachment removes the field without deleting the Element globally if it is used elsewhere.
448. What happens to a Type's children when the parent changes?
Changes to a parent Type propagate to children automatically because inheritance is by reference through the SubClassOf relation, not by copy. Adding an Element to the parent adds it to every descendant; tightening a validation rule applies everywhere; renaming propagates transitively. Impact analysis before major parent changes is essential for exactly this reason.
449. How do you rename a Type without breaking references?
Use the rename feature rather than delete-and-recreate, because the underlying ServerId stays stable and all references — relations, mappings, Mixins — continue to point to the same node. The display name changes; the identity does not. If external consumers reference the Type by external Id, coordinate the rename with them before shipping.
450. How do you retire a Type that is no longer used?
First confirm no active Types, Elements, or mappings reference it; mark it as deprecated via a Mixin or documentation to signal intent; maintain it for a transition period; and only remove after confirmed non-use. CoreModels' graph model makes it easy to trace references and verify that removal is safe.
451. How does the Types Grid help you work with many Types at once?
The Types Grid is a tabular view that lists every Type in the selected Space along with its Elements, rules, and Mixin values. It supports filtering, bulk editing, column configuration, and export. When you need to compare many Types, enforce naming consistency, or audit a large schema, the Grid is the most efficient interface.
452. How does the Graph view help you understand how Types connect?
The Graph view renders Types and their relations visually, showing inheritance chains, composition links, and cross-Type references. It is the best tool for questions about structure — where loops exist, which Types depend on this one, what would removing this break. Visual inspection in the Graph view surfaces issues that are invisible in tabular or textual representations.
453. How do you document a Type so its purpose is clear to collaborators?
Add a description to the Type explaining what it represents, give it an intention-revealing name, link to external references where relevant, include example instances via Exemplars, and annotate why any non-obvious constraints exist. Documentation is part of the schema, not an afterthought — and future you will thank present you for it.
454. How do you bulk-edit Types for consistency?
The Types Grid supports bulk operations — selecting multiple Types and applying changes like adding a Mixin, renaming a shared Element, or attaching documentation — in a single action. For larger transformations, exports and imports combined with CI tooling let you refactor at scale while keeping the audit trail intact.
455. What are the best practices for naming Types in a large schema?
Use domain-appropriate nouns in PascalCase (Article, CustomerAccount), prefer singular over plural for entity types, avoid implementation terms (no Table, Record, or Entity suffix unless meaningful), and establish prefixes only if multiple schemas share a Space and ambiguity would arise. Consistency across Types matters more than any single stylistic choice.
456. How do Types support mapping between multiple data models?
Types from different Spaces can be linked through mapping relations, expressing alignment such as HL7 ConditionDefinition mapping to schema.org MedicalCondition. These mappings preserve the independence of each source model while making cross-model translation explicit and queryable. CoreModels' mapping view visualizes these relationships clearly.
457. How do you export Types to JSON Schema and JSON-LD?
Open the export panel for the Space, select the target format (JSON Schema or JSON-LD), configure options such as draft version or compaction, and export. Types become object schemas in JSON Schema or classes in JSON-LD, with full preservation of Elements, Taxonomies, Relations, and Mixin rules. The export is deterministic and round-trips cleanly.
458. How can Types be annotated with mixins to enforce rules?
Mixins attach to Types (or Elements) to carry validation rules, metadata, or behavior flags. A Type with a required Mixin on certain Elements produces JSON Schema with those Elements in the required array; a Type with custom Mixins can carry domain-specific rules. Mixins are the primary mechanism for layering rules onto Types without subclassing.
459. How do Types appear in generated documentation?
Generated documentation typically lists each Type with its description, inheritance, Elements (with their types and descriptions), rules, and example instances from Exemplars. CoreModels can export documentation in multiple formats — Markdown, HTML, or embedded in tools like Postman — keeping the documentation always in sync with the schema.
460. How does CoreModels store a Type's external ID alongside its internal ServerId?
Every Type has two identifiers: an internal ServerId (a GUID used for graph integrity and refactoring safety) and an external Id (a JSON pointer, IRI, or other external reference used during import and export). This separation lets CoreModels rename Types freely without breaking internal references, while preserving fidelity with external systems that identify Types by external Id.
461. What is an Element in CoreModels, and how does it differ from a Type?
An Element is a reusable property definition — a name with a data type and optional validation rules — that can be attached to multiple Types. Where a Type represents a thing (Article, Product), an Element represents a descriptor of a thing (title, price, status). The key difference is reuse: one Element can belong to many Types without duplication.
462. Why are Elements designed to be reusable across multiple Types?
Reuse is the whole point. A title Element attached to both Article and Product ensures both Types share the same name, data type, and validation rules. Change the Element once, and every Type using it reflects the change. This is how CoreModels avoids the duplication that plagues schemas where every Type defines its own near-identical version of the same field.
463. What data types can an Element have in CoreModels?
Elements can have primitive data types (string, integer, number, boolean, date, dateTime), reference types (pointers to other Types or Elements), collection types (arrays of any of the above), and special types like Taxonomy-controlled values. Data types map faithfully to JSON Schema types on export and JSON-LD datatypes through xsd declarations.
464. How do you create a new Element from scratch?
In the Elements panel or within a Type detail view, create a new Element, give it a name, choose its data type, attach optional Mixins for validation, and optionally link to a Taxonomy for controlled values. The new Element becomes available for attachment to any Type in the Space. Neo Agent can also propose Elements based on descriptions of what you are modeling.
465. How do you attach an existing Element to a Type?
From the Type detail view, use the add Element control to browse existing Elements and attach one — this creates a domainIncludes relation between the Type and the Element. The Type now has this Element as a field. Detaching works the same way, removing the relation without deleting the Element itself if it is still used by other Types.
466. What happens if you change an Element used by many Types?
The change propagates automatically to every Type using it, because Elements are referenced rather than copied. This is powerful for consistency and dangerous for breakage — renaming an Element or changing its data type affects every consumer. Impact analysis before such changes is essential, and CoreModels' graph view makes the affected Types easy to see.
467. How do Elements translate to properties in JSON Schema output?
Each Element attached to a Type becomes a property in the Type's properties object on export. The Element's data type maps to the JSON Schema type, its Mixins become validation keywords like minLength and pattern, and its required Mixin places it in the Type's required array. The result is standard JSON Schema that any validator can consume.
468. How do Elements translate to predicates in JSON-LD output?
In JSON-LD export, each Element becomes a predicate — a property IRI in the generated @context. The Element's data type maps to an xsd type declaration, and its relations (like ControlledList to a Taxonomy) become property constraints. The export produces standard JSON-LD suitable for Linked Data consumption.
469. How do you handle multi-valued Elements (arrays)?
Mark the Element as multi-valued through a Mixin or configuration option, and CoreModels exports it as an array in JSON Schema (with minItems, maxItems, and uniqueItems constraints as configured) or as a container such as @list or @set in JSON-LD. This supports patterns like an Article with multiple Authors or a Product with multiple tags.
470. How do you express required-ness on an Element via the 'required' mixin?
Apply the required Mixin at the point where the Element is attached to a specific Type. This tells CoreModels that the Element must be present in instances of that Type, producing the expected required array in JSON Schema. Because required is per attachment rather than global, the same Element can be required in Article and optional in Draft.
471. How do you add validation rules (minLength, maxLength, pattern) to an Element?
Attach the relevant Mixins — minLength, maxLength, pattern — either to the Element globally or to its specific attachment to a Type. The Mixin values configure the validation rule. On export, these become JSON Schema constraints at the corresponding property. The Rule Builder supports more complex conditional rules when simple Mixins are not enough.
472. How do you link an Element to a Taxonomy for controlled values?
Create or select a Taxonomy, then add a ControlledList relation from the Element to the Taxonomy. The Element now accepts only terms from that Taxonomy, and exports to JSON Schema include the terms as an enum while JSON-LD exports reference the Taxonomy as a SKOS ConceptScheme. This is the clean way to enforce controlled values across consumers.
473. How do Elements support composition over inheritance in a schema?
Because Elements are reusable units attached to Types via relations rather than inherited, they embody composition. You build a Type by composing the Elements it needs, not by inheriting a rigid parent. This keeps the schema flat, flexible, and easy to refactor — exactly the properties that make composition preferable to inheritance in most cases.
474. How do you rename an Element without breaking downstream consumers?
Use the rename operation on the Element; its internal ServerId stays stable, so all attachments and references continue to resolve. If the rename affects an exported schema's property name, coordinate with downstream consumers or use an alias during the transition. CoreModels tracks the rename in history for audit purposes.
475. How do you deprecate an Element gracefully?
Mark the Element with a deprecated Mixin, update documentation to explain the replacement, keep the Element attached to Types during the transition period, communicate the deprecation timeline to consumers, and only detach and delete after consumer migration is confirmed. Rushed deprecations are how you break integrations you forgot existed.
476. How do you decide whether a new Element should be reused or created fresh?
Search for existing Elements with similar names or purposes. If one matches semantically — same concept, same validation, same intended use — reuse it. If it only superficially matches (same name, different meaning), create a fresh Element to avoid semantic collision. Reuse by accident is worse than no reuse at all.
477. How does the Types Grid display Elements per Type?
In the Types Grid, each row is a Type and configured columns show Elements and their properties. You can expand a row to see all attached Elements, filter by Element attributes, or add Mixin columns like JSON Schema Rules and JSON Schema Mixin to view validation rules. It is the most efficient way to survey how Elements are distributed across Types.
478. How does the Elements panel let you manage reusable Elements globally?
The Elements panel lists every Element in the Space independent of which Types use them, so you can audit the complete vocabulary, find unused Elements, rename or consolidate duplicates, and bulk-edit validation rules. This global view is complementary to the Types Grid's Type-centric view and essential for keeping a reusable Element library healthy.
479. How do Elements interact with mixins?
Mixins attach to Elements to carry validation rules, metadata, and behavior — required, minLength, pattern, custom domain rules. The same Element can have different Mixin values at different attachment points, so required status or length limits can vary per Type. This is how CoreModels expresses context-sensitive rules without cloning Elements.
480. What is the role of the Element's data type during JSON Schema round-trip?
The data type determines how the Element exports to JSON Schema (type string, integer, boolean, and so on) and how it imports back when the schema is re-read. CoreModels preserves the data type precisely during round-trip, including nuances like integer versus number, so exports and re-imports produce equivalent schemas without drift.
481. How do you document an Element so it can be understood outside of context?
Give it an intention-revealing name, a description that explains its purpose and units, examples of valid values, and links to external references such as industry standards or internal wikis. Because Elements are widely reused, their documentation travels with them to every Type they attach to, so investing in clear Element docs pays off at scale.
482. How do you find unused Elements and clean them up?
The Elements panel surfaces Elements not attached to any Type, making cleanup a filter operation. Before deleting, confirm the Element is not referenced by saved queries, pending changes, or external mappings. Periodic cleanup keeps the Element library lean and signals to contributors that the set of reusable pieces reflects current practice.
483. How do you version Elements when their meaning changes?
If the meaning genuinely changes, the old Element should be deprecated and a new Element with a different name created, because versioning a single Element in place breaks consumers that relied on the old meaning. If only validation rules change, a Mixin update may suffice. Meaning changes are structurally different from rule changes and deserve different handling.
484. How do you split an Element that ended up being used for two different concepts?
Create two new Elements with distinct names reflecting the actual concepts, re-attach each Type to whichever new Element matches, remove the overloaded original, and document the migration. This cleanup is painful but non-optional: an Element with two meanings is an invisible bug that causes drift and confusion until it is split.
485. How do Elements support schema mapping between different models?
Because Elements are first-class reusable units, mapping them between models is a matter of expressing relations: the HL7 FHIR code Element maps to the schema.org identifier Element. CoreModels supports this through mapping relations in the graph, which can be visualized, queried, and used to drive transformation logic in downstream pipelines.
486. What is a Taxonomy in CoreModels, and when should you use one?
A Taxonomy is a controlled, hierarchical list of terms used to classify or categorize things — topics, statuses, study types, regions. Use one when an Element should only accept values from a curated set, when the terms have relationships (parent, child, broader, narrower), or when the terms need to evolve independently of the schemas that reference them.
487. How does a Taxonomy differ from a free-form text Element?
A free-form text Element accepts any value, which makes data quality depend entirely on editor discipline. A Taxonomy enforces a controlled set at the schema level, preventing typos, drift, and accidental duplicates. Taxonomies also carry structure such as hierarchies, aliases, and definitions that plain text fields cannot express, making them far more useful for filtering, navigation, and analytics.
488. How do Taxonomies relate to 'enum' in JSON Schema?
On JSON Schema export, a Taxonomy becomes an enum listing the allowed term names. This means any downstream JSON Schema validator enforces the controlled vocabulary automatically. The difference is that Taxonomies in CoreModels carry much more — hierarchies, definitions, multilingual labels — which JSON Schema enum cannot express but which surfaces through JSON-LD SKOS export.
489. How do you build a hierarchical Taxonomy with parent and child terms?
Create the Taxonomy, add terms, and link child terms to their parents via a hierarchical relation (typically SubClassOf or a SKOS broader/narrower relation). Hierarchies can be arbitrarily deep, though most practical Taxonomies stay within two or three levels. The Graph view makes hierarchy structure easy to inspect and edit.
490. What is the role of the 'ControlledList' relation?
The ControlledList relation connects an Element to a Taxonomy, declaring that the Element accepts only terms from that Taxonomy. This is the primary mechanism for enforcing controlled vocabularies on specific fields. During export, it produces enum constraints in JSON Schema and SKOS references in JSON-LD.
491. How do you link a Taxonomy to an Element so only its terms are allowed?
Open the Element, add a ControlledList relation pointing to the Taxonomy, and optionally mark the Element as multi-valued if it should accept an array of Taxonomy terms. The linkage survives export to JSON Schema (as enum) and JSON-LD (as SKOS Concept references), and it is visualized in the Graph view for easy verification.
492. What is the difference between a Taxonomy and a Type marked 'SysValuesMap = Taxonomy'?
Conceptually they are the same thing — a Taxonomy is implemented internally as a Type with the SysValuesMap flag set to Taxonomy. This implementation detail lets Taxonomies participate in the same graph machinery as other Types (relations, Mixins, inheritance) while being treated specially for validation and export. Most users never need to think about SysValuesMap directly.
493. How do you model a Taxonomy for study types (Experimental, Observational, Theoretical)?
Create a Taxonomy named StudyType, add terms for Experimental, Observational, and Theoretical, and optionally define hierarchies if some terms are specializations — for example, RandomizedControlledTrial under Experimental. Link the Taxonomy to the study Element on your Study Type via ControlledList, and the schema now enforces that every study carries a valid study type.
494. How do you evolve a Taxonomy by adding, removing, or renaming terms?
Adding terms is usually backward-compatible; renaming requires migrating existing data that references the old name; removing terms requires confirming no data or schema references them. CoreModels' change tracking shows every Taxonomy edit with authorship and timestamp, and Git integration adds full version history for Taxonomies alongside schemas.
495. How do you handle Taxonomy localization across languages?
Each Taxonomy term can carry multiple labels — one per language — through multilingual label properties. The underlying term identity stays stable across languages, so references do not break. On export, JSON-LD supports language-tagged literals natively, while JSON Schema typically exports the canonical label with locale metadata in annotations.
496. How do Taxonomies support faceted navigation in a content system?
Because Taxonomies are structured controlled vocabularies, they map directly to facet filters in a content UI — users pick from defined categories rather than searching free text. Hierarchies let facets drill down from broad to narrow. Publishing Taxonomies alongside content in JSON-LD feeds powers both site filters and AI search citations.
497. How do you represent Taxonomies in JSON-LD using SKOS?
Export each Taxonomy as a skos:ConceptScheme with its terms as skos:Concept instances, linked through skos:broader and skos:narrower for hierarchy, skos:prefLabel and skos:altLabel for labels, and skos:definition for descriptions. This is standard linked-data Taxonomy representation, interoperable with other semantic-web systems that consume SKOS.
498. How do you import an existing Taxonomy from an external source?
Use CoreModels' import tools to load a SKOS, JSON-LD, CSV, or Taxonomy-format file; the importer creates a Taxonomy node with its terms and hierarchy preserved. External identifiers are kept so re-imports update the same Taxonomy rather than creating duplicates. Review the imported Taxonomy in the Graph view to confirm the hierarchy is correct.
499. How do you connect CoreModels Taxonomies to the OLS ontology browser or other external vocabularies?
Mark Taxonomy terms with IRIs pointing to external ontologies such as the Ontology Lookup Service, schema.org, or industry vocabularies, or import from those sources directly via the OLS MCP integration. This links your internal terms to authoritative external definitions, enabling federated semantics and making your Taxonomy interoperable with any system that consumes the same ontology.
500. How do you decide whether a controlled list should be a Taxonomy or embedded enum values on an Element?
Use a Taxonomy when terms have hierarchy, need definitions or multilingual labels, should be reused across Elements, or evolve independently of the schema. Use inline enum values on an Element when the list is small, flat, unlikely to grow, and used by only that Element. Taxonomies carry overhead; simple flat enums do not need it.