Semantic Web X (2017) 1–27 1 IOS Press Semantic-Graph based approach to BIM, resilience, and spatial data interoperability Editor(s): Name Surname, University, Country Solicited review(s): Name Surname, University, Country Open review(s): Name Surname, University, Country Holly Ferguson 1,* , Charles Vardeman II 1,** , Adila Krisnadhi 2 and Michelle Cheatham 2 a Center for Research Computing at the University of Notre Dame, Notre Dame, IN, United States of America E-mail: [email protected], [email protected]b Computer Science Department at Wright State University, Dayton, OH, United States of America E-mail: [email protected], [email protected]Abstract. Interoperability within the Building Information Modeling and resilience analysis domains is essential for positively influencing the built environment, but is still not sophisticated enough for optimal data and model evaluation with regards to modern, multi-disciplinary questions. Fully interoperable data schemas and tools mean that communications from adjacent domains are also necessary, such as compatibility with geography data schemas or other geometry relationships. Dispersed resources that are required for this analysis cannot be centrally located, rather, they need to be made accessible to users through mediums such as Linked Data Platforms that do not alter existing work flows. This research provides a data pattern, called the Spatial Graph Adapter Pattern, and includes use cases that allow spatial relationships to be captured at a more granular and descriptive level than has been possible thus far; it is implemented to unify several other areas of research including an ontology- based Linked Data Platform and Linked Data Views for proprietary data processing. This pattern is an extension to existing work and is now hosted by a modular and extensible framework used for translating between different Building Industry data formats without needing to change current schemas or work flows. Keywords: Semantic Graphs, Linked Data Platform, Big Data Interoperability, Building Information Modeling, Linked Data Views, Spatiotemporal Data, Spatial Graph Adapter Pattern 1. Introduction Building Information Modeling (BIM) has entered an era where Linked Data (LD) and Linked Open Data (LOD) 1 on the Semantic Web 2 and Decision Sup- port (DS) [25] technologies can be leveraged to better- inform currently isolated, domain centered applica- tions in wide use within the building industry. Deci- * Corresponding author. E-mail: [email protected]. ** Corresponding author. E-mail: [email protected]. 1 Linked Data: https://www.w3.org/standards/semanticweb/data 2 Semantic Web: https://www.w3.org/standards/semanticweb/ sions are being made based upon output from these tools and are greatly impacted due to a limited pic- ture provided by our current, disconnected, computa- tional capabilities. For example, a Life Cycle Analy- sis (LCA) 3 [28] of a building should include building materials from a range of manufacturers at several lo- cations and include shipping costs and environmental trade-offs as well as material lifespan information. Interdisciplinary collaborative teams within the building industry are becoming the new norm and, we 3 GS & LCA: http://www.greenscale.org/ 1570-0844/17/$35.00 c 2017 – IOS Press and the authors. All rights reserved
Transcript
Semantic Web X (2017) 1–27 1IOS Press
Semantic-Graph based approach to BIM,resilience, and spatial data interoperabilityEditor(s): Name Surname, University, CountrySolicited review(s): Name Surname, University, CountryOpen review(s): Name Surname, University, Country
Holly Ferguson 1,∗, Charles Vardeman II 1,∗∗, Adila Krisnadhi 2 and Michelle Cheatham 2
a Center for Research Computing at the University of Notre Dame,Notre Dame, IN, United States of AmericaE-mail: [email protected], [email protected] Computer Science Department at Wright State University,Dayton, OH, United States of AmericaE-mail: [email protected], [email protected]
Abstract. Interoperability within the Building Information Modeling and resilience analysis domains is essential for positivelyinfluencing the built environment, but is still not sophisticated enough for optimal data and model evaluation with regardsto modern, multi-disciplinary questions. Fully interoperable data schemas and tools mean that communications from adjacentdomains are also necessary, such as compatibility with geography data schemas or other geometry relationships. Dispersedresources that are required for this analysis cannot be centrally located, rather, they need to be made accessible to users throughmediums such as Linked Data Platforms that do not alter existing work flows. This research provides a data pattern, called theSpatial Graph Adapter Pattern, and includes use cases that allow spatial relationships to be captured at a more granular anddescriptive level than has been possible thus far; it is implemented to unify several other areas of research including an ontology-based Linked Data Platform and Linked Data Views for proprietary data processing. This pattern is an extension to existing workand is now hosted by a modular and extensible framework used for translating between different Building Industry data formatswithout needing to change current schemas or work flows.
Keywords: Semantic Graphs, Linked Data Platform, Big Data Interoperability, Building Information Modeling, Linked DataViews, Spatiotemporal Data, Spatial Graph Adapter Pattern
1. Introduction
Building Information Modeling (BIM) has enteredan era where Linked Data (LD) and Linked OpenData (LOD)1 on the Semantic Web2 and Decision Sup-port (DS) [25] technologies can be leveraged to better-inform currently isolated, domain centered applica-tions in wide use within the building industry. Deci-
sions are being made based upon output from thesetools and are greatly impacted due to a limited pic-ture provided by our current, disconnected, computa-tional capabilities. For example, a Life Cycle Analy-sis (LCA)3 [28] of a building should include buildingmaterials from a range of manufacturers at several lo-cations and include shipping costs and environmentaltrade-offs as well as material lifespan information.
Interdisciplinary collaborative teams within thebuilding industry are becoming the new norm and, we
2 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
believe, LOD based technologies can allow us to be-gin establishing mappings and translations for modelsand data sets to start informing one another [29] usingvocabularies that are natural for each different domainpractitioner [17,18]. For example, within the biomed-ical research community, a concerted effort has beenmade to create structured metadata to facilitate infor-mation sharing between the diverse disciplines thatconstitute the field of research. Given the successesdemonstrated in other fields, this approach of creating“smarter data” would be of great value to the highlymultidisciplinary building industry. To bring BIM datato this level of accessibility, resolving the differencesin semantics across formats is essential. We are utiliz-ing and reusing work such as Spatial Information The-ory [26], modular scientific ontologies such as Seman-ticscience Integrated Ontology (SIO) [13], work onformalizing Mereotopology [22], and geospatial dataefforts via the Open Geospatial Consortium (OGC)4
standards.However, without expanding upon existing meth-
ods of representing geometry structures and associatedspatial relationships, too much context can be lost inBIM translations due to a limited granularity in de-scription options, if the translations can be done atall. Existing data models typically describe geometriesand basic connections plus adjacency of physical ele-ments within a drawing specification. It is our obser-vation that BIM schema are typically created with theintention of conveying “instance” information with-out broader context even though there may be an im-plicit context contained in schema “tags” that lim-its the transferability of the data model to differentschema. This has the effect of limiting application ofthe data to the intended domain or results in a simplis-tic data model that is insufficient for capturing all ofthe context needed for true interoperability. This paperpresents a summary of our existing work as well as aproposed Spatial Graph Adapter (SGA) ontology de-sign pattern that facilitates lifting of existing schemawhile retaining proper spatial and parametric geomet-ric information necessary for BIM.
Graph-based semantic models are becoming the fo-cus and often a viable solution not only for the pre-sented work and related research level efforts, but alsoon the scale of enterprise projects.5 This article is an
extension and full implementation of the contents ofseveral previous papers set in a larger scope of re-search; one is an in depth description of the architec-ture of the Linked Data Platform components’ func-tionality [17], and the second is a detailed methodol-ogy using Linked Data Views (RDF6 Semantic Map-pings) to extract spatial data into Semantic Web com-patible structures [18]. The Semantic Graph approachpresented combines the work from these other two pa-pers and extends it to include techniques for combin-ing the functionality of these components within a plat-form architecture; we also provide several example usecases (with populated patterns and code samples) an-swering industry questions using these semantic align-ments through modular SPARQL endpoints.
We also present the ontology-based data pattern thatconnects domain vocabularies (that interpret the other-wise proprietary BIM or resilience data) utilizing W3CLinked Data Platform (LDP) components to publishdata as LOD objects as well as a methodology to makethese connections a possibility. The remainder of thepaper is organized to explain how these pieces of soft-ware infrastructure come together while maintainingLinked Data Principles and providing opportunities forcapturing data provenance for the benefit of BIM. Webegin with a review of the existing work and relatedprojects including the development and use of LinkedData Views and the structure of the LDP in questionleading to the need for an ontology-based connectionmethod. This is followed by the methodological de-velopment of the LDP structure and SGA Pattern, aswell as the axiomatization in first order logic. Next arethe case studies that apply and validate the approach;these are diagrammed and explained for scenarios thathave arisen in this ongoing research, especially whenconnecting BIM data to resilience-based engineeringdata. Finally, this project is analyzed against other sim-ilar works and future prospects that may influence theoverall vision.
2. Motivation
The focus of this research is based around the ideamodularizing semantic graph construction and usagesuch that it is not another stand-alone standard or con-verter for limited use, but instead is an intelligent datagenerator that can understand any one of the already
6RDF: https://www.w3.org/2001/sw/wiki/RDF
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 3
simulation
/exports
simulation/
exports
simulation
/exports
simulation
/exports
simulation
/exports
simulation
/exports
simulation
/exports
simulation
/exports
Before Semantic Web Technologies Using Semantic Web Technologies
practiceresearchteaching
==>
Semantic-enriched
practiceresearchteaching
data
data
data
data
data
data
data
data
LD &
Endpoint
LD &
Endpoint
LD &
Endpoint
LD &
Endpoint
LD &
Endpoint
LD &
Endpoint
LD &
Endpoint
LD &
Endpoint
LD &
Endpoint
Fig. 1. Depiction of BIM Data Currently Compared to the Additions Presented in this Research
standardized views of the world (in particular, this im-plementation handles spatial/GeoSpatial/Environmentaldata). This project does not debate the need for thesestandards and types of structured data, but it is uniquein the fact that it interprets these different standards insuch a way that new standards can be modularly in-corporated as they are created by diverse communi-ties. Patterns (like the ones designed below) and on-
tologies give metaphorical crosswalks to automate un-
derstanding between the different standards and as-
sociated local semantic mappings which often have
numerous discrepancies, even when referring to the
same items or concepts. Typically, current converters
4 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
use only XML7 data tagging and it is not done us-ing any formal semantics thus providing no possibil-ities for mapping to and from different applications.The solution presented provides a queryable approachto build Semantic Graphs independent of local defi-nitions. These Semantic Graphs provide, in effect, ahigher view of a schema level mapping around whichto build in additional knowledge. Furthermore, thiswork takes advantage of the strategic application lev-els from which to extract information since it is nei-ther advantageous nor practical to format every pieceof data in JSONLD or triples. For example, if a sim-ulation only needs to know the semantics of wall ma-terial information, processing is not required to trans-form all structural information into triples as well. Thisresearch also makes use of lifting relevant semantic re-lationships and tracking provenance details while stillmaintaining mappings to the underlying, original rep-resentations.
After studying many industry standard tools (Re-vit8, Ecotect9, Athena Impact Estimator10, U. S. De-partment of Energy (DOE-2)11, etc.) and even afterdeveloping our own multi-metric application calledthe Green Scale Tool (GST)12, it was still evidentthat there were inherent issues with the raw data con-sumed in the tools that even the best multi-metric toolscouldn’t overcome in terms of automatic interoper-ability. The best-made simulation tools are still onlyproviding results based upon information that is of-ten not sourced, incomplete, inconsistent, and missing[16] [Figure 1, left]; making simple fixes in the soft-ware pertinent to only one tool is not a sufficient fixfor getting more accurate analysis when it now pos-sible to make smarter data. More specifically, the is-sues with the data come from the fact that there aretoo many differences between entries for the “same”data when comparing it from different industry databases (for example material density values). This mayseem negligible if looking at one wall’s worth of a ma-terial, but when these numbers are extrapolated overentire buildings or city infrastructure, then the impactsare too large to ignore. Therefore, our goals of makingsmarter data means that instead of relying, for exam-ple, on only the energy provided by a non-sourced set
of tool output that we are able to verify the values forenergy use during every step of the lifespan of buildingmaterials from mining to manufacturing to shippingand throughout material life spans for engineering riskand resilience calculations.
There was also a desire to eventually expand thiswork and analysis to include complete supply chain in-formation for manufacturing and building materials aswell as build a knowledge base to facilitate data aggre-gations and connect various types of building informa-tion. In order to do this, however, the approach to thiswork needed to be changed to ensure that the projectwould be modular, extensible, scalable, and SemanticWeb compatible since the amount of data that needsto be processed is potentially exponential in complex-ity and extensive in quantity. These challenges can bemet by using Linked Data approaches to handling BIMdata [Figure 1]. Using smarter, semantically enhanceddata in more robust tools is advantageous to both thearchitecture and engineering fields as well as all of thedecisions made to produce a more sustainable built en-vironment.
Since data generated by tools is often “siloed” inproprietary structures or at least in various formats,it does not always contain the semantics necessaryto function outside of specialized, domain centric,schema such as CityGML [21], Green Building XML(GBXML)13, Industry Foundation Classes (IFC)14,and others should a modular or extensible semanticmapping method exist. Fortunately, these data stan-dards contain recognizable information patterns thatcan be computationally predicted, making automaticdata extraction a possibility. The efforts of the pro-posed project caused the realization that using smarterdata techniques means that our multi-metric simula-tion set no longer has to be limited to one type of en-ergy and one type of thermal calculation. Instead, pro-cessing semantic mappings within a scalable LinkedData Platform became the more generalizable solutionto the specific goal of simulations that can include andbe simultaneously cross-examined with any chosen de-sign metric, such as energy performance or thermalgains/losses, but also have metrics for analysis typesof Life Cycle Assessment (LCA)15, structural simula-tions, analysis of components from the city and landsurroundings, and other resilience models.
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 5
2.1. Novelty of the Semantic Mapping Approach toData Integration
All three data standards studied currently each pro-vide part of a more complete picture and in fact feedback into one another; resilience modeling data canbe found in CityGML, energy performance data is of-ten in gbXML, structural or engineering informationcomes from IFC, and finally any missing or incorrectdata can be resolved through LD-based solutions pre-sented in this article once initial data is mined and ex-amined [Figure 1]. Ideally and as available, all threetypes need to be mined and analyzed together in or-der to determine any long term effects or to under-stand how all of these building perspectives influencethe built environment relative to one another based ona user’s individual design choices or decision supportsystem priorities. Therefore, to offer more accuratemulti-criteria decision analysis results to users, thesedifferent data formats all need to be interoperable ina modular fashion so as to continue to expand uponthese research ideas in an organized manner. The ex-plored solution for the combination of several researchpursuits has led to the following:
– Implementation of a spatial Ontology Design Pat-tern and associated Linked Data Views (RDFmappings) [18] within a Linked Data Platform[17] (which is a Linked Data standard, is extensi-ble, is scalable, and gives compatibility when im-plementing additional Ontology Design Patterns).
– This work generates the link between the domaindata with which this research group works andthe LDP which assists the creation of cloud-basedsmart applications via modular Docker16 Con-tainers; presented are the bridging componentsand use cases on current domain expert questions.
– While the individual previous works [17] [18]were designed to work as self-describing enti-ties for ease in automating knowledge, the con-necting Ontology Design Pattern presented hereunites these two previous efforts such that self-description is both possible and tractable, andolder vocabularies can also be included using LDViews.
– This solution for data interoperability in particu-lar allows the automation of connections with theLinked Open Data Cloud17 and linking together
16Docker: https://www.docker.com/17Linked Open Data Cloud: http://lod-cloud.net/
previous work means we are therefore function-ally able to find and process both RDF and non-RDF data and can start to bring that informationinto our simulations.
– Use of patterns, like the one demonstrated be-low, additionally helps to generate the unified Se-mantic Graphs that allow us to verify that all thedata and provenance information is present in themodel, connect to other data stores to fill in whatmight be missing (or search for external data asneeded), and to validate the existing data and re-lationships against other industry (or user pre-ferred) informational resources (eventually usingother patterns to provide reliability metrics).
Linked Data principles used with the Semantic Weballow challenges in these domains to be resolved; theapproach presented is implemented within a cloud-based infrastructure called a Linked Data Platform.As an important note, this approach to resolving thisset of data challenges within the architecture and en-gineering domains is achieved by combining the ef-forts of two existing works from this same researchas mentioned earlier. The first is the LDP Architec-ture itself with components in Docker Containers us-ing RESTful interfacing and design for data discov-ery [17]; the second is a method called Linked DataViews [18] which are RDF files that map how the LDPshould interpret specific industry schema standard in-formation (IFC, GBXML, CityGML) such that seman-tic graphs be generated in interchangeable Linked Dataformats. The implementation that brings these two sep-arate projects together and creates the fuller picture ofmaking smarter data and applications is the focus ofthe work to follow since understanding industry datais one challenge but using it as semantic graphs in aLDP is another. As an extension and facilitator to ex-isting work, this article explains the implementationof several areas of our research as well as describesand demonstrates how these connect into a functionalcomputational ecosystem by applying a newly pro-posed and axiomatized Ontology Design Pattern andexplanation through use cases that need to be solvedby combinations of these different types of data. Forexample, some of these situations arise when askingabout how your building (GBXML, IFC) performsconsidering the impact of the surrounding environment(CityGML, etc.).
6 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
2.2. Domain Expert-Based Competency Questions
With the help of various domain experts, compe-tency questions have been developed that are usedto guide the development of the research. Our pro-posed pattern and query automation parser automat-ically capture and extract geometry, spatial relation-ships, structural elements, floor levels, and additionalrelated information using LD principles [27] - at timesas extensions of existing SIO [13] or other mereotopo-logical concepts. It is important to point out that thesecalculations currently can be completed in individ-ual tools; however our goal is to be able to automati-cally set this information up and validate the numbersto then automatically complete multi-criteria analysiswithout manual effort editing files and without intro-ducing a lot of the error that comes from exporting andimporting 3D models between tools (as is a commonsituation today). This approach allows domain-relatedand multi-disciplinary questions such as the followingto be answered more holistically:
1. What spaces (GBXML) is this damaged struc-tural beam (IFC) a part of (without needing toiterate through every existing spatial componentor coordinate set)?
2. Exactly how much of structural element A (IFC)is exposed and to what spaces (GBXML)?
3. What are all of the spatial elements in this graphthat contain void spaces (air spaces in assembliesthat could be susceptible to damage)?
4. What thermal or occupancy zones is this assem-bly associated with (these may or may not haveto do with adjacency or locality)?
5. What sets of columns are responsible for sup-porting floors X and Y (IFC) and how arethese chosen elements (GBXML) impactingthe environment (CityGML)? (Is there a moreenvironmentally-friendly option for these struc-tural elements given the specific environmentalsurroundings?)
6. For the green-resilience engineering calculationsfor my building, what is both the structural in-tegrity (IFC) under wind loads (ASCE 718) andthe thermal performance (GBXML) over its life-cycle (External LCA Simulations) analyzed atthe same time?
7. What are the peak wind speeds (ASCE 7) andweather effecting my building (GBXML or IFC)
18ASCE 7: http://windspeed.atcouncil.org/
considering all of the surrounding city buildings(CityGML) within N radius using a specific setof weather data (ex. Energy Plus19)?
8. Within N-mile radius of my building (IFC orGBXML), what other structures (CityGML) aremost likely to effect both the thermal energy(GBXML) and wind speed values (ASCE 7) be-ing used in my simulations?
3. Existing Research and Related Projects
Simulation tools have begun to resolve many of theissues [16] raised when examining the current state ofBIM and sustainable data and at times they do workto comparatively analyze data and computational re-sults. For example, newer semantic-based techniquessuch as semantic rules are gaining attention for solvingchallenges where synthesizing different types of infor-mation now requires additional context [32]. In termsof data analysis, there are also now projects that havefocused on converting certain aspects of BIM data intoRDF [10] utilizing Semantic Web technology. Thesegive valuable insights into the value proposition as-sociated with Semantic Web technologies that allowthe possibility of creating new web services, enhancedata discovery, and automate computational execution[35]. In particular, BIM and resilience data can be en-hanced with essential 3D spatial contextual knowledgewhich is absolutely necessary for this data to be suc-cessfully processed or translated [14] or to be reappliedto describe building objects. There have been major ef-forts to automatically align information between vari-ous data formats; even though this is typically workedout between a set of two data formats, it is no small en-deavor [12]. Due to the complex nature of such tasks,the value of being able to automate these processesquickly becomes important and also was for the re-search presented in this paper as well since we weredesigning not only to be able to translate between twoformats but modularly by mapping semantic graphsbetween any number of spatial representations. Whileuse cases are provided later to address the limits ofsolutions, it should be noted that we do acknowledgethe efforts of alignment are immense and that there areseveral pieces to the whole challenge, such as resolv-ing certain discrepancies in coordinate sets [12].
Systems are needed to integrate different data for-mats for many reasons; one example using two data
19Energy Plus: https://energyplus.net/
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 7
formats enabled the translation between GIS data andCityGML data such that systems can be built to im-prove the richness of navigational data. This was ex-ecuted in one tool called BlindAid [36] which im-proved data such that the visually impaired have ac-cess to better spatial references. Data platforms thatare ontology-based [8] not only allow proper transi-tions between spatial and building material informa-tion, but also make it possible to find vulnerabilitiesand calculate data uncertainties which are critical toprovide context for any decision support applicationfor building professionals [1]. Several software or webservice efforts are attempting to help BIM becomemore open and transferable20 [33], and can ultimatelylead to more reliable building calculations, and helpmake general geospatial knowledge21 more accessiblefor decision support [25].
Our approach allows data compatibility for the in-clusion of modular decision support frameworks thatare a major player when tools are being unified andsimulations to simultaneously calculate Life-CycleAnalysis [19] or environmental impacts [30] are run.One of the difficulties in performing this Big Dataanalysis or handling BIM and resilience data is uti-lizing Linked Data methods in order to benefit fromthe Semantic Web; some tools are working towardsthis goal as well. The Google spin-off project, GoogleFlux (Google 2014) now known as FLUX 22, is oneproject that works with BIM data in an accessible plat-form geared toward tool interoperability; however, itdoes not make use of Semantic Web technologies –and thus does not benefit from them – in the waythe research presented in this article proposes. Otherprojects, such as SEMERGY [33], do make use of theSemantic Web but these use practices like taxonomy-based design optimization instead of an extensible andmodular approach to data extraction, as our researchdemonstrates.
Interoperability is no easy goal, but is essential foreffective tools in the future. GeoSPARQL23 helps in-crease data interoperability to an extent as an OWL24
compatible RDF25 ontology and extension to SPARQLused to store and query geospatial information; theOpen Geospatial Consortium (OGC)26 standards them-
selves are useful spatially, but are not yet fully linkedwith the full BIM picture. Apache Marmotta27 is an ac-cessible open data platform effort for translatable datarepresentations across domains (soon compatible withGeoSPARQL) that has an implementation of the LDPrecommendation; however, modeling the relationshipsamong structures within a building requires somethingmore geometrically expressive than parts and wholes.RCC [37], another spatial representation, prevents cer-tain 3D cases but does provide an expanded set of eightspatial relationship descriptions allowing expressivedistinctions other than coordinates for making connec-tions between spatial entities. SIO allows more gran-ularity, but is made for biomedical fields and while ituses mereotopological relations, there are other geo-metric concepts that cannot be captured (more in sec-tion 7).
Ontology Design Patterns28 like Agent-Role orCollection-Entity patterns can manage groupings andmemberships of entities but not at the spatial granular-ity intended by the SGA pattern which also allows usto extend and further support the quality and opennessof city data such as in the PolisGnosis project29. Thefurther goal of the SGA is to help create, predict, andsupport spatial knowledge graphs [8,15] to ultimatelybetter support DS analysis.
Other projects take another step and work to buildan additional interoperability layer to connect BIM on-tologies to the larger Semantic Web. Of particular in-terest to this work is one alignment effort that uses dif-ferent perspectives (quantitative/qualitative, abstract,domain-specific, multimodal) [23] to organize com-putational understanding for different alignment focuspoints [24]. This solution uses a light-weight mereol-ogy that describes how the components fit together aswell as a basic RCC-8 description plus some mere-ology30; these are aligned with DOLCE-Lite and ap-pear to have the intention of creating an ontology thathandles physical entities. This instance is also not thefirst time there has been a goal to separate out thesocial intent of a space using non-physical-endurantto represent building and room types (OfficeBuild-ing, LivingRoom, etc.) [2]; while it has its merits, thisapproach (using a collection of categories) encoun-ters many of the same limitations that a taxonomy-based approach encounters, including but not limited
8 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
to having restricted, if any, compatibility with theSemantic Web. Certain other implementations suchas with OWL31demonstrate other conceptual issuesfor Architectural Design modeling such as the often-encountered issue of solutions only working for se-lect case studies and nothing more. Extensive analysisof IfcSpace (spaces) objects and IfcRelSpaceBound-aries32 (walls, etc.) has been completed to be ableto convert between formats such as BIM to GIS [6].While this may only be handling a single data formattranslation, it demonstrates how the spatial fields arefinding it drastically necessary to be able to have datainteroperability between several formats and queryingtools automatically to answer multi-disciplinary ques-tions [6]. Our solution using Semantic Graphs providesa higher level method to achieve these mappings; otherresearchers agree that successful and full integration ofBIM, GIS, and other spatial data must have systematicsemantic mappings to resolve a variety of data struc-tures [4], which our methods offer.
The goal for the implemented Semantic Graph ap-proach presented in this article is to maintain LinkedData principles as well as set up a modular approachthat is easily integrated with GeoSPARQL, extensible,and scalable. It was designed to be part of a LDP use-ful for accommodating, interpreting, and semanticallyenhancing any BIM, spatial ontologies, or other dataformats/taxonomies (and by extension the underlyingdata) [Figure 2]. To explain it in terms of other ap-proaches of modular ontologies [23], the modules inour solution are essentially at the levels of conceptual-ization throughout a qualitative and quantitative layer-ing. Further use cases with code as well as alignmentexplanation is provided in the discussion section of thisarticle.
3.1. Study of Existing Industry Standard Models
The SGA pattern is modeled based on needs for thebuilding domain, however the goal was to make a pat-tern that can describe any spatial object or space - ageneric solution to increase compatibility in the future.Because coordinates and simple bounding boxes can-not represent the level of complexity needed to pro-cess and query data efficiently at the pace modern toolsneed or with the variety of tagging structures used, thegeometry types and the SGA resolve the differencesfound between spatial data standards.
Fig. 2. General BIM Data Processing Hierarchy for the LDP
Section 6 below shows the relationship betweenthree commonly used Building Information Modeling(BIM) standards: IFC, GBXML, and CityGML. In-dustry Foundation Classes (IFC) is the open standardfor any data describing BIM data. It includes ways todetermine boundaries, related objects, connection ge-ometries, related building elements, related spaces, andso on. GBXML is the Green Building XML schemaand like IFC, it is also open sourced. It has a buildingcomponent tagging system including building, space,surface, material, etc. breakdown as well, but in a dif-ferent relational structure than IFC. CityGML, whichis used for Virtual 3D City Modeling, can representnot only building information but also full city andlandscape models in an XML-based encoding captur-ing geometry, topology information, and a five-levelthematic hierarchy information about object relation-ships.
This graph structure of Linked Data can be used asa data filter and easily queried to fill in the missingpieces, to verify the information against the larger se-mantic web of data, connect the data to as many otherpatterns as is useful, and to finally be able to use thedata in many other simulation tools without the needfor manual translations. Retrieving relevant data froma BIM instance file requires automation in represent-ing cases where different source schema formats donot necessarily decompose geometries into traditionalparts. For example in GBXML, Spaces are directlylinked (through object properties) to the surfaces thatmake up that space. However, to collect those samesurfaces from IFC, we have to find them based onmultiple searches and matching because the originalrepresentation fails to directly connect some of thosesurfaces with the space level data as traditionally ex-
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 9
pected (shading surfaces, for instance). The SGA iswell-suited for resolving these issues and this is im-portant because all building components and relevantrelations need to be captured regardless of what toolgenerates them to reach further levels of data interop-erability.
4. Spatial Graph Adapter Pattern: Link BetweenBIM Data and Unified Processing LDP
4.1. Spatial Graph Adapter Structure and Extents
The organizational spatial hierarchy for capturingrelationships between entities, at a minimum, is a gen-eralized organization of spatial hierarchies seen in theschemas, and we chose to keep the raw geometriesseparate from the relationships they can embody formodularity in LDP design and also because there are alot of inherent inconsistencies in these schemas. Thereneeded to be a way to structure the difference in ge-ometry types under some unifying concepts tractableby the SGA. This was the chosen method [Figure3][Figure 4] because it pertains directly to handlingBIM data and also because it easily aligns to other spa-tial schemas, as discussed further in the discussion sec-tions.
In addition to further defining concepts like geom-etry alignments and spaces versus voids, a SGA so-lution to bridge the gaps that exist between BIM andenergy schemas was developed after analyzing currentmajor BIM industry standards including CityGML,GBXML, and IFC, their data, and the nature of the pro-prietary applications that use them. The developmentalapproach for the SGA was to address the needs of themodular translation adapter applied in the LDP infras-tructure, as discussed. To simplify the explanation andscope for this approach, we separate the schema geom-etry types from the core SGA pattern; while we havefully axiomatized the core pattern in the following sec-tion, we only show domain and range restrictions inthe accompanying OWL file for the schema geome-try types [Figure 3]. For the schema geometry types inFigure 3, we recognize there are mappings to deepermereotopological relations, but for flexibility, we areonly interested in the domain and range restrictions atthis time so it is possible to demonstrate how these twospatial mappings work together to extend spatial con-cept description abilities for our tools.
The SGA pattern is part of a larger, higher levelontology for spatial schemas that talks about seman-
tically similar items from differently contextualizedschema standards in a unified manner that correspondsto how a specific domain describes these concepts. Itis firstly used to capture the main spatial arrangementof geometric elements extracted automatically from aspatial instance file; in other words, how the geome-tries are handed to you from an application [Figure 3].Secondly, the pattern allows us to contextualize addi-tional relationships to capture schema-specific ideas -all in a LD format that lets us ask all the data ques-tions simultaneously. Minimally, a “Spatial Object” isrecorded in terms of a location (SpaceCollectionLoca-tion), and at least one spatial element (SpaceCollec-tion); this spatial element can be broken down into 3Dor 2D entities, depending on the data provided in theinstance file.
BIM entities are captured as sub-layers of spatialobjects, down to material assemblies (or further). Thisgeometry classification structure is crucial in terms ofusing it in conjunction with the SGA such that we canrecord any building industry or other spatial informa-tion, understand the difference or similarities betweenthem, and know about the surrounding context. Ad-ditionally, because we are using a comprehensive andunifying LD graph, our concurrent work can include ajoint data parser that automates the queries needed toget the appropriate file data and store this informationin the SGA, of course depending on what is providedby a particular data schema.
Using a graph with extended geometric and spatialrelations also means there is a solution to not onlyquery forward through a tree of data as many currenttools are capable of doing, but the SGA lets us bypassthis otherwise forced forward searching, which can bevery computationally intensive and limiting in terms ofinferencing ability. Furthermore, once there is a map-ping for a type of data schema, then that can be storedand referenced to enhance future training sets for ma-chine learning.
4.2. SGA Pattern Entities and Axioms (See AppendixA)
In addition to describing what the 2D and 3D ge-ometries are for a given location, our research startsto build in layers of context for those geometries bymapping this ODP to other spatial schemas. This iswhere the core SGA pattern [Figure 4] can be derivedfor these research needs. Since each of the types of ge-ometries represented in Figure 3 are subclasses of Spa-tial Things, this means that any or all of the classes and
10 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
Top Level Spatial Hierarchy for the Organization of BIM Related Geometric Elements
hasSpaceMember
hasSpatialCollectionLocationMember
belongsToSpace
Collection
belongsToSpace
hasSpaceBoundaryElementMemberbelongsTo
SpaceBoundary
hasSpaceCollectionMember
hasSpaceBoundaryMember
SpaceCollection Location(A SpatialObject)
SpaceCollection(A SpatialObject)
Space(A SpatialObject)
SpaceBoundary(A SpatialObject)
SpaceBoundary Element(A SpatialObject)
A SpatialObject(alignment hook to other spatial
ontologies)
Spatial
Object
Types
Definition in Context Example Use Scenario
Space
Collection
Location
Location of the geometries
described in the graph
instance.
Commonly the Latitude,
Longitude, and
Elevation.
Space
Collection
Identifier of relevant geometry
groupings (3D, 2D, points).
For example, a Building
in its entirety.
Space
3D geometry elements in the
SpaceCollection.
3D Enclosure in a
Building (Room, Elevator
etc.).
Space
Boundary
2D or 3D geometries 1)
creating the Space or 2) part
of the SpaceCollection,
depending on the schema.
In BIM, typically the
Walls, Ceilings, and
Floors, or even Shading
or Retaining Walls.
Space
Boundary
Element
2D or 3D geometries 1)
creating the SpaceBoundary or
2) part of the
SpaceCollectionLocation,
SpaceCollection, or Space.
In our research, these
are Material Layers
within Walls or
Landscaping.
Fig. 3. Spatial Hierarchy for Organizing Common Geometry Types within BIM
Note 1: SpatialRepresentationObject can represent any of the Classes in the Top Level Spatial Hierarchy
Note 2: Using this SGA Pattern, Attributes can be used to capture data like coordinates, and,
Note 3: ContextualizedRelation can be used to capture relationships to other spatial objects such as how surfaces
align (inner, outer, center line) or how they should be perceived by other systems (void, solid, etc.)
Note 1
Note 2
Note 3
Fig. 4. Spatial Graph Adapter Pattern: Core Ontology Design Pattern for Spatial and BIM information
properties diagrammed in Figure 4 can be employedto further contextualize each of the Figure 3 geome-tries. Additionally, these allow a greater granularity ofspatial relationships including the ability to potentiallyreduce processing efforts. For example, depending onthe schema being mapped, we would need to be able tocapture the fact that they each use their own coordinatesystem and the geometric properties alone from Figure3 cannot explain this concept. However, if the geom-etry types from Figure 3 are used in conjunction withthe core SGA pattern, then we have a method to fullycontextualize the spatial objects from a variety of do-
mains; it also helps to consider some of these classes tobe roughly analogous to features in GeoSPARQL. Thefull set of axioms are described in Appendix A and theOWL file can be found either on the ODP website33 oron GitHub34.
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 11
5. Use Case Scenarios for BIM Data
5.1. Case Study 1: Populated SGA Pattern InformingStructural Dependencies in the Event of Damage
The SGA allows us to capture term-to-term compar-isons as well as information about how pieces fit to-gether and relate to other proprietary schemas and in-file contexts. For example, a Wall in a given GBXMLfile may refer to the same Wall in the same building ofa CityGML file, but you cannot say they are equal orhave a direct comparison of coordinate points becausewalls in GBXML are referenced differently in terms ofjoining on the center line of the wall versus the outeror inner side. However, if we can enter both of thesedata models into the SGA graph with the relation dis-tinction “connectedBy” with type being “centerline”for these adjoining parts, then a fair distinction can bemade and recorded. Consider a more in-depth exam-ple use case for the SGA pattern (green/yellow/soild)extending the original geometry types (blue/dashed)[Figure 5]. How would we use the geometry informa-tion provided to populate the SGA pattern such that wecould ask questions such as: What exposed columnsare holding up Floor 3 (or would not hold up Floor 3 ifdamaged in a natural disaster)?
Instead of needing to filter through and process allcoordinate information to see what parts of this modelmight effect other parts or assume we can use some-thing like elevation (which is not helpful if based onstarting position as seen in the example study), thisknowledge is represented explicitly in the SGA pat-tern, and we can therefore automatically make queriesto produce all of the relevant column-type structures,per this example. This delineation is needed becausewe may need to include columns that are in adjacentspaces or even in other walls, but are technically partof the same group holding up, in this case, the floor inquestion. Other columns may be considered spatiallyadjacent or in closer proximity than the ones we needto get back as query results, or they may not be struc-turally holding up this example floor. Asking coordi-nate data what building elements may exist at a cer-tain elevation is also not enough to gather the specificcolumns needed as a group for this scenario becausethere is missing context or perhaps even columns thatmay extend through other surfaces. From this graphsnippet, we can ask directly what columns are solid,what floors they are in fact connected to, and then re-trieve the specific 3D coordinate details desired - no
need to evaluate all geometries and do advanced andcomplicated coordinate processing [Figure 5].
Furthermore, in building design, there are often ge-ometries called “adjacent” to other geometries such asSpaceCollection2 in Figure 5. This type of situation isoften where architecturally designed elements act aslandscape framing devices or even as wind breaking orretaining walls, for example, but are not always orga-nized in an XML output file as relating at all. Groupingobjects as adjacent is not even a possibility dependingon the type of data we are reading or depending on theexact locations of these geometries. If this same sec-ond collection of geometries were a retaining wall itwould greatly effect wind direction and thus pressureon a building, making it vital information to capture forengineering simulations. The SGA can build and cap-ture these relationships that other spatial organizationschemas cannot capture with the same level of speci-ficity. Now answering questions such as “to what ex-tent are these pieces considered adjacent“ is possibleand more accurate.
5.2. Case Study 2: Query Example to CompetencyQuestion: Within N-block radius of my building(IFC or GBXML), what other structures(CityGML) are most likely to effect both thethermal energy (GBXML) and wind speed values(ASCE 735) being used in my simulations?
First, consider what types of information are neededto answer this question; there need to be engineeringmodels of the building of interest, city information,climate/shading information (ex. Energy Plus36), el-evations from at least two different sources to com-pare, and so on. Furthermore, to avoid errors in manualtranslations of data to and from several disjoint analy-sis tools or resources, this information should be ableto be used automatically through semantic translations(which our solution offers). Since models often comein different formats, this method allows for data valida-tion and omits human error as well as does not requirethe need to change engineering practices or native dataformats - i.e. practice can keep the engineering modelsin Revit, for example, and then still analyze that modelwith CityGML data, etc.
Specifically, this question is relevant to engineers,for instance, who want to know accurately how anewly proposed building (IFC/GBXML) will be im-
12 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
Fig. 5. Example Application for Describing Column Spanning and Adjacency
pacted by wind speeds given precise surroundings(CityGML). A typical practice is to use ATC windspeeds for a given latitude and longitude; however, amore intricate breakdown about the surrounding ele-vations (wind effects) and material information (ther-mal effects) can be acquired through semantic anal-ysis. Additionally, more context in the data used foranalysis means other types of risk can be calculatedsuch as potential damages given certain environmen-tal disasters where elements of surrounding structurescould damage the building in question. If your buildingis shorter than nearby structures there can be more sur-rounding direct risk of damages from other buildingsin a hurricane, but there can be more risk of strongerwind (effects both thermal and structural wind loads)if your building is taller than your surroundings. Se-mantic analysis allows all of these perspectives to beconsidered together based upon sequences of query re-sults.
Using the Linked Data Platform [17] and LD Views[18], the data needed for the Semantic Graphs to beconstructed to provide such answers can be gatheredfrom potentially a variety of distributed resources oruser-based input since it is all transformed into LinkedData. Consider the example query sequence used toanswer such a question as that posed in this section;
for the sake of this example, an auto-generated set ofcity information37 is generated to test the sequence andvalidate its findings against the results (other types ofCityGML 2.0 models can be used as well) [3]. Fig-ure 6 shows a cluster of simple buildings that sur-round what is identified as the newly proposed build-ing to be evaluated. Semantic Graphs are constructedfor the CityGML space, the IFC model of the newconstruction and the GBXML of the new construction.Semantic alignments can then be established basedupon the location of the new structure placement inthe CityGML and the set location of the new structuregiven in the IFC or GBXML model using constructssuch as owl:sameAs [Figure 6].
Based upon the Semantic Graphs containing allof the spatial data needed to answer this question,queries can be automated that help reach a more con-textual understanding to answer this question. Usinga GeoSPARQL38 enabled graph database and serverframework (Virtuoso39 and GraphDB40 have been in-vestigated) combined with the Semantic Graph data se-
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 13
rialized in Turtle41 (or RDF), it is possible to retrieveall of the City Structures that are available to considerin the scenario, called “SGA:SpaceCollection” from agiven Level of Detail [Figure 6]. In this case, the sur-rounding building footprint geometry is the only partneeding to be considered since the corresponding ele-vations and other information are already stored in ourSemantic Graph, reducing the amount of building datato query over (See first query example: Figure 6, right).
Next, an example GeoSPARQL query is shown withcode and results that performs a routine elimination ofall structures from the previous query that are outsideof a given distance [Figure 7]. This example uses a ra-dius of 100 meters, however this can be defined userinput as a specific application needs. This chosen dis-tance allows consideration of all of the nearby struc-tures that are adjacent to the newly proposed build-ing known in IFC formatting. Based upon this secondquery, we show a subset of the results returned fromGraphDB (in our example there are 24/100 total build-ing returned).
This gives insights into not only what is containedin the original IFC/GBXML model, but it also pro-vides external context to the surroundings from dataof different formatting such that we can easily knowwhat surroundings are more likely to influence ourstructure, and by how much [Figure 8]. For exam-ple, the query returning elevation information from oursemantic graph based upon the location of our IFCmodel shows that the surrounding buildings that are 3-4 proper levels taller [Figure 8] will probably highlyinfluence the shadows cast upon the proposed build-ing (influencing thermal calculations) as well as al-ter the wind pressures (influencing structural calcula-tions), and so on. Ultimately, this aides in the usersability to accurately consider such knowledge whenmaking choices for the proposed building.
As an important note, it is acknowledged that thereare still certain types of imperfections when translat-ing coordinates between different reference systems,in terms of preciseness of geometry connections [12].This contribution is instead about automating semantictranslations and gaining knowledge through semanticmappings and semantic resolution of concepts usefulfor various spatial formats.
At this point, our implemented pattern (plus jointparser) is capable of formatting data organized ac-cording to the SGA schema into the Open GeoSpatialConsortium representation, compatible with the Sim-ple Feature Access profile.42 The framework can beeasily extended to produce output in additional for-mats; OGC was tackled first because it is of specialinterest to our efforts due to its capability to performspatial analysis processing involving properties suchas union, intersection, difference, etc. When convert-ing data organized according to the SGA pattern to theOGC file format, the relationships necessary to under-stand are the OGC geometry classes, such as Point,Polygon, etc. [Figure 9]; it is also possible to includeliterals, comments, and so on as well as to relate ele-ments to one another via references and grouping IDs.The SGA pattern allows us to capture more informa-tion; it is able to capture these types of geometries butalso to describe the relationships between these differ-ent OGC parts. Furthermore, it is necessary to store therelation data that is in the original SGA graph instancesomehow in the OGC standard so that 1) re-creationof the SGA for reverse compatibility is available in thefuture and 2) full and generic vocabulary generation ispossible. [Figure 9].
Translation into the OGC standard was a major partof this proof of concept because it creates interoper-ability between the building domain of knowledge andother spatial analysis efforts. The OGC contributes amajor amount of effort toward creating high qualityopen sourced standards for the geospatial communityworldwide and works to unite professionals from manydisciplines or organizations including research, gov-ernment, commercial, and more. Compatibility withOGC allows building and energy simulations to haveaccess to a much larger scope of data, web map ser-vices, geography markups, and observational featuresto name a few examples. It also will eventually givetools a way to get OGC formatted data from any-where and use the associated SGA instance to form thedata into any file type usable in proprietary applica-tions (part of ongoing research efforts). Furthermore,our data can now be compatible with the GeoSPARQLquery language and other RDF stores in an automatedor semi-automated manner. OGC compatibility result-ing from schema format translations also benefits DS
# Then can build subset .gml files, visualizations, etc.:
# Level 1: 3.048 m
# Level 2: 6.069 m
# Level 3: 9.144 m
# Level 4: 12.19 m
# Level 5: 15.24 m
# (1 Level = 1 Building Storey)
Level 4
Level 1
Level 3
Level 2
Level 5
Level 1
Level 1 Level 1
Level 1
Level 1
Level 2
Level 2 Level 1
Level 3
Level 3
Level 3
Level 3
Level 4
Level 4
Level 4
Level 4
Level 3
Level 5
Level 5
Fig. 8. Query Example 3: Populate and visualize a new set of data by retrieving the contextual data for the new subset of city structures:Elevation/Shading influences from lower levels to higher levels are represented from lighter coloring/labels to darker coloring/labels, respectively.
IfcRelSpaceBoundary, IfcMaterial gml:Polygon or gml:surfaceMember
Surface, SpaceBoundary,
Construction, Layer,
Material
MultiPoint ex. set of IfcRectangleProfileDef ex. set of gml:pos or gml:posList ex. set of CartesianPoint
MultiLineString (ex. from combinations) gml:posList or gml:LinearRing (ex. from combinations)
MultiPolygon IfcWallStandardCase + IfcWindow gml:MultiSurface or bldg:Building Space or Construction
GeometryCollection IfcSpace or IfcBuilding
cityObjectMember , bldg:Building,
grp:CityObjectGroup, or
gml:CompositeSurface
Space or Building
PolyHedron IfcBuilding cityObjectMember or gml:Envelope Building
Tin - - -
Fig. 9. Example of Initial Studies of Alignments and Translation Possibilities between various BIM Schema Formats, Including Adapting to theOGC Standards (Note: Final OGC representations can have several correct forms, depending on what relations are intended.)
subset of applications or for scenarios tailored specifi-cally to one of these data structures. LD Views can beused once to establish a set of terminology and rela-tionships that are relevant for a particular schema whilemaintaining LD standards and modularity; however,since there are a lot of overlapping concepts betweenschemas, the exact way we make these connectionsand alignments is more involved because while twoschemas may talk about the same surface or wall, theydo not describe it in exactly the same way or with thesame descriptors [Figure 10]. One example is where
normal alignment can state that walls in two differentmodels are the same geometry, but our work also letsus establish if the given coordinates are referencingdifferent coordinate systems or are based on differentaxis of the wall (inner edge, outer edge, or center-line).The first step is to identify what part of a computerizedbuilding design is important for simulations (similar tohow geometries are essential to thermal changes) andthen to extract the more minor differences that will af-fect automated understanding. For example, prior toour work using LD Views, individual parsers would
16 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
GBXML
IFC
CityGML, etc.
1) Schema Instance
Source wall formatting Ex:
format gives coordinates as
2D, on centerline:
(2D & center line need to be
captured for complete
translation relationships)
output file
2) Schema View
(Mapping)
(Parser can determine
current file instance and
retrieve the relevant View)
Model Parser: (To create a Unified LD Format Pattern)1. Query View at each SGA Level
2. Automate query for instance file based on view structure
3. Query instance and gather data (process as needed)
4. Store this as triples in unifying LD graph
Result: a LD graph that is now compatible with all the
other patterns/ontologies
from app
from KB
Industry Standard Tools
and Other External Data
View (RDF)
Knowledge
Base
LD graph data can be verified, extended, & reformatted
as needed for requests to external tools and simulations
LDP
LDP
Fig. 10. LDP Processing Schema Using LD Views
have been needed to partially understand every datatype encountered. Views allow us to capture all the ad-ditional spatial or material information that basic termmatching cannot provide.
Most importantly, the Views or windows to under-stand data formats mean that only one parser or datatranslation processor is needed to query any View sincethey are following the same spatial graph. The effectsof this are twofold: 1) it means that this data can beseamlessly extracted into an ontology design patternfor SW compatibility and 2) we have a way to es-tablish the otherwise untraceable differences that existwhen comparing data from different schemas (yieldinga way to express a more nuanced spatial granularity)[Figure 10]. The ontology design pattern that is usedin this new parser (and associated LDP) is referred toas the Spatial Graph Adapter (SGA) pattern. It allowsdata to be passed back and forth through the RESTAPIs of the LDP in a format that is compatible withthe LDP itself. Because there is a common parser forall Views with a cloud-based infrastructure, it meansall desired data can be parsed automatically, reformat-ted for use in simulation models at external locations,and can be automatically queried to allow any gaps tobe filled in and the rest of the data to be verified. TheSGA pattern is intended (and implemented) to func-
tion as a “bridge” or translation-enabling data struc-ture which semantically unifies proprietary spatial dataformats, BIM, geometric representations, dimensionalrepresentation gaps, spatially extended geographicalcontexts, domain specific needs within the building in-dustry, and finally to allow the level of spatial granu-larity needed such that our information can be prop-erly consumed in Linked Data Platforms (LDP)43 en-hanced with provenance layers [34]. This SGA graphstructure itself and its integration with LD Views andthe larger infrastructure is part of the extended workand takes the form of an axiomatized ontology designpattern and modularized schema parser that can readand automate queries from individual LD View files.
While the SGA research addition can handle in-formation sets that include buildings themselves, it isalso able to capture spatial information pertaining toa building’s surroundings, topography, city-scape orother larger regional entities. The standard used forthis set of broader city level information is CityGML,as mentioned earlier, and this schema uses a conceptcalled Level of Detail (LOD) to organize their spatialinformation. There are 5 LODs ranging from regionaltopography with basic massing models to fine grainedmaterial and furniture data (level 4). Each LOD can beconsidered a sub-feature in GeoSPARQL and can alsobe assigned as a spatial attribute in the SGA pattern.Capturing the LOD data in the SGA graph means it canthen be linked through other patterns and associatedby that particular LOD to models that come in formatssuch as IFC or GBXML, creating the data interoper-ability sought. For instance, city level information canbe linked with the Relative Relationship Pattern (RR)44
to building models in schemas such as IFC or GBXMLin order to give city-level context per the LOD pro-vided where there would otherwise be none. Further-more, LOD in CityGML can be aligned as a type ofLevel of Detail in the RR pattern and then it is pos-sible to further extend the pattern instance to resolvealignment differences such as relating models that aredescribed using different scaling systems or for trans-lating between differing coordinate systems or framesof reference as is often the case with data from variousindustry tools.
While the SGA pattern has its own goals and usage,we acknowledge that in several cases there could bebenefits to aligning it with other mereotopological or
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 17
SIO concepts. In any case, consider an example: defin-ing two spaces and spaces between them for buildingindustry data. RCC [37] lets us state that one thingis within another (non-tangential proper part (NTPP)),but neither to what extent, to what purpose, or if itshould be handled as a space, void, or something else.Some ontologies propose what a void is [22,7], but inBIM we need more context because any space couldtechnically be a void. We must consider occupyablespaces differently than air spaces within wall assem-blies which are closer to voids as per building industryuses, and furthermore we need to resolve confusionsfor scenarios such as mechanical HVAC spaces whichare both (voids and occupied in some manner). SGA inconjunction with techniques such as Views45 let us cre-ate computationally automated understanding of theseand other types of distinctions.
7.2. Query Automation Opportunities
A feature of this methodology that is of particularimportance is the ability to fully automate all of thequerying that needs to take place when mining infor-mation from any of the BIM formats in question. Be-cause we are working with LD Views and thereforehave consistent, encoded patterns of mapping allowinga computational understanding of each spatial data for-mat, it is possible to include automatic query parsingand processing. That is, the LD Views tell us whereto look in a BIM document for relevant data, and thesingle parser can therefore use the given structure (thatcomes in one of several patterns) to set the variablesneeded to make each SPARQL query, then execute thescript, and finally collect the results. Consider the ex-ample shown in Figure 11 (which is further explana-tion of Figure 10 part 2 in the Model Parser).
Figures 10 and 11 demonstrate how the single parserrequires the specific instance file (typically describ-ing a building and its surroundings in energy and re-silience simulations) and the respective LD View File.Figure 11 gives an example snippet from the IFC ver-sion of a View in the form of RDF where it recordswhere and how to find the spatial location information(only part is shown for simplicity). For this example,the LD View itself is parsed into a Python ReadableRDF graph and a separate SGA instance graph is cre-ated to record and organize the data that is mined. Thisis performed as JIT population since it is intended to
SpaceCollectionLocation1 isA SpaceCollectionLocation
SpaceCollectionLocation1 hasAttribute Property1
SpaceCollectionLocation1 hasAttribute Property2
Property1 hasType “Latitude”
Property1 hasValue “41.8°”
Property2 hasType “Longitude”
Property2 hasValue “-87.6°”
Variable
S
L = xslt_list (these are known references to
existing vocabulary types such as XSLT:List
Type or RDF:Type)
Variable
L
Latitude,
Longitude
41.8°, 87.6°
{ IFCXML,
GBXML,
CityGML, etc. }
Fig. 11. Reusable Method for Automating Spatial Queries
be dynamic mappings as data is available; the result-ing Semantic Graph is an in-memory structure for an-swering further queries as needed. Other data is visi-ble at this point such as the spatial levels (Figure 11"S" which are the same as Figure 3 hierarchical lev-els) and external vocabulary references (such as RDF,GRDDL46, etc.). These references and known spatialtypes are combined as they are processed into the vari-
46GRDDL: https://www.w3.org/TR/grddl/
18 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
ables needed for SPARQL queries; they can be reusedfor the next set of spatial types encountered in theView as relevant items. There are two examples of howthe BIM standard information is combined with theknown SGA structure to automatically determine whatto gather from the BIM instance file (here the IFCXMLfile), where to find it, and how to place it into the newSGA graph based on the View mapping for the currentspatial type being parsed [Figure 11].
Once the parser knows what spatial items are impor-tant and where and how to find them, searching andretrieving that specific data from the BIM specific in-stance is as straightforward as reading any XML file,with the results stored in the new SGA graph as LinkedData. Figure 11 shows what data would be assigned tothe different parts of the SGA pattern for this simpleexample, and then what triples that might produce to-ward the final SGA graph structure. Since these queriesare being made as the processing happens, it is easyto computationally re-construct them for any spatialtype; generally, it is only necessary to add a new querywhen a new XML informational structuring pattern isfound outside of the known set, else they are automatedand reused as explained in the image. In a similar setof processing routines, queries are automated to ex-tract the data now in a common RDF graph to send toexternal formats and simulation tools; OGC is one ofthe output types handled thus far. The intent is for auser to present a question then only perform this pro-cessing on the necessary pieces of instance data, us-ing only as much processing power as required to buildthe graphs. Additionally, the decisions of this approachcan be thought of as an ETL lifter using RDFLib47
which also makes future application enhancements us-ing SPIN48 rules a possibility.
7.3. LDP, LD Views, and SGA Working Together
To recap, the SGA Pattern and associated imple-mentation of this component is the main addition toexisting work as a facilitator between the Linked DataPlatform and the individual Linked Data Views foreach version of BIM data. This pattern provides a tech-nique to achieve a common Linked Data structure andsemantic mappings that are able to capture all of therelevant data and object relationships that can be ex-tracted from a set of BIM or spatial data. The SGAis the link between using the LD Views (that can be
stored in and retrieved from a Knowledge Base) andthe more extensive LDP components that can now beutilized due to the common formatting of the BIM andresilience data [Figure 12].
The SGA is the mechanism within the LDP thatworks directly with a single parser; having a singleparser and a single data structure that can be formedfrom any LD Views means that all of the queryingand data communications between these componentscan be easily created as needed automatically. While,to the best of the author’s knowledge, there is not asimilar system to compare processing, the construc-tion of these Semantic Graphs currently takes between5.78 seconds and 12 minutes for a range of a singleroom building throughout a multi-story, 60+ room of-fice building, respectively. In terms of the complexitythis involves, graph construction depends upon the se-lection of relevant components to add to the SemanticGraph including but not limited to modular sets of basegeometries, windows and doors, individual material in-formation, structural components such as beams andcolumns, and levels (or stories for targeted engineer-ing wind load simulations). In reference to Figure 12,the SGA and associated parser implementation now al-lows the following infrastructure to become functionaland fully automated:
1. There is a place for the various types of BIMand resilience data to be brought for processingas well as there is a place to store references tothe various storage locations of the LD Viewsand useful ontology design patterns such thatthey can be accessed and pulled into the parseras needed for automation [Figure 12 (1)]. Note:While the LD Views and other platform compo-nents are implemented in this work, their devel-opment and full explanation are outside the scopeof this article but are part of a concurrent pendingpublications.
2. The processing parts of the overall infrastructurecan be seen in Figure 12 (2). This section ex-plains the function of the automation process us-ing BIM data and LD Views. The end result isthe filled SGA pattern instance; this instance isnow independent from the original proprietarydata formatting and can be easily queried furtherto add any additional data that may be relevantto begin using it in external simulations or fil-tered to be used with other external tools. A com-plete infrastructure makes existing work flowsand preferred industry tools remain in place for
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 19
GBXMLIFC
Industry Standard Tools and Other External Data
Knowledge Base
IFC View (RDF):
Term A, Term B,
Relationship A,
Relationship B, etc.
GBXML View (RDF):
Term C, Term D,
Relationship C,
Relationship D, etc.
Modular LDP Components, Containerized
Single Model Parser (Using Views)
Schema
Instance
Schema
Instance
Schema
Instance
SGA Pattern
Respective Linked
Data View (RDF)
Qu
ery
to
ge
t C
om
pli
me
nta
ry R
DF
Vie
w
Qu
ery
to
ge
t N
ece
ssa
ry D
ata
Pa
tte
rns
Modular LDP Components, Containerized
The current object
to query under the
given View
Computerized Map
of what to Query
for in the Instance
Common LD
Structure to store
all query results
(data, relationships)
Reference to
Ontologies/Patterns: i.e.
SGA Pattern
Triple StoreReasoner (plus
selections)
Filled SGA PatternSPARQL
Endpoints
External
Models
External
Containers
Data
Repositories
Inte
rfacin
g w
ith E
xte
rna
l Re
so
urc
es
Second Query Module for Adding any Missing Data,
Correcting Wrong Data, and Filling In Blanks
Filled SGA Pattern
1
2 3
1
Fig. 12. How the SGA enables LD Views to work through a LDP
use, but means that additional simulations anddata analysis are now possible without needingto change those existing work flows - but theycan still benefit from a much more complete andSemantic Web compatible data analysis.
3. An additional benefit to this solution is based onthe fact that a common SGA instance means itis easy to also automate queries that can be usedto find the missing pieces of information in theSGA instance as well as ask external endpointsfor data to fill in what is missing or verify thedata being used in the instance (for example ma-terial property values) [Figure 12 (3)]. It is possi-ble through this method as opposed to other so-lutions because the SGA instance is already andinstantly compatible with any other external LD.
4. Beyond this, HYDRA is useful for incorporatingand validating data that may not yet follow LDprinciples [17]; this means it handles data that isboth RDF and non-RDF. It can also set up sets ofservices [11] for applications though semantics.For this, semantically enabled data and meta-data are needed for achieving truly interopera-ble cross-domain communication and HYDRAgives machine interpretable service descriptionsfor useful development implementations. HY-DRA and JSON-LD allow the automatic com-position of services, i.e. it is possible to com-putationally automatically find options to assem-
ble a set of semantically annotated services [11],which means that a set of best-fitting servicescan be searched and found based upon require-ments. This is possible because modern servicesare API-driven so mappings can be created andused to retrieve data objects [18]; HYRDA helpsthis goal because many of these modern serviceswe are trying to exchange information with arealready using REST APIs which means there canbe meaningful connections with the underlyingstructures.
8. Discussion and Critical Evaluation
8.1. Alignment Possibilities
Several entities within the ontology design patternthat forms the core of the Spatial Graph Adapter [Fig-ure 3][Figure 4] have intentionally been left vague.This enables the pattern to remain relevant for a widevariety of applications. Such entities can be then mod-eled to an arbitrary degree of fidelity, from a flat“strings-as-things” approach, to complex ontologysnippets in their own right. This follows best practicesdescribed in works depicting the capabilities and lim-itation of OWL [31]. Of course, for the pattern to beuseful in a particular application, these loose threadsmust eventually be pinned down. In this section we
20 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
do just that, by aligning the model to existing relatedontologies in a way that supports the overall projectdescribed in this paper.
The need for modular alignment between resourcesis not a new idea, although one that still needs quitea bit of development. Certain projects already haveworked towards aligning IFC to the Semantic Sen-sor Network (SSN/SSN-DUL)49; however, there arestill certain limitations to this and other approachesto modularizing spatial information such as fallinginto the limitations that restrictive taxonomies intro-duce when used alone. The project utilizing organiza-tional perspectives (quantitative/qualitative, abstract,domain-specific, multimodal) [23] starts to completethese upper level alignments by defining their ownRCC8 ontology whereas the presented approach be-gan by modularizing LDP components and by usingGeoSPARQL as well as the existing RCC-8 ontologiesplus other relationships that the proposed SGA patterncan establish.
SSN typically describes sensors, their observations,and similar concepts. The SGA was designed to beflexible enough to incorporate sources and descrip-tors from several ontologies or new ones that are notin use yet. For example and depending on the spa-tial qualities being described, SGA attribute:type andattribute:value can capture any relationship or spatialdistinction, and align to existing concepts such as DUL(hasPart, hasQuality, isObjectncludedIn, etc.). How-ever, the SGA allows spatial descriptors from manyresources (RCC-8, SSN, GeoSPARQL, SGA, etc.) tobe connected within the LDP and therefore analyzedtogether, instead of being forced to use only one re-source or format for the build environment. Mereol-ogy in this solution is also relevant since we want to beable to align to existing RCC representations. To thisend, Building Element as seen in Figure 13 is also asubClassOf each spatialThing.
Following in the footsteps of other ontological BIMefforts (we can reference the Modular Ontologies forSpatial Information book here), we align many ofthese entities to corresponding concepts within theDUL module of the SSN/SSN-DUL ontology. How-ever, there are some key differences between our align-ment work and that of other approaches. In particu-lar, some other solutions make simplifying assump-tions such as âAIJthe x-dimension in an architecturallyrendered building always corresponds to the height or
width of a modeled geometryâAI when designing theiralignments. A guiding principle of the work presentedhere was to avoid such assumptions at all costs. Ad-ditionally, we do not define our own RCC-8 ontology,but rather model the spatial relationships at a moregeneral level (based on how the model was actuallydrawn) and use GeoSPARQL and the existing RCC-8 ontologies to achieve the same end. Other existingdata patterns, such as the Relative Relationship (RR)Pattern33, can then be used to resolve the remainingdiscrepancies between different schemas, for examplewhere we see models that have to be analyzed togetherbut come from different Cartesian coordinate systemswhere reference points cannot be guaranteed to be thesame.
At first glance, aligning against the SSN ontologymight seem like an odd choice. This ontology wasoriginally designed to model sensors, their observa-tions, and similar concepts. However, the DUL modulewithin the SSN has several relevant properties, includ-ing hasPart, hasQuality, isObjectIncludedIn, amongothers. Further, many important applications related tothe built environment involve a variety of sensors mea-suring everything from which parts of a building areoccupied to structural tension on key components ofthe structure.
Additionally, we align relevant SGA entities totwo more general upper level ontologies: the De-scriptive Ontology for Linguistic Cognitive Engineer-ing (DOLCE) [5] and the Basic Formal Ontology(BFO/BFO-SNAP) [20]. Aligning to DOLCE allowsus to model the social implications of a spatial ob-ject, such as zoning, occupancy, etc. Aligning to BFO-SNAP allows us to associate entities with temporalfeatures. This is an important extension because build-ings analyzed for energy and resilience exist as theyare for a certain amount of time - either for a lifespanor while experiencing the effects of natural disastersor other discrete temporal events. Figure 13 shows thealignment of the SGA model to relevant portions ofSSN-DUL, DOLCE, and BFO-SNAP.
At a conceptual layer, Dolce:physicalProperty alignsto SGA:attribute, where the referenced physical en-tity is the SGA:spatialRepresentationObject [Figure4], and these entities can inherit any SGA:Attributesor SGA:Conceptualized Relations that are present inthe SGA instance. For example, DOLCE:feature givesa place to connect to GeoSPARQL Spatial-Thing as anendurant and then pyhisical-endurant provides a placewhich lets us add social implications to a spatial ob-ject such as zoning, occupancy, etc. BFO is used to
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 21
Fig. 13. Linking and Alignment to Upper Level Ontologies
describe basic physical objects as well as spatial partsand locations, although not at the level of granularity indescription necessary for our work. The SGA patternentity SGA:SpatialObject in particular can be alignedwith BFO to identify entities in reality as well as asso-ciate items in our solution with temporal features. Thisis an important extension because buildings analyzedfor energy and resilience results exist as they are fora certain amount of time - either for a lifespan or asof the effects of natural disasters making the temporalaspects useful to record. BFO-SNAP uses SpatialRe-gion for spaces, which can be aligned to our work, butour work allows a larger set of distinctions, includingbreakdown into 2D and 3D geometries. Also, we canalign our class for describing locations of architecturalmodels with BFO-SNAP Site.
Interactions between layers in the presented LDPrequire a bit of additional framework to make tran-sitions effectively [Figure 12]. Building Element cor-responds to SGA:spatialRepresentationObject [Figure4] which is the pattern representation of any of theorganization entities in the corresponding spatial hi-erarchy [Figure 3]. Those geometries seen in Figure3 are Dolce physical-endurants and physical objects(Spatial Things), where the SGA provide additionalrelations and information that align to Dolce quali-ties for those geometries or other features. In termsof linking to upper ontologies, Building Element cor-responds to an assembly (Wall, Floor, Ceiling, Roof,
etc.) or a component (Door, Window, etc.) which cap-tures the information that a taxonomy can, but is nei-ther limited to a restrictive set of building elementsnor separated from Linked Data compatibility bene-fits [Figure 13]. Our definition of Building Elementis conflated so that it can be either an assembly or acomponent; this solved the problem seen in other ap-proaches where assemblies are defined as a set but inreality they can be one or more components, and viceversa. Building Element aligns to IFCOwl using theclassification "element." Functional_Structure and Ar-chitectural_Feature are modeled as roles so this so-lution is also extensible to engineering needs whereit is necessary to figure out if an Assembly is Struc-tural or Architectural. Building, BuildingAssembly,and BuildingComponent would all be SpatialObjectsin GeoSPARQL, and the RCC8 relations are now ac-cessible by using GeoSPARQL. For example, geo:sf-contains property connects building to site and we canreuse the Place Pattern from geolink [Figure 13]. Now,the top level is Object such that it can be aligned topatterns being developed concurrently to advance thisapproach.
There are even other data patterns, such as the Rel-ative Relationship (RR) Pattern50, that can be used toresolve the remaining discrepancies between differentschemas, for example where we see models that have
22 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
to be analyzed together but come from different Carte-sian coordinate systems where reference points cannotbe guaranteed to be the same. For instance, some so-lutions make assumptions such as the x-dimension inan architecturally rendered building is always corre-sponding to the height or width of a modeled geometry[23]. This article acknowledges that information suchas that cannot be assumed and so our solution is moregeneral, pulling out the information from the render-ing space and then using the RR Pattern that can alignthem based upon how a model was actually drawn. Be-yond what is capable by other works, the solution inthis article also allows for integrating building and citylevel objects with OGC/W3C standards that are (soonto be) LD approaches for expressing this informationin LD formats while maintaining ontological modu-larity for depicting architectural object hierarchies be-yond what is capable by other solutions.
8.2. Evaluation of the LDP, LD Views, and SGAPattern Combination
While the full architecture for this project is de-scribed in another paper, the condensed version is andthe focus in this paper and includes the SGA, RESTCommunications used for data handling, and BIM in-teroperability through LD Views and ODP Structur-ing. For instance, compared to Apache Marmotta51,which is an open data platform used to translate dataacross domains, the solution presented in this article ismore general in terms of being able to handle any typeGeoSpatial with options for connecting to other datastores depending on the simulation and type of analysisbeing performed, even though it is specifically imple-mented and demonstrated for BIM and resilience data.It can similarly handle GeoSPARQL queries, whichshould at least support the decision to carry this featureinto the LDP presented above. Being more general inextensibility, modularity, and semantic capability, theLDP using LD Views and the SGA Pattern are also setup such that other issues can be tracked and resolvedgoing forward, such as vulnerability, uncertainty, andrisk analysis within modern practices [1].
The Google Flux (Google 2014) spin-off projectFLUX52 is another relevant project to discuss. Thisproject does work with BIM data and saw the meritsof working with that data in an accessible data plat-form. Also being concerned with data interoperability,
this project took large steps forward in the domain ofbuilding tool functionality for design efforts but doesnot focus on LD. The approach using SGA pattern in-stances is not only compatible with the Semantic Web,but is able to look for additional data outside of the setof industry tools used for building design and this hasthe potential for major impacts on the data analysis re-lied on for design decisions. The SGA also makes itpossible to capture and utilize any spatial information,as Views are added.
SEMERGY [33] is a related project with a simi-lar set of goals. It does focus on design data inter-operability using Semantic Web Technologies, whichdoes open up a lot of potential in that direction; how-ever, instead of the full capacity of semantics, it usestaxonomy-based building design optimizations. It iscontested that taxonomies have a valuable place in re-search, but will not provide the multitude of benefitsthat ontology design patterns offer such as being ableto capture the relationships that exists within BIM files.Without a rich set of relationships even between sim-ple geometries, data analysis becomes far too limitedas happens with taxonomies alone. RDF View exten-sion files informing SGA pattern instances in a LDPmeans information can be queried more efficiently. Forexample, typical BIM file structures are tree-like interms of how you search for information (i.e. compo-nent break-down); SGA instances mean that search-ing can happen in any direction and for any numberof geometry groupings since it is a graph instead ofa tree. When there are thousands of building compo-nents, multi-directional searching within the data canbe vital for running simulations.
This is not intended to say that these are the onlyparts of a LDP that could be useful for BIM interop-erability. It is true that getting BIM and resilience datainto a common format that is compatible with the Se-mantic Web is no small endeavor, but it is also partof an even bigger goal. Further steps to this researchwould include evaluating the benefits of Reasoners,Decision Support, and recording Provenance [9] infor-mation from these SGA instances, and these steps arenow a practical possibility, since our data is in a com-mon LD format. Furthermore, it is important to notethat because of the structure of this LDP and its com-patibility with the Semantic Web, it is possible to addall of these features without needing remake any of thecomponents that are already in place.
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 23
8.3. Modularity in a Distributed LDP Framework
From the start of this project, the goal was to in-sist LDP components be designed to be modular in na-ture, to ensure the most reuse and ease platform growthover time. Modularity is a key factor for BIM and re-silience data translations because it ensures that a dif-ferent parser does not need to be coded for each typeof data formatting that exists, which is impractical andnot a sustainable approach. Furthermore, and perhapsmore importantly, is that modularity is key for find-ing, using, and analyzing data from geographically dis-tributed and remotely located data sets and models.Since all data cannot and should not exist in one loca-tion, modularity in the LDP approach also means thatthis project can be scalable as work progresses and thatindividual SGA instances can be stored for machinelearning as they are generated at their own organizedSPARQL endpoint(s).
8.4. Further SGA Research and Implementation
Additions to this work could be in several areas.The first area of work is planned for adding additionalschema types to the set of existing ones available tothe LDP. That is, additional Views will be added to theset of working ones, and others will follow as they areneeded or as data formats are discovered. Due to thestructure of the LDP and SGA, they will instantly beable to be consumed by the platform, just by having theadditional View; thus, making feature expansion sim-ple. Other potential areas of work that would be bene-ficial to test with this platform include specialized GISsoftware and data formats such as Point Clouds.
At this point, there are new questions that will needto be resolved as this research continues. Some of theseareas would include additional external endpoint dis-covery, LDP components, user-generated Views fornew data types, further Provenance information lay-ers, etc. There is also more research that could be donein terms of ways to use the SGA instances in exter-nal tools, or rather how to extract the relevant informa-tion from a particular SGA instance to be useful in saidtools. Nevertheless, the LDP presented makes it possi-ble to begin to translate between select proprietary for-mats. These new areas of work are all relevant to thefuture of the use of the SGA in the LDP, but are outsideof the current scope of this article.
9. Conclusion
The multi-disciplinary questions being asked of en-ergy, design, and engineering professionals currentlyare requiring increasing amounts of multi-disciplinarysets of data in order to provide accurate and com-plete answers. This article presented a solution to thischallenge using ontology-based Semantic Graphs forautomating spatial data integration. From high-levelviews of this semantically mapped spatial informa-tion, knowledge is accumulated in order to automatequeries and then generate data-based conclusions uti-lizing many types of standard data. Currently, both thistype of approach and diversity of data sets included foranalysis has previously not been possible, especiallyimplemented with Linked Data principles for the Se-mantic Web.
In this article we presented an extension to an exist-ing framework that was intended to use Linked DataViews to bring Semantic Web compatible interoper-ability to BIM and resilience data. The Spatial GraphAdapter Pattern along with its axioms, platform im-plementation, and use case scenarios provide the nec-essary connections within the platform that allow theother two existing areas of research to be functionallyjoined together, making a great stride forward towardthe vision for completely interoperable data and indus-try applications. It is achieved in a manner that is al-ready interchangeable with the Semantic Web and thuscan harness the benefits therein, unlike other existingprojects.
Per domain-specific research needs, this work flowhas been useful and implemented for IFC, GBXML,and CityGML standards through the use of LinkedData Views that are used to map each of these for-mats to the SGA pattern automatically. There will beopportunities to utilize the SGA instances in the fu-ture as they can be used in cooperation with otherODPs to record provenance information from schemaversions over time as well as connect this data to thelarger Linked Data Cloud; this is expected to be a con-tributing factor in improving learning and knowledgestores as time progresses. Modularity and scalabilitywere key factors driving the outcome of the currentproject as well as the now having the ability to gen-erate automated Semantic Graph instances at separateSPARQL endpoints for an easier building block frame-work. This framework embedded in a linked data plat-form is ideal for storing, querying, and analyzing BIMand resilience data.
24 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
It is now possible to strategically add additionalBIM schemas and or other forms of spatial data suchas GIS software or Point Cloud representations of spa-tial collections using LD Views to automatically gen-erate SGA-structured Semantic Graphs as needed. Ad-ditional future work will involve further alignment ofthe SGA pattern to spatial descriptions outside of thebuilding domain schemas so that the SGA can be usedfor spatial constructs of any kind (risk, chemistry, etc.).The Spatial Graph Adapter Pattern is a scalable, modu-lar, extensible approach to schema interoperability andtranslation methods currently used to bring BIM intoa common and open triple format for further use asLinked Data within the Semantic Web and other mod-eling and simulation applications.
Acknowledgments. Thank you to the Center for Re-search Computing at the University of Notre Dame,NSF CMMI-1537652: "A Green Resilience Frame-work to Support the Design of Sustainable BuildingsUnder Multiple Hazards," and Civil Engineering do-main experts Tracy Kijewski-Correa and AlexandrosTaflanidis as well as our Architecture domain expertAimee Buccellato.
References
[1] B. M. Ayyub. Vulnerability, Uncertainty, and Risk: Analysis,Modeling, and Management. In First International Sympo-sium on Uncertainty Modeling and Analysis and Management(ICVRAM 2011); and Fifth International Symposium on Un-certainty Modeling and Anaylsis (ISUMA), Reston, VA: Amer-ican Society of Civil Engineers, 2011. Reston, VA: AmericanSociety of Civil Engineers.
[2] M. Bhatt, J. Hois, and O. Kutz. Ontological modelling ofform and function for architectural design. Applied Ontology,7(3):233–267, July 2012.
[3] F. Biljecki. Random3dcity: Synthetic CityGML data and pro-cedural modelling engine.
[4] T. Bittner, M. Donnelly, and S. Winter. Ontology and seman-tic interoperability. In Large-Scale 3D Data Integration: Chal-lenges and Opportunities, CRCPress, Boca, volume 139-160.
[5] S. Borgo and C. Masolo. Ontological Foundations of DOLCE.Theory and Applications of Ontology: Computer Applications.Springer Link, Springer Netherlands, 2010.
[6] G. Boyes, C. Thomson, and C. Ellul. Integrating BIM and GIS: Exploring the use of IFC space objects and boundaries. InGISRUK 2015.
[7] B. Brodaric and T. Hahmann. Toward a foundational hydroontology for water data interoperability. In HIC 2014.
[8] G. P. Cimellaro, A. M. Reinhorn, and M. Bruneau. Frame-work for analytical quantification of disaster resilience.32(11):3639–3649, 2010.
[9] M. Compton, D. Corsar, and K. Taylor. Sensor Data Prove-nance: SSNO and PROV-O Together At Last. In SSN 2014,Trentino, Italy, 2014. ISWC.
[10] O. Corby, C. Faron-Zucker, and F. Gandon. A Generic RDFTransformation Software and Its Application to an OnlineTranslation Service for Common Languages of Linked Data.In Lecture Notes in Computer Science, volume 9367, pages150–165. Springer, 2015.
[11] F. Diniz. Composition of semantically enabled geospatial webservices.
[12] S. Donkers, H. Ledoux, J. Zhao, and J. Stoter. Automatic con-version of IFC datasets to geometrically and semantically cor-rect CityGML LOD3 buildings. 20(4):547–569.
[13] M. Dumontier, C. Baker, et al. The semanticscience integratedontology (SIO) for biomedical research and knowledge discov-ery. 5(1):14, 2014.
[14] E. Eaton, C. P. Gomes, B. Williams, and et al. Vol 35, No 2,Summer Issue. AI Magazine, 35(2), 2014.
[15] C. Esteban, V. Tresp, et al. Predicting the co-evolution of eventand knowledge graphs [1512.06900]. arXiv.org - ComputerScience - Learning, 2015.
[16] H. Ferguson et al. Capturing an architectural knowledge baseutilizing rules engine integration for energy and environmentalsimulations. In SimAud 2015, pages 17–24. Society for Mod-eling & Simulation International (SCS).
[17] H. Ferguson, C. Vardeman II, and J. Nabrzyski. Linked DataPlatform for Building Resilience Based Applications and Con-necting API Access Points with Data Discovery Techniques.In IEEE Workshop on Big Data Metadata and Management(BDMM ’2016) in conjunction with the 2016 IEEE Interna-tional Conference on Big Data, Washington D.C., USA, Nov.2016. IEEE Conference Publications and Sponsored by IEEEBig Data Initiative (BDI).
[18] H. Ferguson, C. Vardeman II, and J. Nabrzyski. Linked DataView Methodology and Application to BIM Alignment and In-teroperability. In 1st IEEE International Workshop on Big Spa-tial Data in conjunction with IEEE International Conferenceon Big Data, Washington D.C., USA, Nov. 2016. IEEE Confer-ence Publications and Sponsored by IEEE Big Data Initiative(BDI).
[19] M. Flint, L. Dhulipala, Y. Shahtaheri, and et al. Developinga Decision Framework for Multi-Hazard Design of Resilient,Sustainable Buildings. In Iconhic 2016 | International Confer-ence on Natural Hazards and Infrastructure, Chania, Greece,2016.
[20] P. Grenon and B. Smith. SNAP and SPAN: Towards DynamicSpatial Ontology. Spatial Cognition and Computation, 4-1:69–103, 2004.
[21] G. GrÃuger and L. PlÃijmer. CityGML âAS interoperable se-mantic 3d city models. 71:12–33.
[22] T. Hahmann, B. Brodaric, and M. Gruninger. Voids and ma-terial constitution across physical granularities. In IOS Press.FOIS-2014.
[23] J. Hois. Modular Ontologies for Spatial Information. Disser-tation, Berlin, 2013.
[24] J. Hois, M. Bhatt, and O. Kutz. Modular Ontologies for Archi-tectural Design. In Proceedings of the 2009 conference on For-mal Ontologies Meet Industry, pages 66–77, The Netherlands,2009. IOS Press Amsterdam.
[25] A. Ishizaka and P. Nemery. Multi-criteria Decision Analysis:Methods and Software. John Wiley & Sons, Ltd., 1 edition
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 25
edition.[26] Ittingen, Kartause. Spatial Information Theory : Foundations
of Geographic Information Science. LNCS ; 2825. Springer:International Conference, COSIT 2003.
[27] K. Janowicz, P. Hitzler, B. Adams, D. Kolas, and C. Varde-man II. Five stars of linked data vocabulary use. Semantic WebJournal, 2014.
[28] K. Janowicz, A. Krisnadhi, Y. Hu, and et al. A Minimal On-tology Pattern for Life Cycle Assessment Data. In 6th Work-shop on Ontology and Semantic Web Patterns (WOP 2015),PA, USA 2015, 2015.
[29] K. Kaneiwa, M. Iwazume, and K. Fukuda. An upper ontologyfor event classifications and relations. In AI 2007: Advances inArtificial Intelligence, volume 4830 of LNCS, pages 394–403.Springer Link.
[30] T. Kijewski-Correa, N. Smith, A. Taflanidis, A. Kennedy,C. Liu, M. Krusche, and C. Vardeman II. CyberEye: Develop-ment of integrated cyber-infrastructure to support rapid hurri-cane risk assessment. Journal of Wind Engineering and Indus-trial Aerodynamics, 133:211–224, Oct. 2014.
[31] A. A. Krisnadhi, P. Hitzler, and K. Janowicz. On the capa-bilities and limitations of OWL regarding typecasting and on-tology design pattern views. In Ontology Engineering - 12thInternational Experiences and Directions Workshop on OWL,OWLED, co-located with ISWC 2015, LNCS 9557, pages 105–116. Springer, 2015.
[32] P. Pauwels, D. Van Deursen, R. Verstraeten, J. De Roo,R. De Meyer, R. Van de Walle, and J. Van Campenhout. Asemantic rule checking environment for building performancechecking. Elsevier, 20(5):506–518, 2011.
[33] U. Pont, J., N. Ghiassi, S. Fenz, J. Heurix, et al. Semergy: Ap-plication of semantic web technologies in performance-guidedbuilding design optimization. 107âAS20.
[34] B. Regalia, K. Janowicz, and S. Gao. VOLT: A provenance-producing, transparent SPARQL proxy for the on-demandcomputation of linked data and its application to spatiotem-porally dependent data. In The Semantic Web, pages 523–38.Springer.
[35] D. Ventura, R. Verborgh, V. Catania, and E. Mannens. Au-tonomous Composition and Execution of REST APIs for SmartSensors. In Joint Proceedings of the 1st Joint InternationalWorkshop on Semantic Sensor Networks and Terra Cognitaand the 4th International Workshop on Ordering and Reason-ing, 2015.
[36] B. Wu. Development of MIT geospatial data to CityGMLworkflows.
[37] S. Zhang and O. Bodenreider. The body region connectioncalculus RCC-8, 2005.
26 H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data
Appendix
A. Spatial Graph Adapter Pattern Axioms
SpatialInformationObject represents exactly one SpatialObject, where a SpatialObject can align to GeoSpatialObjectfrom GeoSPARQL. The SpatialObject is the actual spatial entity and the SpatialInformationObject is the data objectrepresenting that actual spatial entity, to clearly define the difference between spatial things and representations ofthose spatial things.
S patialIn f ormationOb ject v (= 1 represents.S patialOb ject) (1)
∃represents.S patialOb ject v S patialIn f ormationOb ject (2)
S patialIn f ormationOb ject v ∀represents.S patialOb ject (3)
A SpatialInformationObject may have Attribute and may have ContextualizedRelation. Since Attributes and Contex-tualizedRelations have different descriptions in different data schema, these model classes were also chosen to workfor any of the schemas used by our domain tools. So we simply state the domain and range for the correspondingproperties.
∃hasAttribute.Attribute v S patialIn f ormationOb ject (4)
S patialIn f ormationOb ject v ∀hasAttribute.Attribute (5)
∃hasContextRelation.ContextualizedRelation v S patialIn f ormationOb ject (6)
S patialIn f ormationOb ject v ∀hasContextRelation.ContextualizedRelation (7)
Types and Values are needed because as seen Figure 9, the semantics for the same types of spatial objects are labeleddifferently schema to schema. Attribute must have exactly one Value and exactly one Type. It must be attached toexactly one SpatialInformationObject. Note that it is possible for two different SpatialInformationObjects to haveattributes of the same Type and Value.
Attribute v (= 1 hasValue.Value) u (= 1 hasType.Type) (8)
Attribute v (= 1 hasAttribute−.S patialIn f ormationOb ject) (9)
Our use of hasType makes the model more amenable to resolving the large variation of schema differences thatexist; instead of subclassing we consider types to be instances of individuals so that we are not burdened by thedecision to say that something is a subtype or not. Doing so would cause more hierarchical confusion instead ofhelp in terms of its application. Nevertheless, having typing through properties does not preclude us from adding inthe function of such a hierarchy later on [31]. ContextualizedRelation must have exactly one Value and exactly oneType. ContextualizedRelation refers to at least one SpatialInformationObject. The refersTo relation is an inverse ofhasContextRelation.
ContextualizedRelation v (= 1 hasValue.Value) u (= 1 hasType.Type) (10)
ContextualizedRelation v ∃re f ersTo.S patialIn f ormationOb ject (11)
re f ersTo ≡ hasContextRelation− (12)
H. Ferguson et al. / Ontology-Based Linked Data Platform Interoperability for BIM and Resilience Data 27
Domain and range restrictions for hasValue and hasType:
∃hasValue.Value v Attribute t ContextualizedRelation (13)
∃hasType.Type v Attribute t ContextualizedRelation (14)
Attribute v ∀hasValue.Value u ∀hasType.Type (15)
ContextualizedRelation v ∀hasValue.Value u ∀hasType.Type (16)
Pairwise class disjointness:
alldisjoint(S patialOb ject, S patialIn f ormationOb ject, Attribute,ContextualizedRelation,Value, Type) (17)
![Completing RDF Data in Linked Open Data Cloud using Formal ... · Linked Open Data (LOD) [1] has become the de facto standard for publishing data on-line. LOD uses standard semantic](https://static.documents.pub/doc/80x56/5f5b0671a16fd555464d194c/completing-rdf-data-in-linked-open-data-cloud-using-formal-linked-open-data.jpg)
![Research Article Measuring Semantic Relatedness between ...downloads.hindawi.com/journals/tswj/2014/758089.pdf · as Linked Open Data (LOD) [ ]andSemanticLink Network (SLN) [ ], the](https://static.documents.pub/doc/80x56/5f74f8a6ddb0d873833885aa/research-article-measuring-semantic-relatedness-between-as-linked-open-data.jpg)
