Making the Knowledge Graph of a building
In this section you will find examples of how to use the RealEstateCore ontology both as triplets (the foundation of semantic web technologies) and how we use it in a high capacity production environment with document oriented storage (using JSON or JSON-LD).
The data model of a building
First the data model of how we describe the buildings and its components.
The highest level in the hierarchy is RealEstate which consists of 1 or more BuildingStructure(s) and Land(s). RealEstate is the legal entity.
-
A BuildingStructure consists of one or more BuildingStructureComponents.
-
A BuildingStructureComponent can be: Room, Roof, Facade, VirtualComponent, etc.
-
A VirtualComponent is a BuildingStructureComponent that does not need to physically exist, but is useful to attach data to that are calculated or received from external sources (e.g. an energy meter reading from a utility company or a weather forecast).
-
Premises = a collection of Room:s or other spaces or objects that are leased to a tenant.
-
StoreyLevel = an (usually horizontally) aligned collection of BuildingStructureComponents.
Figure 1: Building data model.
RealEstate, Building,
and Location
The real estate’s name is “Great view estate”, it has been assigned an UUID (would look something like “8a9c11d9-60c8-4c37-bc47-b7b4f44e74d8”), let’s call it “EstateUUID”.
The main building on the real estate is called “Main Building” and it has also been assigned an UUID, let’s call it “MainBuildingUUID”. The second building is called “Annex Building” -> “AnnexBuildingUUID” (same for the land, etc. -> “LandUUID”).
Using RealEstateCore we can express these statements in RDF triplets as follows:
Figure 2: Real estate consisting of 2 Buildings and 1 Land.
EstateUUID isA RealEstate
EstateUUID hasPopularName “Great view estate”
LandUUID isA Land
LandUUID belongsTo EstateUUID
And defining that the “Main Building” and “Annex Building” are BuildingStructure:s and belongs to “Great view estate”:
MainBuildingUUID isA BuildingStructure
MainBuildingUUID belongsTo EstateUUID
MainBuildingUUID hasSourceDataPopularName “Main Building”
AnnexBuildingUUID isA BuildingStructure
AnnexBuildingUUID belongsTo EstateUUID
AnnexBuildingUUID hasSourceDataPopularName “Annex Building”
We can also specify that the “Great view estate” has a geographical location using WGS84 coordinates; latitude, longitude, altitude.
This could be the center of the land or a point of a main entrance, depending on the needed precision.
EstateUUID isLocatedAt "59.333239,18.061099,10"
And if we define a specific location (LocationUUID), i.e. the center of Stockholm, Sweden:
LocationUUID isLocatedAt "59.326242,17.8419709,11"
LocationUUID hasPopularName “Stockholm”
Figure 3: EstateUUID has a geo-location.
Then we can state that the “Great view estate” is placed (using the object property isLocatedIn) in Stockholm:
EstateUUID isLocatedIn LocationUUID
Using islocatedIn, an object instead of geographical coordinates are used.
Device, Sensor, and Actuator
We define a Device as a thing made or adapted for a particular purpose, specifically a piece of electronic equipment.
-
A Device has one or more Sensor(s) and/or Actuator(s).
-
A Sensor is a thing which detects or measures a physical property and records, indicates, or otherwise responds to it.
-
An Actuator is a component that is responsible for moving and controlling a mechanism or system.
Let’s assume that we have 1 Sensor that measures temperature and that it is placed in a conference room called “Great Meeting” in the outlet air vent:
First, let’s define the conference room:
RoomUUID isA BuildingStructureComponent
MainBuildingUUID hasBuildingStructureComponent RoomUUID
RoomUUID hasPopularName “Great Meeting”
The definition of the Device and Sensor and that it is placed in RoomUUID:
DeviceUUID isA Device
SensorUUID isA Sensor
SensorUUID isPartOf DeviceUUID
SensorUUID isLocatedIn RoomUUID
Next we define that the Sensor records temperature and that it is placed in an outlet air vent:
SensorUUID hasQuantityKind Temperature
SensorUUID hasPlacementContext SupplyAir
-
QuantityKind describes the value observed by a Sensor or the value used by an Actuator.
-
PlacementContext describes in what context or media that the Sensor or Actuator is operating in. E.g in the SupplyAir or the ExhaustAir flow.
Figure 4: A Device with 1 Sensor and 1 Actuator
Figure 5: A Sensor in a BuildingStructureComponent (e.g. a Room)
Crossing the chasm
Triplets-store to document-oriented-database
To take an OWL-ontology and direct deploy it in real production has its challenges. To mention a few:
-
Efficiency of triple stores in real-time production needs further development – certain types of queries can be prohibitively expensive, particularly if one wishes to maintain statement-level metadata (e.g., to tag each observation or piece of data separately with metadata about its source, access conditions, etc).
-
Semantic Web ontologies are built on an open world logic assumption, whereas most database systems and OO-based software development assumes a closed world logic. Certain types of operations (reasoning by default, etc.) are therefore difficult or costly to implement using ontology technologies.
-
Lack of off-the-shelf tools for large scale data integration and operation using ontologies and other semantic web technologies.
Our approach in developing and using RealEstateCore is to use and improve upon existing semantic web tools, but also to develop new tooling as needed to support our use cases. We do this in collaboration with the Semantic Web research community, and the tools we develop, like our ontologies, are released under free / libre licenses.
As of now, we are encoding and storing our data according to RealEstateCore in different types of data stores. We do not presently store our data in native RDF triple formats, but rather we expose our data as triples when needed.
If we would apply RealEstateCore to our example “Great view estate” using a document-oriented database it would be represented as two collections, RealEstates and BuildingStructures with one and three documents respectively (in JSON).
As triplets:
EstateUUID isLocatedAt "59.333239,18.061099,10"
EstateUUID hasPopularName “Great view estate”
As JSON:
{
"id": "EstateUUID",
"isLocatedAt": "59.333239,18.061099,10",
"hasPopularName": "Great view estate"
}
As JSON-LD:
{
"@context": "http://w3id.org/rec/core/2.2/",
"@id": "http://mydatanamespace/EstateUUID",
"isLocatedAt": "59.333239,18.061099,10",
"hasPopularName": "Great View Estate"
}
More examples of how RealEstateCore can be implemented as JSON and JSON-LD will come.