In recent years, approaches to model di erent domains that interact in the IoT landscape are constantly emerging, such as the building information one, which includes related sensors, devices and appliances. The SAREF ontology represents a reference model for smart appliances, originally focused on the smart home domain. This work presents a SAREF extension for building devices as well as their location.
On the one hand, a more e cient interaction and integration of actors, methods and tools during the di erent phases of the building life cycle is being demanded in the Architecture, Engineering and Construction (AEC) and Facilities Management (FM) elds. Along its life cycle, multiple tools interact with building models to extract information for di erent purposes (e.g., energy demand, appliance characteristics, etc.). Therefore, there are missing mechanisms easing the data exchange between actors thorough the complete building cycle, along with tools for interoperability.
On the other hand, the quantity of things that are being made available
through the Internet is constantly growing1 carrying with them the inherent
heterogeneity and diversity of the IoT landscape. Given this situation, some
solutions embrace semantic technologies in order to alleviate interoperability
problems. In this sense, numerous ontologies have been de ned to cover the IoT
domain in many ways [
Undoubtedly, building related information and building objects play a crucial
role in IoT systems and applications due to the need for contextualising IoT
information. The ISO standard data model Industry Foundation Classes (IFC)
[
In this paper, a modular approach for transforming a subset of IFC concept is presented, being this fact the main characteristic of this work compared to existing e orts (Section 2). In particular, the paper will focus on the ontological requirements extraction (Section 3) and ontology implementation (Section 4) activities. Finally, an overview of the resulting ontology, identi ed as SAREF4BLDG, is provided (Section 5) before closing with some concluding remarks (Section 6). 2
Some of the rst attempts to semantic conversion, considering RDF technologies,
of IFC include the approach presented in [
While most of existing approaches aims at transforming EXPRESS le or the IFC model as a whole, and from an architectural point of view, in this work we focus on a modular approach. In this approach only devices are considered and the transformation method follows both automatic translation and modelling decisions based on ontology development patterns. In addition, this works aims at lling the gap between IFC architectural point of view and the IoT landscape, for what the transformation is linked to SAREF ontology. 3
Traditional techniques for ontology requirements elicitation include both the elicitation requirements from reference literature and documentation in the domain of interest and interviews with domain experts. In the particular of SAREF4BLDG no domain experts were part of the project partners, therefore the access to such a role has been restricted to acquittances and members of the AEC research community who disinterestedly answered questions, provided resources and acts as consultants with limited involvement.
The purpose of the SAREF4BLDG ontology is to extend the information of IFC models to include smart devices data annotations, focusing on: (a) the devices, including appliances, described in IFC and on their attributes; and (b) how to locate such devices in buildings.
It is not trivial to extract all the devices described within IFC4 as they do not belong to one unique hierarchy hanging from a top \Device" concept. IFC4 is organized by views and in each view several devices could be included. For example, the core speci cation contains transport elements as devices, the shared part of the speci cation contains shading devices and each speci c domain contains its own devices, for example actuators and alarms in the controls domain.
In order to select the subset of IFC4 relevant in the context of a SAREF extension, the boundaries of the concepts that would be included are delimited by the term \device", that is, every entity that can be classi ed as a device would be taken into account. In some cases, the concepts are easily recognised because the term `device" is included in the identi er, for example \shading device". However, in other cases, the description of the entities had to be reviewed in order to check whether the concept actually represents a device. For example, the IFC description of the term \Controller"2 reads as \A controller is a device that monitors inputs and controls outputs within a building automation system.".
In addition, some concept de nitions do not contain the term \device" as
part of their description but a hypernym of it. That is, they are a more speci c
type of device. In these cases, we have made use of WordNet [
After selecting the concepts of interest, the requirements were extended adding the properties de ned for such concepts. In this case not just all the properties de ned in IFC4 were added, some of them were discarded. More precisely, for all the devices selected the \Reference" property was discarded as it can be either mapped (a) to the element URI (in the sense of identi er) or (b) to a rdfs:label. The property \Status" has been also discarded as it indicates whether the element previously existed or is a new item in a retro tting project and that is out of scope of this SAREF4BLDG. The properties whose expected type is de ned as \P TABLEVALUE" were also discarded, for example the property \Spectrum". 4
In the rst step for transforming the extracted requirements to OWL, an owl:Class together with its additional information as shown in Listing 1.1 was created for each concept selected from the IFC documentation. For each class extracted from the IFC speci cation, rdfs:label and rdfs:comment annotations have 2 http://www.buildingsmart-tech.org/ifc/IFC4/Add1/html/schema/ifcbuildingcontrols domain/lexical/ifccontroller.htm 3 http://wordnet.princeton.edu/ been generated including the identi er and an excerpt of the de nition provided in the IFC online documentation. In addition, provenance information has been including using the PROV-O ontology.4 In our case, the property prov:hadPrimarySource is used to link each class with (a) the online document in IFC describing the concept and (b) the online document in IFC describing the properties de ned for such concept.
In order to create these classes, a CSV le containing all the devices selected from IFC, their description extracted from IFC, the URLs de ning the concepts and their properties were created. From this tabular data, mappings to RDF and OWL metamodels were created using OpenRe ne.5 More precisely for each row it was created: an owl:Class declaration (line 2 in Listing 1.1); an rdfs:label with the class name (line 3 in Listing 1.1); an rdfs:comment with the class de nition (line 4 in Listing 1.1); and as many prov:hadPrimarySource statements as URLs de ned for provenance (lines 8 and 11 in Listing 1.1). Finally, links to the https://w3id.org/ifc/IFC4 ADD1# ontology have been established by means of the property rdfs:seeAlso (line 14 in Listing 1.1)
Each class was then manually classi ed according to the hierarchy proposed in IFC6 under the corresponding class of the device's hierarchy (line 5 in Listing 1.1). In order to create this hierarchical structure the following consideration should be taken into account. IFC de nes the concept \Element"; however, this concept is too broad to be reused since it refers to devices and any other element that can appear in a building. This issue also appears in other levels of the hierarchy; for example, IFC de nes the concept \Distribution elements" which contains devices but also many other elements that are not devices. In this case we have created the class s4bldg:DistributionDevice in order to restrict the use to devices. This decision has been taken for the following classes: s4bldg:BuildingDevice, s4bldg:DistributionDevice, s4bldg:Distribution ControlDevice and s4bldg:DistributionFlowDevice. 1 ### Class d e f i n i t i o n 2 s4bldg : Compressor r d f : type owl : Class ; 3 r d f s : l a b e l " Compressor "@en ; 4 r d f s : comment "A compressor i s a d e v i c e that compresses a f l u i d t y p i c a l l y used i n a r e f r i g e r a t i o n c i r c u i t . "@en ; r d f s : subClassOf s4bldg : FlowMovingDevice ; 5 6 7 ### Provenance i n f o r m a t i o n f o r c l a s s d e f i n i t i o n 8 prov : hadPrimarySource <http : / /www. buildingsmart tech . org / i f c /IFC4/Add1 /html/schema/ ifchvacdomain / l e x i c a l / i f c c o m p r e s s o r . htm> ; 9 10 ### Provenance i n f o r m a t i o n f o r c l a s s p r o p e r t i e s 11 prov : hadPrimarySource <http : / /www. buildingsmart tech . org / i f c /IFC4/Add1 /html/schema/ ifchvacdomain / p s e t / pset compressortypecommon . htm> ; 12 13 ### Mapping to ifcOWL c l a s s e s 14 r d f s : s e e A l s o <https : / / w3id . org / i f c /IFC4 ADD1#IfcCompressor> .
Listing 1.1. Example of turtle code of a class de nition 4 https://www.w3.org/TR/prov-o/ 5 http://openre ne.org/ 6 http://www.buildingsmart-tech.org/ifc/IFC4/Add1/html/annex/annexc/common-use-de nitions/all.htm
For each class, its associated properties described in IFC have been transformed into object or datatype properties. IFC datatypes \logical", \boolean", \natural", \integer", \string", and \fstringg", have been transformed into datatype properties with ranges xsd:boolean, xsd:boolean, xsd:nonNegativeInteger, xsd:integer, xsd:string, and xsd:string, respectively. IFC datatypes \ratio", \real ratio", \normalised ratio", \positive ratio", and \Real" (associated to a P SINGLEVALUE), have been transformed into object properties that would link to an instance of saref:Measurement. The IFC datatype \Real" (associated to a P BOUNDEDVALUE) has been transformed into two object properties (one for maximum value and another for minimum value) that would be used to link to an instance of saref:Measurement. The IFC datatype \Complex" has been transformed into an object property with open range.
Taking into account such datatype transformations, an object property or datatype property is created for each property selected from IFC speci cation. It should be clari ed that a given property could be de ned for more than one concept in IFC, for example the property \refrigerant class" is de ned for the the concepts \compressor", \condenser", and \evaporator". In this case, one property is created for the energy source and a local axiom de ning a universal restriction is created for each class in which the property can be applied.
The naming of the created object and datatype properties is consistent with the naming used in IFC. More precisely, the names of the properties in the ontology are the names assigned in IFC transformed into \mixedCase" starting with lowercase. For example, the property \RefrigerantClass"7 has been transformed into the object property s4bldg:refrigerantClass.
Listing 1.2 shows the RDF code generated for the s4bldg:refrigerantClass datatype property and the local axiom for the such property de ned in the s4bldg:Compressor class. As it can be observed, the datatype property does not have a domain de ned as it can be applicable to more than one concept. Leaving the domain open allows the inclusion of more concepts in the ontology that could have that property, while de ning the domain as the union of the classes that can have that property when creating the ontology would not have been as sustainable solutions as the current one in case of extensions. 1 ### https : / / w3id . org / d e f / s a r e f 4 b l d g#r e f r i g e r a n t C l a s s 2 : r e f r i g e r a n t C l a s s r d f : type owl : DatatypeProperty ; 3 r d f s : range xsd : s t r i n g ; 4 r d f s : comment " R e f r i g e r a n t c l a s s used by the compressor . CFC: C h l o r o f l u o r o c a r b o n s . HCFC: H y d r o c h l o r o f l u o r o c a r b o n s . HFC: Hydrofluorocarbons . "@en ;
r d f s : l a b e l " r e f r i g e r a n t c l a s s "@en . 5 6 7 ### https : / / w3id . org / d e f / s a r e f 4 b l d g#Compressor 8 : Compressor r d f : type owl : Class ; 9 r d f s : subClassOf [ r d f : type owl : R e s t r i c t i o n ; 10 owl : onProperty : r e f r i g e r a n t C l a s s ; 11 owl : allValuesFrom xsd : s t r i n g 12 ] .
Listing 1.2. Example of turtle code of a local universal restriction axiom de nition 7 Property extracted from http://www.buildingsmarttech.org/ifc/IFC4/Add1/html/schema/ifchvacdomain/pset/pset compressortypecommon.htm 5
SAREF4BLDG is an OWL-DL ontology that extends SAREF with 72 classes (67 de ned in SAREF4EBLDG and 5 reused from the SAREF and geo,8 179 object properties (177 de ned in SAREF4EBLDG and 2 reused from the SAREF and geo ontologies), and 83 data type properties (82 de ned in SAREF4EBLDG and 1 reused from the SAREF ontology).
During the development of the SAREF4BLDG extension the Linked Open Terms9 lightweight methodology was followed. SAREF4BLDG has been made available according to the best practices for publishing ontologies in the Web10. The ontology is published implementing content negotiation mechanism under the persistent URI https://w3id.org/def/saref4bldg# and licensed under the Creative Commons CC BY 4.0 license.11
Figure 1 presents an overview of the classes and some general properties included in the SAREF4BLDG extension. As it can be observed the classes s4bldg:Building, s4bldg:BuildingSpace and s4bldg:PhysicalObject have been declared as subclasses of the reused class geo:SpatialThing in order to reuse the conceptualisation for locations already proposed by the geo ontology. The building objects (saref:BuildingObject) and building spaces (saref:Build ingSpace) model has been adapted from SAREF.
The modelling for measurements, depicted in Figure 1, represents an n-ary pattern that allows users to relate di erent measurements for di erent properties using di erent units. That is, the saref:Measurement class aims at describing a measurement of a physical quantity (using the saref:hasValue property) for a given saref:Property and according to a given saref:UnitOfMeasure.
The main contribution of this extension is the representation of the devices de ned in the IFC standard and their connections to SAREF. In this sense, a hierarchy consisting in 62 classes has been created taking into account the subset of the IFC hierarchy related to devices, as de ned in the buildingSMART documentation,12 and adding several classes to clarify its categorisation.
Figure 1 also shows the rst ve levels of the hierarchy (of the six total levels). Since transport elements (s4bldg:TransportElement) and vibration isolations (s4bldg:VibrationIsolation) are not classi ed under IFC elements, they belong directly to the class s4bldg:Device. The building elements are divided into s4bldg:ShadingDevice and s4bldg:DistributionDevice. In fact, most of the device types included in IFC belong to the distribution device category which contains the classes s4bldg:DistributionControlDevice and s4bldg:DistributionFlowDevice (the hierarchy under this last class is partially shown in the gure. 8 http://www.w3.org/2003/01/geo/wgs84 pos# 9 http://lot.linkeddata.es/ 10 https://www.w3.org/TR/swbp-vocab-pub/ 11 http://purl.org/NET/rd icense/cc-by4.0 12 http://www.buildingsmart-tech.org/ifc/IFC4/Add1/html/annex/annexc/common-use-de nitions/all.htm
As we can observe in Figure 1, some classes de ned in SAREF4BLDG are also de ned in the SAREF ontology, apart from the already explained s4bldg:Device. More precisely, this occurs in the classes s4bldg:Actuator and s4bldg:Sensor that extend the classes saref:Actuator and saref:Sensor, respectively. This decision has been taken because in the SAREF4BLDG extension these concepts refer to speci c sensors and actuators that are placed in or related to buildings. 6
One of the main obstacles when trying to reuse existing IFC translation into OWL is the lack of a modular approach in which a view of a speci c aspect is provided. In this work, the modularisation of a concrete type of elements has been carried out. As main lesson learnt, we can claim that extracting requirements in a systematic and consistent way is not a trivial activity even less with lack of domain experts as part of the project team.
It is worth noting that the translations into an OWL ontology should not be taken as a straight automatic process. Modelling decision according to best practices should be made both before and after the transformation process.
One important outcome of this work has been the impact of the resulting SAREF4BLDG on the SAREF ontology. For example, the concepts and properties related to building were moved to the SAREF4BLDG extension and the proposed model for measurements were adopted by SAREF in its second version.
Regarding future work, we can mention that the current list of building devices should not be considered exhaustive. It might be needed to extend the hierarchy in the case of new devices related to buildings are included in IFC or needed for a particular use case. It is expected that concrete use cases reuse the existing classes to represent their devices or specialise some classes to cover speci c device types (e.g., by creating a hierarchy of boiler devices under s4bldg:Boiler). Another example of this extension could be carried out by including those speci c devices provided as values of the property \type" in IFC. For example, the concept lamp could be further extended with subclasses as \ ourescent", \halogen", etc. according to the enumeration provided by the IfcLampTypeEnum property.13 In this case, domain knowledge would be needed, for example to be able to identify subtypes within the list provided by the property.