Introduction

How to use RealEstateCore

What is an ontology?

RealEstateCore (REC) is an ontology, which can most easily be thought of as a standard and interoperable schema for building knowledge graphs; it defines the types of nodes you can have in your graph, the types of relations these nodes have with one another, and the types of data values associated with them. By using REC, you get two distinct advantages:

1. You do not need to spend a lot of time and resources on designing your own data model; we’ve already done it for you.
2. Your data is automatically compatible with that of other REC users (e.g., your suppliers or your customers), greatly simplifying data and process integration (doubly so if you also utilize the REC APIs to exchange data).

RealEstateCore was originally designed to be used with RDF-based knowledge graphs, and this is still the intended use of our SHACL version. However, RealEstateCore types and relations can equally well be described using one of the many property graph models available on the market, e.g., Neo4J, Apache TinkerPop, etc. In fact, the DTDL version of REC specifically supports the Azure Digital Twins platform, which does not use an RDF data representation. We find that translating between different graph formalisms is generally not a complex or time-consuming problem, as long as one has a well-described schema such as what RealEstateCore provides.

RealEstateCore Structure

The figure above illustrates the overall REC type structure, also listed below. Note that this a small introductory subset of the REC constructs; the browsable reference documentation contains a list of all types and all of their properties.

  • A Space is contiguous part of the physical world that has a 3D spatial extent and that contains or can contain sub-spaces. For example a Region can contain many Sites, which in turn can contain many Buildings, which in turn can contain Levels and Rooms. Note that we differentiate between spaces that are designed/architected (subtypes of Architecture) and spaces that are not; the former have a number of properties specific to constructed spaces.
  • A BuildingElement is a part that constitutes a piece of a building’s structural makeup, for example Facade, Wall, Slab, RoofInner, etc.
  • An Asset is an object which is placed inside of a building, but is not an integral part of that building’s structure. We provide a hierarchy of assests, for example architectural, furniture, etc. Our Equipment asset hierarchy is sourced from our collaboration with Brick Schema.
  • A Point indicates the capacity of an entity, be it an Architecture, an Asset, to produce or ingest data. The Point hierarchy is sourced from our collaboration with Brick Schema. Specific subclasses specialize this behavior: Sensor entities harvest data from the real world, Command entities accept commands from a digital twin platform, and Setpoint entities configure some capability or system, etc.
  • Collection covers administrative groupings of entities that are adressed and treated as a unit for some purpose. These entities may have some spatial arrangement (e.g., an apartment is typically contiguous) but that is not a requirement (see, e.g., a distributed campus consisting of spatially disjoint plots or buildings).
  • Agent describes any basic types of stakeholder that can have roles or perform activities, and is subclassed into, e.g., people, companies, departments.

RealEstateCore employs a set of design principles for how we wire up these types, including:

  • Parthood is described using the hasPart and isPartOf relationships. Instances of a type can only have other instances of the same type as parts; e.g., assets can only have assets as parts, spaces can only have spaces, and so forth. This provides a simple a consistent way for developers to navigate the building topology. To jump across these topologies (e.g., to indicate that an asset has a spatial location), other specific properties are used, see below.
  • Spatial location is described using locatedIn and isLocationOf relationships together with some Space instance.
  • Administrative parthood, i.e., membership in a Collection, is described using the outgoing Collection relationship includes.

Our APIs

In addition to providing the ontology itself, the RealEstateCore consortium also publish RESTful and message-oriented APIs intended to be used on the northbound and southbound edges of a smart building platform.

By adhering to these APIs, RealEstateCore-based smart building platforms are decoupled from building-specific or vendor-specific systems, allowing the development of a rich and dynamic ecosystem of services and products, and avoiding vertically integrated lock-in.

An example scenario

Our documentation provides a set of guides for different common digital twin modelling tasks. The picture below is taken from one of those guides, and illustrates how spatial modelling, equipment modelling, sensor modelling, and tenant modelling can be combined using RealEstateCore.

This example REC-based building graph can answer a variety of business-relevant questions supporting analytics, compliance, and operation, e.g.:

  • What’s the reported speed of the fan in the air handling unit feeding the bottom floor?
    • Is this reported speed diverging from the configured setpoint?
  • Where is the air handling unit that feeds Apartment 2 located?
  • What’s the temperature readings on the second floor?
  • What’s the reported occupancy rate of conference rooms leased by Initech?