# Core Concepts

Welcome to the Core Concepts page.

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.

***

#### 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:

![Examples of Properties/Elements](/docs-assets/wuNpqrjI6cohRtbt5hkZ.png)

*Examples of Properties/Elements*

***

#### 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.

Other examples of relations could be:

![Examples of Relations](/docs-assets/gc76ipUbfEWbI5xy8X0s.png)

*Examples of Relations*

***

#### 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](/concepts/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`