Core Concepts

Metapad is built on the principles of metamodeling - a powerful approach to defining and working with domain-specific models. This guide explains the key concepts you'll encounter.

The Modeling Layers

Metapad uses a layered architecture inspired by the OMG's Meta-Object Facility (MOF). Understanding these layers is key to using Metapad effectively.

M3: The Meta-Metamodel (System Layer)

This is Metapad's built-in foundation - you don't modify it directly. It defines:

What a "Node Type" is
What a "Relationship Type" is
What a "Property" is
What a "Diagram" is

Think of M3 as the grammar of the modeling language itself.

M2: Your Metamodel (Type Layer)

This is where you define what kinds of things can exist in your domain:

M2 Concept	Description	Example
Node Type	A category of things	"Department", "Employee", "Server"
Relationship Type	A category of connections	"works_in", "depends_on", "hosts"
Property Definition	Attributes that instances can have	"budget" (number), "name" (text)
Allowed Connection	Rules for valid relationships	"Employee can 'work_in' Department"

Your M2 layer is essentially a domain-specific language for your business.

M1: Your Model (Instance Layer)

This is where you create actual things based on your M2 types:

M1 Concept	Description	Example
Node	A specific instance of a node type	"Engineering" (a Department)
Relationship	A specific connection	"Alice works_in Engineering"
Property Value	Actual data for an instance	budget = 500000

Your M1 layer is your actual model - the knowledge graph of your domain.

Node Types and Nodes

Node Types (M2)

A Node Type defines a category of elements. When you create a Node Type, you specify:

Name: What this type is called (e.g., "Department")
Properties: What attributes instances will have
Visual style: Color, shape (for diagrams)

Nodes (M1)

A Node is a specific instance of a Node Type. Each node has:

Name: The identifier for this instance (e.g., "Engineering")
Type: Which Node Type it belongs to
Property Values: Actual data for each defined property

Relationship Types and Relationships

Relationship Types (M2)

A Relationship Type defines a category of connections. It specifies:

Name: What this relationship is called (e.g., "works_in")
Properties: Optional attributes for the connection itself

Relationships (M1)

A Relationship connects two specific nodes:

Source: Where the relationship starts (e.g., "Alice")
Target: Where it ends (e.g., "Engineering")
Type: Which Relationship Type it uses (e.g., "works_in")

Allowed Connections

Allowed Connections are constraints that define which relationships are valid between which node types.

Why Constraints Matter

Without constraints, you could accidentally create invalid connections:

"Department works_in Employee" (backwards!)
"Server works_in Department" (wrong types!)

Defining Allowed Connections

An Allowed Connection specifies:

Relationship Type: Which relationship (e.g., "works_in")
Source Type: Which node type can be the source (e.g., "Employee")
Target Type: Which node type can be the target (e.g., "Department")

This ensures your model maintains structural integrity.

Properties

Properties are attributes that describe nodes and relationships.

Property Definitions (M2)

When defining a property, you specify:

Attribute	Description
Name	The property identifier (e.g., "budget")
Type	Data type: Text, Number, Boolean, Date, List
Required	Whether instances must have this value
Default	Optional default value

Property Values (M1)

Each node or relationship instance can have values for its type's properties:

Engineering (Department)
├── name: "Engineering"
├── budget: 500000
└── location: "Berlin"

Diagrams

Diagrams are visual views of your model. They don't contain the data - they reference it.

Key Concepts

One model, many diagrams: You can create multiple diagrams showing different aspects
Same node, multiple diagrams: A node can appear on several diagrams
Layout is per-diagram: Position and size are stored per diagram, not per node

Diagram Types

Overview diagrams: Show the big picture
Detail diagrams: Focus on a specific area
Type diagrams: Show your M2 metamodel structure

The Knowledge Graph

When you combine nodes and relationships, you create a knowledge graph - a connected network of information about your domain.

┌─────────────┐   works_in   ┌─────────────────┐
│    Alice    │─────────────►│   Engineering   │
│  (Employee) │              │  (Department)   │
└─────────────┘              └─────────────────┘
       │                              │
       │ manages                      │ part_of
       ▼                              ▼
┌─────────────┐              ┌─────────────────┐
│     Bob     │              │    Company      │
│  (Employee) │              │ (Organization)  │
└─────────────┘              └─────────────────┘

This graph can be:

Queried: "Who works in Engineering?"
Analyzed: "What's the total budget?"
Exported: To Neo4j, RDF, or other formats
Visualized: Through multiple diagram views

Real-World Analogy

Think of it like a database, but more flexible:

Database Concept	Metapad Equivalent
Table schema	Node Type
Column definition	Property Definition
Table row	Node
Foreign key constraint	Allowed Connection
Join/relationship	Relationship

But unlike a database, Metapad:

Has a visual modeling interface
Supports AI-assisted creation
Enables real-time collaboration
Focuses on graph relationships, not tables

Summary

Layer	Contains	Purpose
M3	System primitives	Defines what modeling constructs exist
M2	Your metamodel	Defines what's valid in your domain
M1	Your model	Contains your actual data

Understanding these layers helps you:

Design clean, well-structured models
Communicate with your team using consistent terminology
Leverage Metapad's full capabilities

Tip: Want to see these concepts in action? Explore the tutorial model in our gallery — it demonstrates node types, relationship types, allowed connections, and more.

Next Steps

Getting Started - Set up your first model
Tutorial - Build a complete model step by step
Template Gallery - See real-world examples