📌Core Concepts
Welcome to the Core Concepts page. These are the fundamental building blocks of a schema in CoreModels. Understanding these concepts is key to designing, visualizing, and managing your data structures effectively.
You can also use the Crash Course in order to see live examples of how to setup your model.
Types & Elements
At the heart of your schema is the Type, which serves as a blueprint or template for a data structure. A Type defines the kind of information that can be stored, such as a Product or a Blog Post.
Each Type is composed of Elements, which are the individual fields that hold the actual data.
For example, a Product Type would have Elements like ProductName and Price.
In SQL, Types are like the tables and Elements are like the Columns.
In Object Oriented programming languages, types are the classes, and Elements are the properties.
In Forms, the Type is the whole form, and the Elements are the fields inside that form.
In Content Management Systems (CMSs). All content types are Types and the fields are the elements, For example a Blog Post, and the fields for Title, Body, and Author are the Elements.
Here are a few more examples:
Taxonomies
Taxonomies are classification systems that help you organize your data into categories.
They can be a simple, flat list of options (like a dropdown menu) or a nested, hierarchical structure with parent and child categories.
You can link a Taxonomy to an Element to ensure users select from a predefined list of choices, guaranteeing data consistency.
For example, a field in a registration form, could require the user to select the value for the Job Title field from a fixed set of options: Developer, Product Owner, Designer etc..
Mixins
Mixins are a flexible way to add metadata or attributes to your Types, Elements, or Taxonomies. They don't contain data themselves but provide information or rules about the data structure.
Think of them like C# attributes or setting a "nullable" checkbox in a database, or any validation rules that goes around a field.
For example, an Email Element in a Form can have a "required" Mixin to mark it as a mandatory field, it also has a special validation (format) to insure having the correct structure for a valid email address.
Relations
Relations define the connections between different Nodes (Types, Elements, Taxonomies) in your schema. They allow you to link one piece of data to another, reflecting real-world connections.
A Relation establishes a clear and structured link from an Element in one Type to an entire record in another Type.
For example, a Book Type could have a BookAuthor Element that has a relation to a separate Author Type.
A Scientific Article can inherit all the elements of Article to reduce duplications and promote reusability.
Read more about composition and inheritance at
Other examples of relations could be:
Spaces
A Space is the top-level container that holds all the different parts of a project, schema, or content repository. It's a complete, self-contained environment that organizes your Types, Elements, Taxonomies, and other components.
Think of a Space like a dedicated folder or a single application where all the data structures and content for one specific project live. but unlike a simple folder, assets within your system -such as a Type- can belong to more than one Space. This allows for reusability without duplication.
a Space is the technical term for a single schema, and the Core Data Model is the unified structure that is built by connecting multiple Spaces together. Read more at the Core Data Model.
Terminology notes:
Nodes & Relations
Since the Types, Elements, Taxonomies and the other CoreModels components are interconnected in a dynamic way, far more agile than Tables or Spreadsheets, they are easier imagined and referred to as Nodes in a graph, that are connected by the relations. So for ease of reference, we refer to Types, Elements, Taxonomies, and any other CoreModels structure that can be connected using relations as Nodes that floats in the schema graph.
Schema.org terms and concepts
In CoreModels, we adopt some terms from the schema.org catalog:
'SubClassOf' → 'Inheritance' Concept (is a). Example: a car is a vehicle, so it inherits all the common properties of a vehicle.
'DomainIncludes' → 'Composition' (has-a). Example: a car has a transmission
'RangeIncludes' → 'Applicability' (can-be). Example: a transmission can be manual or automatic
Last updated