About the ontology
The Mapped ontology is the vocabulary behind the Mapped graph: the classes an entity in a building, campus or portfolio can have, the properties each class carries and the relationships allowed between them. It is published as a machine-readable export, one definition per class, and these pages are generated from that export; nothing is hand-maintained per class.
The overview has the current number of classes, properties and relationships, and the classes per source.
Four sources
Mapped did not start from scratch. Classes come from four places, and the class's URI tells you which; the Source fact on each class page names it:
| Source | URI prefix | Notes |
|---|---|---|
| Mapped | https://mapped.com/schema/mapped/1.0/ (core#, openusd#) | Mapped's own classes: the meta layer, people and organizations, identities, the equipment, point and location classes Mapped adopted from Brick and RealEstateCore and publishes under its own URIs, the types Brick lacks, and the OpenUSD geometry classes |
| Brick | https://brickschema.org/schema/Brick# | Brick Schema classes used under Brick's own URIs, each linked to its upstream definition. The current export has none: the Brick classes Mapped uses are published under Mapped's URIs, and only their DTMIs (dtmi:org:brickschema:…) still say Brick |
| REC | https://w3id.org/rec# | RealEstateCore terms, each linked to its upstream definition: Agent, Organization, Company, Lease, Premises, SubBuilding, MezzanineLevel, Workspace, Desk |
| BACnet | http://data.ashrae.org/bacnet/ | The BACnet object types, see the BACnet guide |
An export without URIs (before version 1.87.19) shows the class's DTMI instead, and its prefix decides the source.
A class page shows its source in the title block and its URI under the name. The source says where a class's definition comes from, not where its parents do: Data_Center_Tenant is Mapped, its parent Organization is REC.
The root chain
There is one root, Meta, "a top-level meta class of all the concepts in Mapped". It carries the properties every vertex has: id, organizationId, exactType, dateCreated, dateUpdated and connectorIds.
Meta
├─ Class
│ ├─ Entity
│ │ ├─ Thing equipment, devices, vehicles, furniture
│ │ ├─ Point sensors, setpoints, commands, statuses, alarms, parameters
│ │ ├─ Place sites, buildings, floors, spaces, zones
│ │ ├─ Collection systems, loops, groups, portfolios
│ │ └─ Person, Agent, Account, Lease, Event, File, the BACnet objects, …
│ └─ Warranty
├─ Identity keys from other systems, attached with hasIdentity
├─ Address, PropertyBag, Property_Node, ExtendedProperty, Floor_Level
└─ Representation, Analytic_Shape, Spatial_Constraint, OpenUSD_* (geometry metadata)
Everything under Entity is a thing in the world or in the business; everything else under Meta is metadata about entities. The four big branches are joined by a small set of relationships: hasPart / isPartOf within Places and within Things, hasLocation from a Thing to exactly one Place, hasPoint / isPointOf from a Thing, Place or Collection to its Points, isHostedBy from a Point to the device producing it, and feeds / controls between Things.
Inheritance is multiple: many classes have more than one parent, and a class can reach the root by several distinct paths. A class page lists each path.
Deprecation and "replaced by"
Deprecated classes lists every deprecated class. A deprecated class still exists so that data already using it keeps validating, but new data should not use it. Its page carries a deprecation notice with, where the export provides them:
- Deprecated in Brick version: the Brick release that retired it, e.g.
1.3.0. - Replaced by: the class to use instead. AHU → Air_Handling_Unit; Staging_Zone → Staging_Area; Chilled_Water_Supply_Temperature_Sensor → Leaving_Chilled_Water_Temperature_Sensor.
Deprecated classes stay in the class tree and in search so that existing data can still be looked up.
Reading a class page
Each class page has the same parts, top to bottom:
- Title block: the display name, the source and the full URI, and the deprecation notice, if applicable, as above.
- Description: the definition as written in the ontology, and the Propose a change link.
- Hierarchy: parents, every inheritance path back to
Meta(the class sits under each of its parents in the sidebar, and the breadcrumb at the top of the page follows one of them), and direct subclasses with their descendant counts. - Facts: the URI, the source with the upstream link for Brick and REC classes, the Protobuf and GraphQL names, and the deprecation with the replacement class.
- Properties: name, schema (with enum values or object fields where they exist), required flag and default. The export flattens inherited contents into every class, so the page separates the class's own properties from inherited ones; most are inherited.
- Relationships: outbound relationships with their target classes, multiplicity and inverse.
- Referenced by: inbound relationships, the classes whose own relationships target this one.
Proposing a change
Every class page has a Propose a change link. It opens your mail client with a message to Mapped support ([email protected]), with the subject [Ontology] Change proposal: <class name>, and pre-filled with the entity name, its URI and the page link, and blank Proposed change and Reason sections. Use it for a wrong description, a missing class, a relationship that should exist, or a deprecation that should. The ontology is versioned as a whole, so accepted changes appear here at the next export.
How these pages are built
The pages are static. Each time the site is built, the ontology export is read once, indexed by id and name, and every class gets a page at /ontology/<Name>; display names are unique, so the name is the URL.