> For the complete documentation index, see [llms.txt](https://learn.coremodels.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.coremodels.io/core-concepts.md).

# 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](/getting-started/crash-course.md) 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 <mark style="color:$success;">Product</mark> or a <mark style="color:$success;">Blog Post</mark>.

Each Type is composed of Elements, which are the individual fields that hold the actual data.

For example, a <mark style="color:$success;">Product</mark> Type would have Elements like <mark style="color:blue;">ProductName</mark> and <mark style="color:blue;">Price</mark>.

* 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 <mark style="color:$success;">Blog Post</mark>, and the fields for <mark style="color:blue;">Title</mark>, <mark style="color:blue;">Body</mark>, and <mark style="color:blue;">Author</mark> are the Elements.

Here are a few more examples:

<figure><img src="/files/wuNpqrjI6cohRtbt5hkZ" alt=""><figcaption><p>Examples of Properties/Elements</p></figcaption></figure>

***

#### 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 <mark style="color:blue;">Job Title</mark> field from a fixed set of options: <mark style="color:purple;">Developer</mark>, <mark style="color:purple;">Product Owner</mark>, <mark style="color:purple;">Designer</mark> etc..

***

#### Mixins

Mixins are a flexible way to add metadata or attributes to your <mark style="color:$success;">Types</mark>, <mark style="color:blue;">Elements</mark>, or <mark style="color:purple;">Taxonomies</mark>. 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 <mark style="color:blue;">Email</mark> Element in a <mark style="color:$success;">Form</mark> 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 <mark style="color:$success;">Book</mark> Type could have a <mark style="color:blue;">BookAuthor</mark> Element that has a relation to a separate <mark style="color:$success;">Author</mark> Type.

A <mark style="color:$success;">Scientific Article</mark> can inherit all the elements of <mark style="color:$success;">Article</mark> to reduce duplications and promote reusability.

Read more about composition and inheritance at [Broken mention](broken://pages/2qcJwAY7Ueyd56d8JXOT)&#x20;

Other examples of relations could be:

<figure><img src="/files/gc76ipUbfEWbI5xy8X0s" alt=""><figcaption><p>Examples of Relations</p></figcaption></figure>

***

#### 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](/core-data-model.md).

***

### 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 grap&#x68;**.**

#### **Schema.org terms and concepts**

In CoreModels, we adopt some terms from the schema.org catalog:&#x20;

* 'SubClassOf' → '*Inheritance*' Concept (is a).\
  Example: a <mark style="color:$success;">car</mark> is a <mark style="color:$success;">vehicle</mark>, so it inherits all the common properties of a vehicle.
* 'DomainIncludes' → '*Composition*' (has-a).\
  Example: a <mark style="color:$success;">car</mark> has a <mark style="color:blue;">transmission</mark>
* 'RangeIncludes' → '*Applicability*' (can-be).\
  Example: a <mark style="color:blue;">transmission</mark> can be <mark style="color:purple;">manual</mark> or <mark style="color:purple;">automatic</mark>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://learn.coremodels.io/core-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.