Itis acceptedin theLinkedDatafor ArchitecturaendConstruction(LDAC) community thatgenerating knowledgegraphs(KGs) from theBIM model of a buildingenableshigherleveluse cases such as integrationwithgeographicinformationsystems, operationaslystem integrations,emanticdigitaltwins (DTs), or automaticcompliancechecking.However,existingapproachesgeneratea large,monolithic knowledgegraphthatis difficulttointegratweithotherknowledgesuch as ThingDescriptions(TDs) of Internetof Things(IoT) devices,orinformationaboutofficeoccupantsandroom occupancyschedules.In thiswork,we describea setof threemodularknowledgegraphsthatenableknowledgeintegratiofnorthe semanticDT of ourbuildingatMinesSaint-Étiennel,everagingtheprinciplesof LinkedBuildingData:(1) KGLBD is automaticallgyeneratedfrom theRevitmodel of our building,(2) KGFOAF is semi-automatically generatedfrom theemployee directoryof Mines Saint-Étiennea,nd(3) KGTD is automaticallgyenerated from theETS5 projectfiledescribingtheKNX networkin our buildingusing theW3C TD ontology,and pointstoreal-timeandhistoricadlata.Our approachoffersan alternativweithrespecttothestateof the artsuchthat(:1) relevantbitsof thebuilding'sKG canbe accessedusing a simple REST-likeinterface, whereeachsmallKG containslinkstootherentitiesthatthemselvesareidentifiedby an IRI andhavea smallKG accessible(;2) Knowledgepotentiallsyervedby differentserverscanbe integrateidn thesame solution(;3) simple accesscontrolcanbe implementedforsome partsof theglobalKG.
In practice, however, modeling changes that occur over time in building design is complex
as one must define what elements are the same (with some changes) or completely4n].ew [
In addition, with DTs, one must be able to inject data specific to a device (such as a heater)
or property (such as a room temperature) from IoT devices and other sources into the BIM
model. The problem with this is that although BIM models are very useful, they were originally
designed to provide data only about the building in the design and construction phase, not
necessarily in the operation pha5s]e.A[ s such, there is no standard approach to use them in
dynamic situations as needed in a DT. Moreover, BIM data is largely fragmented depending
on the source of the dat6a],[thus to add data, it must be in a manner that allows this data to
be associated with the right domain and to be managed independently of the overall system if
needed. As a result, the use of Semantic Web technologies to aid this integration is becoming
popular. With the use of Knowledge Graphs (KGs), BIM models can become more useful by
integrating BIM data in KGs, or linking BIM data to KGs thus providing better contextual
information [
Even so, integrating BIM data and IoT data poses a new set of challenges due to the monolithic nature of most KGs. For one, the existing reasoning engines are unable to efectively process large-scale KGs because they load and compute them as a whole, as demonstrated by the authors of8[]. Modular design, or modularity in design, refers to a design paradigm where components work through a combination of distinct building blocks or modules to achieve an overall objective or functio9n]. [For the knowledge engineering domain, d’Aqui1n0][ describes modularity asway of designing graphs to support maintenance and re-usability by the combination of self-contained, independent, and reusable knowledge components.
This necessitates the need for ways to use subsets of KGs or more simply the use of modular design in knowledge engineerin1g1[]. To this end, this work presents a framework to integrate BIM with data from external sources such as IoT devices, and manually curated knowledge in a modular manner. Backed by Linked Data (LD) principles, this work is motivated by a vision of a building of the future where all information is encoded such that information can be gotten from the IFC model of the building, sensors, and actuators stationed at various parts of the building, and other sources, such that every single element in the building is interconnected to enable faster data exchange and visual monitoring of user comfort parameters as well as room occupancy in real-time.
In this paper we propose and discuss an approach that is based on a large set of small, linked KGs. Our primary research problem centers on how to integrate BIM models in the IFC format with data from external sources such as IoT device configurations and live IoT data, and manually curated KGs, in a modular manner, improving overall system performance in DTs. We focus on the following research question: Could modular graphs facilitate knowledge integration in the semantic DT of a Smart Building?
We demonstrate the benefits of our approach on the semantic DT of our smart building at Mines Saint-Étienne. The rest of this work is structured as follows. 2Sercetciaolnls some background on the linked data principles, modular design, the Building Topology Ontology (BOT), and the WoT Thing Descriptions (TDs). Sect3iopnresents some related work, then Section4 describes the Espace Fauriel building of Mines Saint-Étienne. S5ecptrieosnents our proposed approach, preliminary results, and a demonstration use case. 6Sedcitsciounsses the benefits of our approach, and Sectio7nconcludes the paper.
The modern idea of linked data is based on the linked data principles presented by Tim BernersLee in a design issue not1e: 1. Use URIs as names for things, 2. use HTTP URIs so that people can look up those names, 3. When someone looks up a URI, provide useful information, using the standards (RDF,
SPARQL), 4. Include links to other URIs, so that they can discover more things.
The W3C Linked Building Data community group (LBC-CG) brings together experts in the area of BIM and Web of Data technologies, who are working to address the challenge of managing the huge amount of data that is generated across the building life cycle. They propose to adapt the linked data principles for building-related data as follows: 1. Using URIs as names for building-related things such as: rooms, walls, products, elements, enable diferent parties to provide complementary descriptions of the same uniquely identified entities in diferent knowledge graphs. 2. Using HTTP URIs for these things enables the authority responsible for these URIs to provide reference information about this entity when one looks it up on the Web. For example, products in a catalogue, building appliances, or even the building itself. 3. Providing information using common standards (RDF, SPARQL) and common KG models enable semantic interoperability between data sources. 4. Include links to other URIs can help to discover more things, such as a link to the catalogue an appliance has been chosen from, or a link to the Web of Things Servient that enables it to interact with this appliance.
This group’s flagship result is the Building Topology Ontology (BO1T2]),[an ontology that provides a high-level semantic description of the topology of buildings including storeys, spaces, and the building elements they contain.
The W3C Web of Things (WoT) Working Group seeks to counter the fragmentation of the
IoT through standard complementing building blocks (e.g., metadata and APIs) that enable easy
integration across IoT platforms and application do2mTaDinss.[
In this section, we present a brief review of works related to the conversion of IFC models to
KGs and integration with IoT data.
3.1. IFC to KGs
Although there aren’t many ontologies that adequately cover the scope of IFC,1i4fc,O15W]L [
is a game changer. Introduced in 2009 by Beetz et. al., ifcOWL is a direct mapping of IFC express
schema into OWL thus, it has the same status as IFC’s EXPRESS and XSD schemas. A downside
however is that the graphs produced by the ifcOWL mapping are complex in terms of structure
and size [15]. [
The IFC-to-LBD converter17[, 18] generates a lighter KG from an IFC file using the ontologies
from the LBD-CG group. After conversion, important information about the building such as
topology, elements classification e.g Wall, Space, etc, and their properties are saved in one to
three large graphs. When compared to the output of the ifcOWL-based IFC-to-RDF converter
[19], the graph structure becomes more concise (minimum 83% fewer triples) and substantially
simpler to query.
3.2. IoT + BIM
Since IoT devices are fundamental in the Operation phase of a Smart Building lifecycle, there have
been a number of studies centered around the integration of IoT data with BIM information. Tang
et. al. 2[0] reviewed several methods of integrating building contextual data and time-series data
generated in the IoT layer. Their work showed that an eficient approach would be to represent
the building contextual data and sensor information as an RDF graph and also serialize
timeseries data from IoT devices into another RDF graph. The final step of this approach is to then link
both graphs using unique identifications. The architecture of this method is shown in1.Figure
Based on the knowledge from
[20], the same researchers
went on to develop a
hybrid approach to facilitate
information exchange between
BIM-based building data,
timeseries data generated from
the IoT devices (in a
relational database), and
Building Automation System (BAS)
metadata using Semantic Web
Technology 2[
Donkers et. al. 2[
Figure 2: Workflow of DT using WoT TDs (Source: [22]) Although their approach proved effective in collecting occupant feedback as intended, it made use of a monolithic KG.
Similarly, to improve indoor condition monitoring, Desogus et2.4a]lp.r[esented a data platform for the visualization of building indoor conditions (e.g., temperature, luminance, etc.) and energy consumption parameters. It was tested using a case study in Italy. Their approach integrate the Revit software with the Dynamo visual programming platform and a specific API.
Cimmino et. al. 2[
In order to support real-time data integration and dynamic decision-making in Asset Management (AM) applications, Moretti et.2a6l]. p[resented an openBIM methodology that makes use of the IfcSharedFacilitiesElements schema to process and integrate geometric and semantic information of existing and newly created IFC objects. The approach incorporates data from the BIM environment, IoT platform, and Building Management Systems to support the asset management team’s workflows and operations during the asset’s use phase. For improved interoperability and cross-platform use, the technique was built utilizing open-source software and IFC. The case study showed how the suggested strategy could support an asset anomaly detection application and boost digital AM automation.
5
Mines Saint-Étienne, built around 1920 by mail-order selling company Manufrance and re-empowered in 1994 for the Mines Saint-Étienne higher education institute, is an eight storeys building of 6720 m2 used for research and teaching. It includes lecture halls, classrooms, ofifces, meeting rooms, and a space iflled with industrial robots and workshops called thITe’M Factory.3 The 3D model of the EF building is made available under the CC-by 4.0Figure 3:Espace Fauriel Building of Mines Saint-Étienne license as Revit (137 MB), IFCv4 (186
4 MB), and Xeokit (12 MB).
The Building Management System consists of an historical EIB bus (European Installation Bus, which became KNX ISO-IEC 14543-3) installation for controlling HVAC and alarm systems, and several IoT devices deployed to monitor comfort parameters such as humidity, temperature, luminosity, CO2, windows opening status. In addition, smart meters are deployed to measure the electric consumption at the level of storeys, and at the level of a few individual equipments. Sensor data is published in real time to an MQTT broker, and a subset of the historical data is made publicly available under the CC-by 4.0 lic5ense.
Our approach aims to interlink three diferent KGs: (1L)BKDGis automatically generated from the Revit model of the building, and describes its topology and static properties using the BOT ontology; (2) KGFOAF is semi-automatically generated from Mines Saint-Étienne’s employee directory, and uses identifiers from KLGBD to link employees to their ofice and the desk they work on; (3) KGTD is automatically generated from the ETS5 project file, and describes the configuration of KNX sensors and actuators using the TD ontologFyO.AKFGuses identifiers from KGLBD, KGLBD uses identifiers from KGTD, and KGTD describes means to access the real-time and historical IoT data. Fi4guilrleustrates the general methodology of our approach, which we detail in the rest of this section. The knowldege graphs are served as static files by an Apache 2 server, and have the following entrypohinttps:s://ci.mines-stetienne.fr/emse/ for the LBD graphh,ttps://ci.mines-stetienne.fr/knfoxr/ the KNX configuration graphh,ttps: //ci.mines-stetienne.fr/mqtfto/r the historical IoT data as CSV files. 3IT’M Factory: Virtual vishittps://itm-factory.fr/index.php/objectif_et_visite_360/ 43D model of the EMSE EF buildinhgttps://ci.mines-stetienne.fr/EMSE_EF/ 5Raw data for smart meters and heating devhitctepss://ci.mines-stetienne.fr/mqtt/ Crawl employee data working in the
Espace Fauriel building
<< manual step >>
Link employee to furniture Serialize one graph per individual
Serialize one graph per individual links to
links to links to links to links to
KNX network configuration in ETS5
Export .knxproj file
Analyse XML project file For each device, find and analyse hardware description in XML.
Generate TD Thing description for devices, their properties, and their communication objects Generate property affordances for group addresses Generate forms for KNX, MQTT, and historical data as CSV over HTTP Revit model with KNX electric appliances
Employee directory of Mines Saint-Étienne Export IFC IFC-to-LBD Repare unicode Prune objects Transform RDF
Update IRIs
Export schedules and Dynamo script results: 1. device and furniture locations, 2. doors and windows to/from locations, 3. physical quantity values (geom., therm.) 4. Adjacency between rooms Add schedules and Dynamo script results
Include SOSA/SSN properties
Serialize one graph per individual
To prepare the linking of KLBGD to KGTD, a ’KNX Device’ family is created in Revit, and elements are positioned in diferent spaces and are given a KNX address parameter as shown on5F. igure The Revit model is first exported to IFC, then converted to RDF using the IFC-to-LB6D tool. This results in a large 256k triples graph that is unsatisfactory for our use cases, which justifies the following sequence of post-processing steps, implemented as python scripts. The sources of our post-processing scripts and instructions to re-generLaBtDeaKrGe openly availab7le. 6Settings for the conversion are describehdtitnps://github.com/maximelefrancois86/databat-kgc-revit/tree/main/rvt 7https://github.com/maximelefrancois86/databat-kgc-revit 1_repareCharacters.py. Wrongly encoded Unicode characters are restored. For example: ”\n” was encoded as ”\\X\\0D\\X\\0A”, ”é” was encoded as ”\\X\\00E9\\X\\0A”. 2_pruneObjects.py. We only need a few type of elements for our use case. This step keeps triples with RDF terms whose IRI contain one of: ”site”, ”building”, ”storey”, ”space”, ”wall”, ”window”, ”ifcowl_ifcfurniture”, ”electricappliance”. It prunes triples with RDF terms whose IRI contain one of ”airterminal”, ”beam”, ”cablecarrierfitting”, ”cablecarriersegment”, ”column”, ”covering”, ”curtainwall”, ”ductfitting”, ”ductsegment”, ”flowterminal”, ”ifcowl_ifcopeningelement”, ”lightfixture”, ”member”, ”plate”, ”railing”, ”ramp”, ”roof”, ”slab”, ”stair”, ”stairflight”. The total number of triples after this step is 129 k. 3_transformObjects.py. This step re-generates a KG by executing a set of SPARQL construct queries that select a subset of the triples and replace properties. For example the following properties had the same literal objepcrtops:s:familyAndType_simple, props:family_simple, props:objectTypeIfcObject_attribute_simple, props:typeId_simple, props:type_simple.
Only one is kept and we use properrtdyfs:label instead. Output contains 28,5 k triples. 4_renameObjects.py. IRIs were all under the sa minest: namespace, their local name is made of a type name and a UUID. This step establishes a more natural IRI structure that reflects the organisation of the building. For exam<p{blueilding}>, <{building}/{storey}>, <{building}/{storey}/{space}>, <{building}/{storey}/{space}/{knx_device_in_space}>. 5_readSchedules.py. This step generates triples from the Revit schedules and the output of Dynamo scripts, which are exported as CSV files. Its goal is to recover important knowledge that was lost somewhere in the Revit-to-IFC-to-LBD pipeline: (i) in which space furnitures and devices are located, (ii) which spaces windows and doors are adjacent to, (iii) adjacency between spaces, (iv) quantity values for properties were floored to the nearest integer, with no unit. The total number of triples after this step is 50 k. 6 _addProperties.py. This step explicits some SOSA/SSN Properties for spaces and elements, which are useful for some of our use cases. For example each space is associated a temperature, CO2, and humidity property. Each door and window is associated an open/close status. The total number of triples after this step is 53 k. 7_storeTurtleFiles.py. Finally, this step iterates over the resources in the KG, automatically extracts a small number of triples that describe each resource, and serializes these small RDF graphs in Turtle files named after the resources’ IRIs.
KGLBD contains a total of 4.414 RDF graphs, with 19,64 triples per graph on average. The total number of triples contained in those graphs is 86.686 while the number of triples in the non-modularized graph is 52.979. Two triples per graph are just metadata, this means that 24.879 triples are duplicates and are useful to help clients navigate in the knowledge graph. The set of static RDF documents are served by an Apache 2 server with the URLbootf:Stihteeas an entrypointh:ttps://ci.mines-stetienne.fr/em.seL#isting1 shows an excerpt of the graph that describes Ofice 416. Table 1 lists the number of instance (and graphs) for each main class, and gives an example one can access. <emse/fayol/4ET#> a bot:Storey ; bot:hasSpace <emse/fayol/4ET/416#> . <emse/fayol/4ET/416#> a bot:Space ; rdfs:label "416" ; rdfs:comment "Office" ; skos:hiddenLabel "2IRRGeGVD4mwnjuD6Rcm6i" ; bot:adjacentElement <emse/fayol/4ET/door/1VMOlJ3knDeODu7af36Nwh#>, ... ; bot:adjacentZone <emse/fayol/4ET/418#>, <emse/fayol/4ET/waiting-area#>, ... ; bot:containsElement <emse/fayol/4ET/416/device/1bDMdL0k55X8oOMH5VKzRL#> , ... ; coswot:canWalkTo <emse/fayol/4ET/418#>, <emse/fayol/4ET/waiting-area#>, ... ; coswot:hasAreaStableValue "20 m2"^^cdt:ucum ; coswot:hasTemperatureProperty <emse/fayol/4ET/416#temperature> ; ...
Listing 1:KGLBD sample: excerpt of the RDF document availablhetattps://ci.mines-stetienne. fr/emse/fayol/4ET/416. Note 1: the coswot vocabulary is under development. Note 2: base and namespace declarations are shared by listings.
Knowledge graph KGFOAF is the result of crawling the Mines Saint-Étienne employee directory, generate a small RDF graph for each employee that works in the EF Building, and identify them with obfuscated IRIs for privacy reasons. As an additional manual step, each employee is linked to the desk it works at, using IRIs fromLBKDG. At the exception of a few, access to all RDF graphs in KGLBD requires authentication. Ta2bliests the number of instances inFKOGAF. Listing2 is an example of an openly accessible RDF graph inFOKAGF. <foaf/b54952c3-e4a6-423d-b724-ed9392f6f2a1> a foaf:Document ;
foaf:primaryTopic _:person . _:person a foaf:Person ; foaf:name "Xxx Xxx" ; foaf:img <data:image/png;base64, /.....> ; foaf:phone <tel:+xxxxxxxxxxx> ; foaf:mbox <mailto:xxxxxxxxxxxxxxxx@emse.fr> ; org:memberOf <https://www.imt.fr/>, <https://mines-stetienne.fr/>, <foaf/fayol> ; coswot:worksAtDesk <emse/fayol/4ET/416/BureauD'Angle/1VMOlJ3knDeODu7af36LS_#> .
Listing 2:KGFOAF sample: RDF document available ahtttps://ci.mines-stetienne.fr/foaf/ b54952c3-e4a6-423d-b724-ed9392f6f2a.1 Note 1: the coswot vocabulary is under development. Note 2: base and namespace declarations are shared by listings.
Devices in a KNX network are identified with a two bytes address, which defines some topology for the network. The first four bits is the Area, the next four bits is the Line, and the remaining eight bits is the Bus Device. For example the selected KNX Device on F5iginurOefice 416 has address 1/2/184. Devices have some configurable properties and communication objects that may be readable and/or writable. Communication objects of devices are linked by socalled group addresses, which are also encoded on two bytes, and are used in read/write KNX messages. Group addresses may be displayed with a 3-level structure 5 bits/3 bits/8 bits, and are how messages are passed from communication objects of sensors to communication objects of actuators. For example group address 2/0/117 links Object O-12 of Device 1/2/185: the output command of a Hager TX320 room thermostat deployed in Ofice 423, with Object O-140 of Device 1/2/171: one the controllable relays of a Hager TYA608C 8x16A Output module (which controls the heater in Ofice 423).
The first step to generate KTGD is to export the ETS5 configuration project to a 1.MknBxproj ifle, which is an archive that contains multiple XML files, including a 7 K lines XML project ifle, a 450 lines XML hardware description file, and 42 hardware XML definition files. We then automatically extract from these files relevant bits of information about the KNX network: the KNX topology, devices properties and communication objects, and the list of group addresses.
Devices are modeled as instancestdof:Thing, and each property and communication object is modeled as atd:PropertyAfordance . Each property afordance is further described as a js:DataSchema using the JSON Schema in RDF vocabula8ryG. roup addresses are also modeled as td:PropertyAfordance and are wheretd:Forms are defined: Each form describes how a certain operation can be made to interact with the property. These forms are shared by diferent property afordances using a propertcoyswot:sharesFormsWith we introduced. coswot:sharesFormsWith a owl:SymmetricProperty, owl:TransitiveProperty . td:hasForm owl:propertyChainAxiom ( coswot:sharesFormsWith td:hasForm ) .
There are three kinds of forms currently defined inTDK:G1. KNX forms use a proposed knxip:// URL scheme for KNX/IP addresses, where the host and port are those of the KNX/IP gateway service, and the path defines the group address to read or write. They also use a proposedcoswot:KNXMethodName property we introduced to define if the address needs to be read or written to. 2. MQTT forms use the MQTT vocabulary for RDF (mqv), which is under development9. 3. HTTP forms to access the historical data as CSV files. As these files have a diferent schema (an array of objects with value and timestamp properties), we choose to define separate property afordances for them. The sources of our post-processing scripts and instructions to re-generateLBKDGare openly availab1l0e.Listing4 shows how the current and historical temperature values of Ofice 416 are described. <1/2/184> a coswot:Device, td:Thing ; 8JSON Schema in RDF vocabularhyttps://www.w3.org/2019/wot/json-schema 9MQTT vocabulary for RDF h-ttps://www.w3.org/TR/wot-binding-templates/ 10https://github.com/maximelefrancois86/databat-kgc-knxproj <ga/3/0/27> a coswot:KNXGroupAddress, td:PropertyAffordance ; rdfs:label "T° amb secrétariat N4" ; skos:hiddenLabel "3/0/27" ; coswot:sharesFormsWith <1/2/184#O-10> ; td:hasForm [ hctl:forContentType "text/plain" ; hctl:hasOperationType td:observeProperty ; hctl:hasTarget <mqtt://193.49.165.40:1883> ; mqv:controlPacket "subscribe" ; mqv:filter "emse/fayol/4ET/416/temperature/current" ], [ coswot:KNXMethodName "read" ; hctl:hasOperationType td:readProperty ; hctl:hasTarget <knxip://195.83.140.67:3761/1/8/27> ] . <ga/3/0/27#history> a js:ArraySchema, td:PropertyAffordance ; coswot:sharesFormsWith <1/2/184#O-10-history> ; js:items [ a js:ObjectSchema ; js:properties [ a js:NumberSchema ; js:propertyName "value" ],
[ a js:StringSchema ; js:propertyName "timestamp" ] ] ; td:hasForm [ htv:methodName "GET" ; hctl:forContentType "text/csv" ; hctl:hasOperationType td:readProperty ; hctl:hasTarget <https://ci.mines-stetienne.fr/mqtt/emse/fayol/4ET/416/temperature/
current/log.csv> ] .
Listing 4:Current and historical temperature afordances for Ofice 416. Note 1: the coswot vocabulary is under development. Note 2: base and namespace declarations are shared by listings.
The generated RDF graph contains a total of 40.721 triples, which are then distributed in 1.043 graphs with an average of 53,3 triples per graph, totalling 55.556 triples (36% redundancy). Static RDF documents in KLGBD are served by an Apache 2 server, with entryphotinttps: //ci.mines-stetienne.fr/kn.Lxistings5 shows an excerpt of how the KNX device 1/2/184 is linked to from KGLBD. <emse/fayol/4ET/416#> bot:containsElement <emse/fayol/4ET/416/device/1bDMdL0k55X8oOMH5VKzRL#> . <emse/fayol/4ET/416/device/1bDMdL0k55X8oOMH5VKzRL#> a bot:Element,
coswot:Device ; rdfs:label "KNX Device:Thing" ; owl:sameAs <knx/emse/fayol/1/2/184> ;
Table1 lists the number of instance (and graphs) for each main class, and gives an example one can access. The MQTT broker (Mosquitto) and the KNX/IP gateway are only available when connected to the building’s network. The CSV logs are openly available under the CC-by 4.0 license1.1 These logs include the history of the outside temperature, ofices temperatures, room thermostat setpoint commands, and room thermostat acknowledgement messages. Note that there exists a proposal for a KNX ontolhotgtyp://schema.knx.org/2020/ontology/, however in this work we wanted to abstract from KNX and therefore rather used the W3C TD ontology. 5.4. Demonstration Use Case: Comfort parameter monitoring To illustrate the combined use of the three KGs, this section describe acsocmenfoarrtipoarameter monitoring. Preliminary demonstrations of tThereritoire Databsactenario are available onl12in.e
An employee of Mines Saint-Étienne, Marie-Line, works in room 416 of the EF building. She logs in theTerritoire Databpaltatform, and the camera point of view directly jumps to the center of her desk. She can then navigate in the 3D model using the arrow keys, step in front of the box that represents the KNX Device next to her ofice door, click on it, and visualize the current and historical state of the room thermostat. As she is registered as the user of this ofice, she can select a diferent setpoint, or request a change in the temperature setpoint.
In practice, this scenario only requires the Territoire Databat server to enable authentication, and after a successful login send to Marie-Line’s browser the URL of the grFOaApFh1 G that describes her in FKOGAF. The client may then download and parFsOeAGF1. It can then dereference the object of tchoeswot:worksAtDesk property, and obtain graphLBGD1 with the IfcGUID of the furniture, and a link to the ofice it is an element of. The client can use the IfcGUID to determine the XYZ coordinates of the center of the desk. When Marie-Line clicks on the KNX Device on the wall, the client can dereference its URL, a) check it is located in Marie-Line’s ofice, and b) fetch the graphTGD1 in KGTD that describes the device. FromTDG1, it can find more graphs and ultimately obtain the forms it can use to visualize the history of the temperature in the room and the thermostat setpoints. 11Raw data for smart meters and heating devhitctepss://ci.mines-stetienne.fr/mqtt/ 12Demo: https://ci.mines-stetienne.fr/ldac2023/demo/demo1.m-ph4ttps://ci.mines-stetienne.fr/ldac2023/demo/ demo2.mp4
Although other studies had worked on BIM modeling using semantic web approaches, we propose to use modular knowledge graphs which we believe has several benefits compared to using monolithic graph architectures. Modular graphs allow merging independently developed KGs into a single one that is easier-to-understand, better to reason with, and also reusable as demonstrated in27[]. In addition, when integrated with real-life systems, modular graphs improve performance by loading only the needed segments, eliminating problems with querying and reasoning in large stores.
Thus, in contrast to the other works that used mono1l5it]hoirc s[emi-modular 1[
Serving static documents with an Apache 2 server is more scalable than exposing SPARQL endpoints, and this is also better aligned with the vision of a hypermedia-driven Web and the Web of Linked Data. True, more processing is required on the client side to fetch and parse multiple smaller RDF documents, and query the subset of the graph that has been fetched at any given point in time. On the other hand, the application gains responsivity as little data is needed when the application starts.
Our motivation may be positioned with respect to the Linked Data Fragments sp2e8c]t,rum [ where on one far end the server bares all the query processing work, and on the other far end the client downloads the whole graph as a dump and que1r3ieAsritg.uably, our approach applies to KGs what tilemaps apply to 2D or 3D game development: the global KG is made out of small, regular-shaped graphs that we coulLdBcDaKllnowledge Tiles, which results in performance and memory usage gains.
We have presented a methodology to integrate diferent knowledge graphs so as to contribute to the building’s semantic Digital Twin vision. Our approach has been implemented on the Espace Fauriel building of Mines Saint-Étienne, and results in the creation of a set of resources that may be useful for other researchers in the community. As for future work, we aim to improve the knowledge graphs with more knowledge useful for doing thermal simulations of rooms, serve live and historic IoT data as RDF using the SOSA/SSN ontology, serve live data with MQTT over websocket, further develop the 3D visualization platform shallowly demonstrated 5in.4,Section and experiment with autonomous agents in this virtual environment. 13Linked Data Fragmentsh-ttps://linkeddatafragments.org/
This work was partially funded through the following projects: HyperAgents (grant ANR19-CE23-0030-01), CoSWoT (grant ANR-19-CE23-0012-04), ACCORD (Horizon Europe R&I programme grant agreement no. 101056973). [14] J. Beetz, J. van Leeuwen, B. de Vries, Ifcowl: A case of transforming express schemas into ontologies, AI EDAM 23 (2009) 89–101. do1i:0.1017/S0890060409000122. [15] P. Pauwels, W. Terkaj, EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology, Automation in Construction 63 (2016) 100–133. [16] P. Pauwels, A. Roxin, Simplebim: From full ifcowl graphs to simplified building graphs, in: eWork and eBusiness in Architecture, Engineering and Construction, CRC Press, 2017, pp. 11–18. [17] M. Bonduel, J. Oraskari, P. Pauwels, M. Vergauwen, R. Klein, The ifc to linked building data converter-current status, in: Proceedings of the 6th Linked Data in Architecture and Construction Workshop (LDAC 2018), volume 2159, CEUR Workshop Proceedings, 2018, pp. 34–43. [18] J. Oraskari, M. Bonduel, K. McGlinn, P. Pauwels, F. Priyatna, A. Wagner, V. Kukkonen, S. Steyskaland, J. Lehtonen, Ifctolbd, 2023. UhRtLt:ps://doi.org/10.5281/zenodo.7701792. doi:10.5281/zenodo.7701792, If you use this software, please cite it using the metadata from this file. [19] P. Pauwels, L. J. McGibbney, B. Thurm, G. Velludo, pipauwel/ifctordf: v0.4, 2020. URL: https://doi.org/10.5281/zenodo.4008032. do1i0:.5281/zenodo.4008032. [20] S. Tang, D. R. Sheldon, C. M. Eastman, P. Pishad-Bozorgi, Z. Gao, A review of Building Information Modeling and the Internet of Things devices integration: Present Status and Future Trends, in: Automation in Construction, BCS-HCI ’08, British Computer Society, Swinton, UK, UK, 2019, pp. 13–22. [21] S. Tang, C. Zhang, J. Hao, F. Guo, A Framework for BIM, BAS, and IoT Data Exchange
Using Semantic Web Technologies, in: Construction Research Congress 2022, 2022. [22] M. Kuller, F. Kohlmorgen, N. Karoglan, M. Niemeyer, I. Kunold, H. Wohrle, Conceptual design of a Digital Twin based on Semantic Web Technologies in the Smart Home context, in: IEEE work shop, CANDO-EPE 2020, British Computer Society, Swinton, UK, UK, 2020, pp. 167–172. [23] A. Donkers, B. de Vries, D. Yang, Creating occupant-centered digital twins using the Occupant Feedback Ontology implemented in a smartwatch app, Semantic Web (2022) 1–26. doi:10.3233/SW-223254. [24] G. Desogus, E. Quaquero, G. Rubiu, G. Gatto, C. Perra, BIM and IoT sensors integration: A framework for consumption and indoor conditions data monitoring of existing buildings, Sustainability 13 (2021) 4496. [25] A. Cimmino, M. Poveda-Villalón, R. García-Castro, eWoT: A semantic interoperability approach for heterogeneous IoT ecosystems based on the Web of Things, Sensors 20 (2020) 822. [26] N. Moretti, X. Xie, J. Merino, J. Brazauskas, A. K. Parlikad, An openBIM Approach to IoT
Integration with Incomplete As-Built Data, Applied Sciences 10 (2020) 8287. [27] B. C. Grau, I. Horrocks, Y. Kazakov, U. Sattler, A Logical Framework for Modularity of
Ontologies, in: International Joint Conference on Artificial Intelligence, 2007. [28] R. Verborgh, M. Vander Sande, O. Hartig, J. Van Herwegen, L. De Vocht, B. De Meester, G. Haesendonck, P. Colpaert, Triple pattern fragments: a low-cost knowledge graph interface for the web, Journal of Web Semantics 37 (2016) 184–206.