Change and hand off an ontology

When operational data changes, review the ontology definition, loading pipelines, and graph exploration conditions together. This final lesson separates edits that Portal supports in place from changes that require a recreated resource and a data migration.

Understand supported edits

A saved entity or relation exposes Overview, Attributes, Data, and History, but not every field remains editable.

Unsupported schema edits show a message explaining that removing or renaming a column, changing its type or nullability, or changing Identity Keys is not supported. The same restriction applies to an empty resource, so verify names, keys, and types before creation.

Practice extending the model

Assume a new maintenance_events dataset arrives.

1. In Modeling, create entity name iot_maintenance_event with alias Maintenance event.
2. Add id as Text, NOT NULL and select it for Identity Keys and Display Column.
3. Add the maintenance_events input and a transform or Code node to a Batch pipeline.
4. Connect iot_maintenance_event as an Entity output with Upsert.
5. Create relation iot_triggers from iot_machine to iot_maintenance_event.
6. Output these structural relation columns.

7. Confirm Ready and latest run Success for both pipelines.
8. Verify each resource's Data tab and the result in Graph Explorer.

Saving a definition does not create data. Keep repeatable loading in pipelines.

Hand a result to an analyst

Share the selected collection and exploration conditions as one reproducible bundle:

Collection: test1
Inspect: Sensor-to-machine relation
Expected result: 2 nodes, 1 relation
Starting item: relation iot_reads_from
Expansion order: select machine_001 → Expand neighbours
Properties: sensor_001.id, iot_reads_from.installed_at, machine_001.id

The analyst selects iot_reads_from in the same collection, then expands the same node to reproduce the result.

Hand an output contract to an engineer

There is no collection README editor for a detailed contract. Keep purpose and owning team in the collection Description, and maintain the detailed contract in team documentation or code.

Also record types, nullability, the Code run arguments, and returned keys. After a pipeline change, inspect both run success and the target Data tab.

Use the actual permission roles

Portal's resource roles are Owner, Editor, and Viewer in the UI. Their internal permission names are owner, writer, and reader.

• Modeler — Editor on ontology resources and loading pipelines they change
• Engineer — Editor on input datasets and loading pipelines, Viewer on ontology resources they inspect
• Analyst — Viewer on the collection and graph resources they inspect
• Permission administrator — Owner on collections whose membership and permissions they manage

Collection permission provides the basis for child-resource access. Grant only the minimum role required, and add a higher direct role only on a specific child when responsibility requires it.

Record the change

Use History on an entity or relation for its resource history. Also record intent, affected pipelines, the collection, starting item, expansion order, and rollback procedure in the team's change-management tool. Sidebar Recents is not a security audit log.

Course completion check

• Entities and relations use valid lowercase system names.
• Identity Keys and Display Column are configured.
• Entity and Relation rows were Upserted through real Batch pipelines.
• Results were verified in Data and Graph Explorer.
• Additive edits are distinguished from recreate migrations.
• Analysts and engineers can receive a reproducible contract.

You can now define a model, load its data, verify its graph, and hand off changes as one workflow.