Ontology modeler's main work areas

Analysts build charts and dashboards from prepared data, while engineers own how data is produced and refreshed. The ontology modeler defines what that data means and how its objects connect.

D.Hub manages entities and relations in the Ontology area of the left sidebar. This lesson introduces the two surfaces and the core concepts used throughout the course.

Inspect the Ontology area

The Ontology section contains two menus.

1. Modeling — Create and edit entities and relations. After selecting a collection, use the Builder and List tabs.
2. Graph Explorer — Explore actual data loaded into the model. Select entities or relations in the left panel, or run Cypher in Query Console.

Remember these rules:

• Entities and relations are not individual leaves in the collection tree. Manage them under Ontology.
• One collection has one ontology scope. Creating a collection creates its ontology scope. Every entity and relation requires an owning collection_id; omitting it returns 422.

Ontology is the model that adds meaning to a collection's data, not an isolated utility.

Three building blocks

1. Entity — Represents a real-world object such as a customer, product, machine, or sensor. Rows are loaded by a pipeline's Entity output.
2. Relation — Represents a directed connection between two entities. It has Source, Target, and a system name such as purchased or iot_reads_from.
3. Entity schema metadata — Identity Keys identify entity instances, and Display Column supplies the node caption. Identity Keys are required for Entity Upsert and relation endpoint references. Relation rows instead Upsert by the system structural id column.

Map familiar vocabulary

Two distinctions matter:

• Model and instance surfaces are separate. Define structure in Modeling and inspect loaded instances in Graph Explorer.
• There is no separate Sink screen. Saving a model does not create instances. A pipeline must connect the target entity or relation as an output and run successfully.

Domain examples

The hands-on flow uses one manufacturing IoT scenario end to end and compares it with a larger retail model only when useful.

• Manufacturing IoT — small graph (3 + 2): entities iot_machine, iot_sensor, iot_maintenance_event; relations iot_reads_from and iot_triggers.
• Retail supply chain — larger graph (4 + 3): entities ri_product, ri_branch, ri_region, ri_supplier; relations ri_stocked_at, ri_located_in, ri_supplied_by.

Entity and relation names must be 1–63 characters, start with a lowercase letter or underscore, and contain only lowercase letters, digits, and underscores. IOT_Machine is rejected; use iot_machine.

Responsibility boundary

One person may hold multiple roles. This course focuses on decisions and verification from the modeler's perspective.

What to learn here

• The questions answered by Modeling and Graph Explorer
• Entity, Relation, and entity schema metadata
• Mapping from ER, Neo4j, and Cypher vocabulary
• One collection = one ontology scope
• The modeler's boundary with analysts and engineers

Next lesson

Next, open Modeling and create iot_machine with a valid lowercase name, attributes, Identity Keys, and Display Column.