In this release

This is the first major version increment of ProptechOS (since 1.0) and the star of the show is the  RealEstateCore ontology strictly exposed as an API – using the ontology itself as specification. In fact Idun ProptechOS 2.0 is the first ever RealEstateCore API.

In adopting RealEstateCore as an API specification we have also jumped to the latest version, RealEstateCore v3.1.1, and we are using the specification produced by the Owl2OAS tool developed by Dr. Karl Hammar for RealEstateCore.

New functionality


GET endpoints return full JSON-LD ( with all properties referring to RealEstateCore (or ProptechOS extensions to RealEstateCore, see below).

(Json GET endpoints are deprecated)

Hydra API Classes

RealEstateCore is using Hydra ( to render the ontology as an API. Adopting RealEstateCore 3.1.1 and Hydra, we are using Hydra classes for API meta properties (e.g. hydra:Collection and hydra:Member classes for array responses and hydra:PartialCollectionView for pagination).

PUT endpoints for update

Following RealEstateCore and http convention, the POST method  is for creation of objects, while PUT updates an existing resource. (In the previous version both functionality was combined in the POST version)

DELETE endpoints

The DELETE method is now available using the api/resource/{id} path for the following resources:

  • aliasnamespace
  • buildingcomponent
  • device
  • realestatecomponent
  • realestate
  • sensor
  • storey

ProptechOS extensions to RealEstateCore

RealEstateCore is meant to be a starting point, open for implementations such as ProptechOS to continue. ProptechOS has our extension to RealEstateCore ( at


Individuals, like core:QuantityKind and core:PlacementContext are extended by ProptechOS. Also building:RoomType is extended by ProptechOS, as is intended by RealEstateCore – (with the same change, the new property RoomType has replaced the previous subclasses of Room in RealEstateCore v3.1


ProptechOS uses an advanced structure for aliases that are not available in the same way using RealEstateCore, or other existing Ontologies. For that purpose we have introduced our native classes proptechos:Alias and proptechos:AliasNamespace.

Additions promoted for adoption to RealEstateCore

For advanced presence modelling, Idun have created individuals that extend the presence affordances in RealEstateCore. QuantityKinds proptechos:AreaPresence and proptechos:Footfall, PlacementContexts proptecos:DirectionInward and proptecos:DirectionOutward and MeasurementUnit proptechos:NumPeople will be suggested by Idun as candidates for adoption in RealEstateCore v3.2 or v3.3.

Integrated Device registration

New in ProptechOS, Device registering is integrated. When creating a Device axiom, it is also registered in ProptechOS and a Key is stored in the ProptechOS KeyVault.

Breaking changes

Since the v2.0 API adopts JSON-LD and Hydra. All changes can be considered breaking.

Since moving from JSON to JSON-LD, the content type is changed (type=”application/ld+json” in the request headers)

We have kept non-JSON-LD versions of the GET endpoints with the “/json/” prefix. They are available to use until you have adopted a full JSON-LD client.

In addition, going from RealEstateCore 2.3 to 3.1 brings some changes that would be breaking, even if the response or payload formats would have been kept the same.

  • “BuildingStructure” is called Building in RealEstateCore 3.1
  • “BuildingStructureComponent” is called BuildingComponent in RealEstateCore 3.1 (Room is a subclass of BuildingComponent)
  • “StoreyLevel” is replaced by Storey in RealEstateCore. Storey is a subclass of BuildingComponent.
  • “AliasId” is now called “Alias”
  • “AliasIdNamespace” is now called “AliasNamespace”

Fixes and minor updated

Version 2.0 is about big changes and improvements… There are no notable fixes or minor updates :)