> 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/faq.md).

# FAQ

<details>

<summary>What's the default relation when creating Types and Elements ?</summary>

The default relation used by CoreModels when creating a Type along with its elements is the 'Domain Includes' relation which is the equivalent of (has-a) or the 'Composition' concept in programming languages

</details>

<details>

<summary>When should I use 'Domain Includes'/'Composition' and when to use 'SubClass Of'/'Inheritance' ?</summary>

Use *SubClassOf* when it’s an “is-a” relationship

* You’re saying one thing is a specialized type of another.
* All properties of the parent apply to the child.

Examples:

* <mark style="color:$success;">Car</mark> subClassOf <mark style="color:$success;">Vehicle</mark> (every Car is a Vehicle).
* <mark style="color:$success;">ScientificPost</mark> subClassOf <mark style="color:$success;">BlogPost</mark>.

Use this when the type is just a more specific version of another.![](/files/vNxhTEXfHub5UIIL8Han)

***

Use *DomainIncludes* when it’s a “has-a” relationship (composition)

* You’re saying: this property belongs to this class.
* It defines where a property can appear.

Examples:

* <mark style="color:blue;">Transmission</mark> domainIncludes <mark style="color:$success;">Car</mark>.\
  → “Cars have transmissions.”
* <mark style="color:blue;">Author</mark> domainIncludes <mark style="color:$success;">Article</mark>.\
  → “Articles have authors.”

Use this when you’re attaching properties (features, attributes, parts) to a class.![](/files/m6hkPIRh3KLZc7deK0Gl)

</details>

<details>

<summary>What is the difference between a Project and a Space?</summary>

A Project is the highest-level container in CoreModels. It holds one or more Spaces and defines the overall team and permissions. A Space is the technical term for a single schema and contains all the Types and Elements that make up that schema. Think of a Project as a portfolio and a Space as a single, organized project file within it.

</details>

<details>

<summary>Schemas, Spaces, and Data Models, what is the difference ?</summary>

Schemas, Spaces, and Data Models are three interconnected concepts that describe the structure of your data at different levels of a project.

#### Data Model

A Data Model is the abstract blueprint or framework that defines how all your data is organized. It's the highest-level concept, outlining the entities, their properties, and their relationships. A single Data Model can represent your entire business's data ecosystem. Think of it as a complete architectural plan for a building.

***

#### Schema

A Schema is the technical implementation of a Data Model. It's the specific, formalized set of rules that governs the structure of your data. While a Data Model is the abstract plan, a Schema is the code that defines it, such as a JSON Schema file or a set of SQL table definitions. A single Data Model can have different Schemas depending on the system or format used.

***

#### Space

A Space is the technical term in CoreModels for a single Schema. It acts as a project-level container that holds all the Types, Elements, and other assets that belong to a single, defined schema. A single project can have multiple Spaces, with each Space representing a distinct schema.

</details>

<details>

<summary><strong>How can I add rules and constraints to my schema ?</strong></summary>

You can add rules and constraints to your Elements using Mixins. A Mixin is a small piece of metadata that defines a specific behavior or rule. For example, you can add a `required` Mixin to an Element to make it mandatory, or a `minLength` Mixin to enforce a minimum number of characters.

</details>

<details>

<summary><strong>How do I collaborate with my team ?</strong></summary>

CoreModels is built for collaboration. First, you need to invite others to your project, open the 'share' menu that is available on the top right, then type your team member's email and select their role.\
When clicking the 'Add User' button they will receive an email if they doesn't have an account already.

To collaborate with your team or even only to add notes, you can right click on any cell in CoreModels grids and click on 'Add Comment', which will start a thread linked to this cell.

</details>

<details>

<summary>Can I add My own relations ?</summary>

Yes you can add any relation to CoreModels by following these steps:

1. Open the 'Features Tray' (by clicking the hamburger menu (☰) under the CoreModels logo)
2. Click on 'Relations' → Plus button
3. Add a name for the relation, and specify the 'from' and 'to' parts
4. Click 'Add'

Now you can configure the grids to show the relation and use it.

</details>

**Need more help?**&#x20;

If you have any questions that are not answered in our documentation, please contact us at `tech@schematica.io` or use the 'Report an Issue' feature directly in the UI.


---

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