Introduction

The Building Knowledge Graph

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 (classes) of nodes you can have in your graph, the types of relations (object properties) these nodes have with one another, and the types of data values (data properties) 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 is used with RDF-based knowledge graphs. There is a wealth of information about RDF available on the net, which we will not duplicate here; suffice to say that in RDF, a knowledge graph is made up of a (potentially very large) set of statements, each of which consist of three components: the subject of the statement, the predicate that captures what the statement intends to say about the subject , and the object that carries the value of that assertion. E.g., a graph might include the statement WhiteHouse ownedBy USGovernment, or IBM hasNumberOfEmployees 345900. Due to their structure, a statement is often known as a triple.

In the below we introduce some key REC classes and exemplify their use with RDF triples.

Key Classes

The figure above (borrowed from the DTDL port of REC) illustrates a subset of the key classes in RealEstateCore, which are described in greater detail below.

RealEstateCore employs a set of design principles shared across these classes:

• Parthood is described using the core:hasPart and core:isPartOf object properties. Restrictions are defined on top-level classes such that instances of these classes can only have other instances of the same class 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 core:hasLocation and core:isLocationOf object properties together with some core:Space instance.
• Administrative parthood, i.e., membership in a core:Collection, is described using the object properties core:includedIn and core:includes.
• To indicate that a capability or asset has a coverage or impact area (e.g., a camera covering a lobby, an HVAC unit covering an apartment), or other functional relation to some REC entity, we utilize the core:serves and core:servedBy object properties. These properties are at present comparatively ambiguous.

For exhaustive documentation, see the PyLODE docs.

Spaces

A core: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 pieces of Land, which in turn can contain many Buildings, which in turn can contain Levels and Rooms. This concept is comparable to a Zone in the BOT ontology.

:JU-E-Building rdf:type core:Building
:JU-E-Building-L1 rdf:type core:Level
:E2412 rdf:type core:Room
:E2412 core:isPartOf :JU-E-Building-L1
:JU-E-Building-L1 core:isPartOf :JU-E-Building

Building Components

A core:BuildingComponent is a part that constitutes a piece of a building’s structural makeup, for example Facade, Wall, Slab, RoofInner, etc.

Assets

A core: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 substantial hierarchy of assests, for example architectural, furniture, equipment, systems, etc.

Logical Device

core:LogicalDevice: A physical or logical object defined as an electronic equipment or software that communicates and interacts with a digital twin platform. A logical device could be an integrated circuit inside of a smart HVAC unit, or a virtual server running on a Kubernetes cluster. Logical devices can have Capability instances (through hasCapability) that describe their input/output capabilities. If Logical Devices are embedded within Asset entities (through the hostedBy property) such capabilities typically denote the capabilities of the asset.

APIs

RealE