=Paper=
{{Paper
|id=Vol-3213/paper03
|storemode=property
|title=Knowledge Graphs for Multidisciplinary Co-Design: Introducing RDF to BHoM
|pdfUrl=https://ceur-ws.org/Vol-3213/paper03.pdf
|volume=Vol-3213
|authors=Diellza Elshani,Alessio Lombardi,Al Fisher,Steffen Staab,Daniel Hernández,Thomas Wortmann
|dblpUrl=https://dblp.org/rec/conf/ldac/ElshaniLFSHW22
}}
==Knowledge Graphs for Multidisciplinary Co-Design: Introducing RDF to BHoM==
https://ceur-ws.org/Vol-3213/paper03.pdf
Knowledge Graphs for Multidisciplinary Co-Design:
Introducing RDF to BHoM
Diellza Elshani1, Alessio Lombardi2, Al Fisher2, Steffen Staab3,4, Daniel Hernández3 and
Thomas Wortmann1
1
Chair for Computing in Architecture (CA), Institute for Computational Design and Con-struction (ICD), Faculty
of Architecture and Urban Planning, University of Stuttgart, Keplerstraße 11, Stuttgart, 70174, Germany
2
Buro Happold, 17 Newman St, London, W1T 1PD, United Kingdom
3
Department for Analytic Computing (AC), Institute for Parallel and Distributed System (IPVS), University of
Stuttgart, Universitätsstraße 38, Stuttgart, 70174, Germany
4
Electronics and Computer Science, University of Southampton, University Road, Southampton, SO17 1BJ,
United Kingdom
Abstract
Architecture, engineering, and construction (AEC) projects require multidisciplinary solutions;
therefore, one physical asset results in several disciplinary representations. Interoperability
problems between different software often hinder disciplinary data integration, which prevents
the recognition of violated design constraints until it is too late. The open-source platform
Building Habitat object Model (BHoM) integrates many AEC concepts across existing
languages and platforms, allowing multiple discrete disciplinary representations of buildings.
The Linked Building Data Community Group of the World Wide Web Consortium uses
Semantic Web standards to store and share data. This paper explores and presents methods to
recast BHoM's object model as a knowledge graph using Semantic Web standards. It analyzes
BHoM in an ontological context by elaborating on its approach to object-oriented
programming and comparing it to the Semantic Web standards.
Furthermore, it presents BHoM RDF prototypes as a potential solution to the interoperability
problem of multidisciplinary design in AEC. It exemplifies BHoM RDF prototypes on a small
demonstrator project. When combined with Semantic Web standards, the BHoM framework
can increase the use of knowledge graphs in the AEC industry, improving data interoperability
and assisting design decisions through reasoning.
Keywords 1
Interoperability, Knowledge representation, Linked building data, Graph data modelling,
Ontology engineering, Data mapping, Open source.
1. Introduction
The building industry is fragmented [1], and requires multidisciplinary solutions [2]. To develop
disciplinary solutions, architecture, engineering, and construction (AEC) professionals create
discipline-specific information. Therefore, one physical asset results in several distinct disciplinary
representations [3]. An integrative approach, such as 'Co-Design' [4], considers design and analysis
LDAC 2022: 10th Linked Data in Architecture and Construction Workshop, May 29, 2022, Hersonissos, Greece
EMAIL: diellza.elshani@icd.uni-stuttgart.de (D. Elshani); alessio.lombardi@BuroHappold.com (A. Lombardi); al.fisher@
BuroHappold.com (A. Fisher); steffen.staab@ipvs.uni-stuttgart.de (S. Staab); daniel.hernandez@ipvs.uni-stuttgart.de (D. Hernández);
thomas.wortmann@icd.uni-stuttgart.de (T. Wortmann)
ORCID: 0000-0003-2902-341X (D. Elshani); 0000-0002-0780-4154 (S. Staab); 0000-0002-7896-0875 (D. Hernández); 0000-0002-5604-
1624 (T. Wortmann)
© 2022 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
32
methods simultaneously, encompassing building systems, materials, manufacturing, and construction
processes. Therefore multidisciplinary co-design must integrate data from the early stages of design;
furthermore, AEC professionals should be able to exchange data about building elements rather than
files [5]. In current practice, interoperability problems between different software often hinder data
integration. These interoperability issues may prevent the recognition of violated design constraints
until it is too late, i.e., until construction has already started.
To tackle interoperability issues the Industry Foundation Classes (IFC) data schema was created
[6]. The IFC data schema represents building elements, including semantic information such as
attributes, relationships, and abstract concepts or processes in a monolithic approach. However, the
fragmented nature of the AEC industry contrasts with the monolithic approach of IFC [1]. A common
data schema causes restrictions on how buildings can be represented and thus explored [7].
Contrary to IFC, the open source platform Building Habitat object Model (BHoM) [8] does not rely on
a single “neutral format” but rather provides adapters to map data among many AEC concepts across
existing languages and platforms, and it allows multiple discrete disciplinary representations of
buildings and building elements; with an open and extendable data dictionary.
The Linked Building Data Community Group (LBD-CG) [9] of the World Wide Web Consortium
(W3C) has focused on using Semantic Web standards as an open, decentralized alternative to the
existing centralized and file-based BIM 2 approaches of storing and sharing data [10]. Semantic Web
technology remains one of the most promising approaches to share data and achieve interoperability
between heterogeneous systems [5]. The Semantic Web uses knowledge graphs, a graph-structured
database model, to integrate and link data. Besides the advantages of linking data, formal Semantic
Web languages have rich expressivity supported by reasoning tools, which allow making claims, known
as axioms, about these data [11]. In AEC, this inferred knowledge would allow recognizing design
constraints from involved disciplines such as structural or fabrication from early design stages.
IFC is available in Semantic Web standards represented as a knowledge graph. But the support for
AEC knowledge graphs and linked data in tool development remains low [12]. The reason for this low
support might be the monolithic approach and hierarchical format of IFC in representing data. Elshani,
et al., [3] discuss centralized data exchange over a shared data schema as unsuitable for co-design and
argues for using federated data interoperability instead. Furthermore, they suggest using BHoM to
construct disciplinary representations of buildings and building elements as a framework that applies
federated interoperability. In a federated interoperability paradigm, each discipline uses its
corresponding tool to represent discipline-specific data, but they share a core ontology that all
disciplines can relate to and refine [3]. BHoM has a shared mapping process through identifiers, but
lacks a shared ontology which would allow linking BHoM objects. Linked data, where each discipline
manages local data, improves data interoperability; thus, it provides a good foundation for data
exchange [13].
Therefore, this paper compares BHoM and Semantic Web standards and presents prototypes that
introduce Semantic Web standards to BHoM, applying linked data principles alongside BHoM as a
potential solution to the interoperability problem of multidisciplinary design in AEC. Linked BHoM
object models would not only allow constructing many multiple discrete disciplinary representations of
building elements but also carry all the advantages of the Semantic Web, including reasoning ability by
augmenting the meaning of the pre-defined knowledge.
In this paper, we elaborate on BHoM in an ontological context by explaining its object-oriented
programing (OOP) approach and comparing it to Semantic Web standards. Afterwards, we present
mapping methods to convert existing BHoM object models to the standard database model for data
interchange on the web, the Resource Description Framework (RDF). We discuss and present technical
implementations of BHoM RDF prototypes. We also restrict BHoM data with RDF Schema (RDFS)
and the Web Ontology Language (OWL) vocabulary. Finally, we present a small demonstrator of our
approach, discuss its advantages and limitations. The presented building demonstrator is a building
described in BHoM objects converted to an OWL graph, using the developed method to convert the
BHoM data model to Semantic Web standards.
2
Building Information Modeling files using the IFC data schema.
33
2. Background
BHoM is an open source collaborative computational framework that integrates many concepts across
existing AEC languages and platforms [8] [14]. BHoM consists of (1) object models (oM), (2) engines
that operate on data, (3) adapters that map and translate data and (4) user interfaces to manipulate data.
Currently, BHoM has over 1.200 object models with an extendable data dictionary and adapters to over
30 different software. It also allows using customized object models. While OOP classes implement or
inherit implementations of methods, RDF does not have methods. But BHoM’s interpretation of OOP
is closer to an "ontological" approach than the “classical” OOP paradigm [15]. In the following sections,
we first discuss BHoM's approach to OOP and afterwards compare BHoM with the technological
standards set by the W3C and the LBD-CG.
2.1. BHoM ’s Interpretation of OOP
At its core, BHoM’s object model is a set of C# a programming language types (classes, interfaces,
enums, etc.) and methods. But BHoM takes an approach that often departs from conventional OOP
principles by: (1) Separating functionality from types and (2) focusing on ontologically meaningful
interfaces.
First and foremost, BHoM imposes that all functionality is separated from the types. In other words,
BHoM types have attributes but no methods. All functionality applicable to the oM types is isolated,
and it is primarily grouped in C# projects called Engines. Similarly to oM projects, these groups target
a specific domain, use specific namespaces and are suffixed with “Engine”, e.g. methods for Structural
Engineering are placed in the Structure_Engine under namespaces starting with BH.Engine.Structure.
This separation makes BHoM similar to a virtual object database like those used to convert objects to
relational databases 3.
Further, the development of BHoM types strictly follows the composition over inheritance principle.
There are numerous interfaces and interface implementations, with each interface holding not only a
contractual agreement with implementing types but also an ontological meaning.
2.2. Comparison of BHoM and Semantic Web standards
Whereas BHoM does not apply the standards set by the W3C, LBD community group, and developed
through the Linked Data for Architecture and Construction (LDAC) workshops, conversion is still
possible since they differ mainly in their technical implementations. The following subsections compare
BHoM to Semantic Web standards regarding their identifiers, data models, data schemas, data exchange
formats, and querying methods (see Table 1).
Identifiers. A noticeable difference between the two approaches is the way they identify things.
Whereas in the Semantic Web, all nodes and edges (except for literals, e.g. strings, dates, etc.) are
identified using a dereferenceable Uniform Resource Identifier (URI) [12], BHoM uses Globally
Unique IDentifier (GUID) to identify the object models. Linked Data of the Semantic Web relies on
HTTP URLs as identifiers of things [16]. But BHoM conventions also establish that every oM type and
every piece of functionality is separated into different files. Because each file is committed to a public
Git repo, each oM type is associated with a Unique Resource Identifier (URI) in the form of an HTTP
address.
Database Model. While the Semantic Web uses a graph-based data model [17], BHoM relies on an
object-oriented data model. RDF is a standard graph-based data model for data interchange on the
internet [10] and consists only of ‘triples’: subject, predicate and object [12], whereas BHoM does not
include explicit classes that describe the relationships between objects.
3
Database Object-Relational Mappers (ORMs)
34
Data Schema. The Semantic Web relies on two languages to state the schema and terminological
knowledge of an RDF graph: RDF Schema (RDFS) [18] and the Web Ontology Language (OWL) [19].
The former is a minimal language that describes classes and relationships. The latter extends RDFS
with features that can be mapped into an expressive description logic. A further approach to describe
RDF graphs is SHACL, which constrains data to follow the schema. Compared to relational data
models, where an upfront defined schema is followed at each step, modeling data as a graph offers more
flexibility to integrate new data sources [11]. On the other hand, BHoM object models are classified in
specific namespaces, e.g., Architecture_oM, Structure_oM, Acoustic_oM, etc., allowing disciplinary
representation of buildings and building elements. BHoM oM schema relies on the C# classes modeling.
For example, a representation of a room in the Architectural BHoM namespace is:
namespace BH.oM.Architecture.Elements
{
public class Room : BHoMObject, IRegion, IElement2D
{
public virtual ICurve Perimeter { get; set; } = null;
public virtual Point Location { get; set; } = null;
}
}
The namespace BH.oM.Architecture.Elements locates the Room type in the architectural domain,
while the suffix Elements is a term conventionally used throughout BHoM to categorise things in a
domain of reference. The Room type owns two properties, Perimeter and Location, which are in turn
other oM types. Each type and property (e.g. Perimeter) is usually accompanied by description attributes
(e.g. ICurve) that help convey their semantic value.
Querying. While the Semantic Web uses SPARQL to navigate data, BHoM querying is generally
implemented through framework-specific functions hosted in the BHoM_Engine Query classes. In
addition, certain BHoM_Adapters are able to convert oM models to other queryable formats, for
example, the Mongo_Adapter. An advantage of graph query languages is their compactness for certain
queries [20]. Furthermore, graph querying also allows retrieving and manipulating data from combined
graphs. Specifically, SPARQL allows the full use of relational operators, including path expressions.
Table 1
BHoM and Semantic Web standards comparison
Database Data Exchange Querying
Identifiers Data Schema
Model Format
TTL, N-Triples,
Semantic RDFS, OWL,
URI RDF JSON-LD, SPARQL
Web SHACL
RDF/XML
BHoM
Object- BHoM_Engine Query
BHoM GUID Namespaces and JSON
Oriented and MongoDB
BHoM classes
2.3. Summary
Considering BHoM’s rich semantics and its approach to OOP in separating functionality from the
objects, it is possible to state that the BHoM oM is effectively akin to an ontology: because each oM
class owns semantic data, we can have a mapping to an ontological class. Not only each BHoM class
can be mapped to an ontological class, but it is also possible to derive many ontological relationships
from the BHoM classes (e.g. from inheritance or interface classes).
35
Currently, BHoM does not implement any class to represent the relationship between different oM
classes. For example, a column can be described in the physical domain via the oM type
BH.oM.Physical.Elements.Column and it can have an alternative representation in the structural
engineering domain through the oM type BH.oM.Structure.Elements.Bar. Concretely, a typical design
workflow may involve conversion or creation of a structural model for finite element analysis from a
BIM model, with the logic and relationships between these distinct multidiscipline elements being
encoded inside the computational process/script or indeed lost within any manual steps taken. However,
there is at present no class that can capture these possible relationships between instances of oM
Columns and oM Bars, say, to enable logical persistence beyond the script itself.
The RDF simple entailment semantics follow the open-world assumption, and ontologies using the
RDFS and OWL languages follow the open-world assumption. On the contrary, SPARQL has operators
that do not follow the open-world assumption, such as operators minus and optional. Under the open-
world assumption, the RDF/OWL ontology admits more interpretations than the BHoM model under
the closed-world assumption. All inferences under the open-world assumption are also valid under the
closed-world assumption. Hence, RDF/OWL inferences do not hinder interoperability. BHoM is
written in an OOP language for convenience reasons, but it does not adhere strictly to OOP design
patterns. BHoM is designed to be extensible and to avoid limitations in representational potency and
interoperability. This paper shows how BHoM models can be translated to RDF/OWL ontologies, and
strictly speaking, the resulting ontology is not equivalent to the BHoM model. Inference in BHoM
models can be complemented with RDF/OWL features.
By leveraging BHoM’s particular approach to OOP and bridging the gap in the definition of
relations between oM types, it is possible to convert BHoM concepts into Semantic Web vocabularies
such as RDF, RDFS and OWL. BHoM ontology can be enriched with other relations, allowing
inferential reasoning to be applied to oM models.
3. Methods
As argued in the previous section, BHoM’s rich semantics and BHoM’s approach to OOP in separating
functionality from objects make it possible to convert BHoM object models to an OWL ontology. In
order to perform such a conversion, we considered the following sub-problems: (1) Terminological
translation and generation, which represents the ontology of BHoM objects; and (2) Assertional
translation and generation - which will contain object instances, specifically actual BHoM data, in an
RDF data model. This paper focuses on the first sub-problem. It proposes a set of mappings (see Table
2) between BHoM framework types, type properties and inter-type relationships to ontological
concepts, such as classes, object properties and data properties as well as datatypes.
Mapping BHoM to RDF requires a specific approach because BHoM doesn’t have oM types that
represent relationships between different oM types. Therefore, before mapping existing BHoM
concepts to RDF, RDFS, and OWL, a new oM interface IRelation is introduced and a set of classes
implementing it which serve as owl:ObjectProperties. Currently, three classes are introduced that
implement IRelation: hasProperty, IsAListOf and RequiresProperty. Together with information
extracted from oM types, these newly introduced classes obtain a the foundation to representing the
code and its semantic knowledge in a graph-based database.
Table 2 presents several mapping from BHoM oMs to Semantic Web standards, including
mappings for BHoM components such as identifiers, object classes, inheritance and interface
implementations, class properties, as well as datatypes.
BHoM classes and interfaces (such as BHoM_Room or BHoM_ICurve) are mapped to a class in
OWL. Both class inheritance relations and interface implementation relations are represented as
rdfs:subClassOf. BHoM interfaces are ubiquitous and are often used to represent concepts in a
taxonomic manner. For example, the interface IElement1D represents all types that have a linear (1
dimensional) representation, e.g.: columns, beams, pipes. This taxonomic information that interfaces
hold makes the interface implementation relationship between concepts an ideal candidate for the
rdfs:subClassOf.
36
A BHoM class may define a property for its instances. The values that the property can take is
defined in the BHoM class. For example, the code "public virtual ICurve Perimeter" in the definition
of class Room states that the property Room#Perimeter takes values from objects that implement the
interface ICurve. The values of the property can be mapped to RDF terms, which can be instances of
classes or literals.
A technical implementation of the conversion, including the presented mapping concepts, is shown
in the results section.
Table 2
BHoM to RDF mapping concepts
BHoM component Semantic Web equivalent Comment
Concept identifier URI The original GitHub oM class URI.
GUID -Instance identifier URI URI built on a domain name,
concatenated with the GUID of
BHoM instances.
Object class an owl:Class, An exception to this rule are BHoM
e.g. BH.oM.Physical.Elements e.g.bhom:Physical.Elements Enum types.
Column Column
Class inheritance relation rdfs:subClassOf
Interface (eg. IElement1D) bhom:IElement1D a owl:Class In BHoM interfaces are ubiquitous
and are often used to represent
concepts in a taxonomic manner.
Interface implementation rdfs:subClassOf
relation
Class property Type owl:Class, If the property is a class with
(eg. Perimeter of Room, or or rdfs:Literal further properties it becomes an
OrientationAngle of Bar) owl:Class, else rdfs:Literal
Property relation bhom:hasProperty A new property named
-not implement in BHoM Type owl:ObjectProperty bhom:hasProperty is introduced
or type owl:DatatypeProperty
Datatypes xsd rdfs:Datatype System.String are represented with
xsd:string; BHoM types that do not
fall in any other category are
treated as Literals.
Lists Type rdf:Seq To simplify serialization rdf:Seq is
proposed instead of rdf:list.
IEnumerables and HashSets Type rdf:Bag Unordered collections, since they
do not possess ordering property.
Dictionaries Type rdf:Bag of owl:classes Dictionaries are unordered
collections of Tuples. A named
graph is used to represent a set of
tuples (Key/Value).
Enums Type rdf:Alt rdf:Alt doesn’t have the ordering
property C# Enums have, but such
quality only matters from a
programming perspective. rdf:Alt
also allows for a default value,
which is mapped to the first value
of the enum in BHoM
37
4. Results
The previous chapter introduces mapping methods of BHoM’s object model to the RDF model. The
technical implementation of BHoM RDF is currently at a prototype stage whose main aim is to
demonstrate its feasibility. Its development is open-sourced in the GitHub repository RDF_prototypes
(https://github.com/BHoM/RDF_Prototypes). The repository consists of a BHoM RDF_Toolkit, a
Visual Studio C# solution built on the BHoM framework. The Toolkit parses the existing code base
using a mixture of C# Reflection, document parsing and processing, to build a graph of the BHoM types
and their code-base relationships (inheritance, interface implementation, property exposure, etc.) using
RDF, RDFS and OWL vocabulary. A close up view of BHoM oM, BHoM_Object base described in
BHoM (left) and its generated graph (right) is presented in Figure 1. Whereas every BHoMObject
implements the IBHoMObject interface, IBHoMObject implements the IObject interface. Therefore in
OWL convention, a BHoMObject becomes a subclass of IBHoMObject, and IBHoMObject is a subclass
of IObject. Properties such as GUID, Name, Fragments, Tags and Dictionary belong to the interface
IBHoMObject; therefore, they belong to the IBHoMObject class in its OWL representation.
Figure 1: BHoM_Object base (left) and its corresponding graph (right).
The RDF_Toolkit implements a conversion to the JSON-LD structured format for every existing BHoM
object, resulting in over 1200 classes. We focus on the generations of the following ontologies of the
BHoM framework:
1. Domain-specific ontologies, or namespace ontologies. These are ontologies that illustrate the
relations between classes defined in the domain-specific BHoM namespaces, e.g.
BH.oM.Architecture, or BH.oM.Structure (structural engineering) (see Fig. 2).
2. Cross-domain ontologies, which describe inner and interface relations between namespace
ontologies.
3. Concept-specific ontologies, or object ontologies, which focus on specific BHoM classes. E.g. a
cluster of building elements that correspond to a specific building system.
38
Figure 2: Graph of the ontology for the BH.oM.Structure (structural engineering) namespace.
4.1. Building Demonstrator
Following the concept-specific ontologies generation, this section presents a demonstrator building
described in BHoM objects and in its generated graph database. The building consists of five BHoM
oMs: room, wall, column, floor, and ceiling. Additionally, the graph includes all oM that help to build
the aforementioned building elements (e.g. Curve, Point, and Name as input oMs to construct a Room).
To search for classes that build oMs graphs, the tree recursion is set to 100. This parameter works to
iteratively define how many levels on the graph nodes are expanded. This large number helps to reveal
all atomic data entities. The resulting building graph is visualized in the WebVOWL (see Fig. 3). The
demonstrator building graph resulted in 231 triples, 47 unique Classes, including main concepts such
as Room or Column, and 145 Properties, mainly HasProperty with different domains and range. As
example from the exported graph in *.ttl format, an owl:class (Room) and an owl:ObjectProperty
(HasProperty) are presented below:
# --------------------------- Class 1-------------------------
rdf:type owl:Class;
rdfs:subClassOf
rdfs:label "Room (BH.oM.Architecture.Elements)"@en .
39
# --------------------------- Property 4-------------------------
rdf:type owl:ObjectProperty ;
rdfs:label "HasProperty"@en;
rdfs:domain ;
rdfs:range .
Since the domain and range of the properties differ, the graph resulted in a large number of properties
with the same label (mainly HasProperty). To avoid confusion between different owl:ObjectProperties
naming of the relations needs to be reevaluated. However, the representation of BHoM building data in
RDF triples demonstrates that any BHoM object model can be mapped to a graph-based database model
using Semantic Web standards. Such workflows with selected building elements allows to describe
specific building systems and form re-usable building system ontologies from BHoM.
In the scope of this paper, methods to populate the graph with actual data from Grasshopper 3D are not
investigated. However, data population from different editors (such as Protégé) is possible,
demonstrating the feasibility of a complete BHoM RDF knowledge graph. Extending this framework
to generate object instances from design platforms through the BHoM interfaces would provide a solid
foundation for describing complex building models’ in knowledge graphs across many AEC software
in a straightforward way.
Figure 3: BHoM RDF building demonstrator, with a zoom on the Room class.
40
5. Conclusion
This paper presents BHoM's RDF prototypes as a potential solution to the interoperability problem of
multidisciplinary design in AEC. The method section presents a mapping approach of the BHoM oM
to Semantic Web standards. The results section demonstrates a procedural generation of ontologies
from BHoM oM types, resulting in customized ontologies. The RDF prototype results show that further
refinement of the ontology classes, properties and data types is needed. Future work will focus on
refining BHoM’s terminological translation that RDF_Toolkit generates, e.g. refining relations,
developing alignment modules between domain-specific ontologies, modularising concept-specific
ontologies based on building systems, etc.
Further work will also consider BHoM’s assertional translation, which follows with the questions
how we can scale this project to a framework that allows building ontologies within Grasshopper 3D.
Such work makes it feasible to represent any oM model in a knowledge graph. BHoM knowledge
graphs will serve to validate assumptions across distributed multidisciplinary design models.
RDF_prototypes Toolkit should include features that allow the procedural generation of ontologies
from any supported BHoM_UI and for any given set of BHoM oMs. Users should be able to define
inter-type relations to describe ontological connections between different types and their properties.
Further work also will consider alignment modules to existing AEC ontologies such as Building
Topology Ontology (BOT) and ifcOWL.
We expect that these efforts will ultimately contribute to an increased use of knowledge graphs in
the AEC industry, which would address interoperability problems without file conversions and improve
decision-making via inferential reasoning.
6. Acknowledgements
Partially supported by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation)
under Germany's Excellence Strategy - EXC 2120/1 – 390831618 and COFFEE - STA 572_15-2.
7. References
[1] J. Werbrouck, P. Pauwels, J. Beetz, and E. Mannens, Data Patterns for the Organisation of
Federated Linked Building Data. 2021.
[2] J. R. Haymaker and C. K. M. Fischer, “A methodology to plan, communicate and control
multidisciplinary design processes,” 2005.
[3] D. Elshani, T. Wortmann, and S. Staab, “Towards Better Co-Design with Disciplinary Ontologies:
Review and Evaluation of Data Interoperability in the AEC Industry.,” 2022.
[4] J. Knippers, C. Kropp, A. Menges, O. Sawodny, and D. Weiskopf, “Integrative computational
design and construction: Rethinking architecture digitally,” Civil Engineering Design, vol. 3, no.
4, pp. 123–135, Sep. 2021, doi: 10.1002/cend.202100027.
[5] J. F. Tchouanguem Djuedja, F. H. Abanda, B. Kamsu-Foguem, P. Pauwels, C. Magniont, and M.
H. Karray, “An integrated Linked Building Data system: AEC industry case,” Advances in
Engineering Software, vol. 152, p. 102930, Feb. 2021, doi: 10.1016/j.advengsoft.2020.102930.
[6] buildingSMART, “Industry Foundation Classes. bSI Standards,” n.d.
http://www.buildingsmart.com
[7] B. Toth, P. Janssen, R. Stouffs, A. Chaszar, and S. Boeykens, “Custom digital workflows: a new
framework for design analysis integration,” International Journal of Architectural Computing,
vol. 10, pp. 481–500, Dec. 2012.
[8] “BHoM. The Buildings and Habitats object Model,” https://bhom.xyz/, n.d.
[9] P. Pauwels, Dr. K. Mcglinn, S. Törmä, and J. Beetz, “Linked Data,” in Building Information
Modeling: Technology Foundations and Industry Practice, 2018, pp. 181–197. doi: 10.1007/978-
3-319-92862-3_10.
41
[10] P. Poinet, D. Stefanescu, and E. Papadonikolaki, “Collaborative Workflows and Version Control
Through Open-Source and Distributed Common Data Environment,” in Proceedings of the 18th
International Conference on Computing in Civil and Building Engineering, vol. 98, E. Toledo
Santos and S. Scheer, Eds. Cham: Springer International Publishing, 2021, pp. 228–247. doi:
10.1007/978-3-030-51295-8_18.
[11] A. Hogan et al., “Knowledge Graphs,” Synthesis Lectures on Data, Semantics, and Knowledge,
vol. 12, no. 2, pp. 1–257, Nov. 2021, doi: 10.2200/S01125ED1V01Y202109DSK022.
[12] P. Pauwels, A. Costin, and M. H. Rasmussen, “Knowledge Graphs and Linked Data for the Built
Environment,” in Industry 4.0 for the Built Environment, vol. 20, M. Bolpagni, R. Gavina, and D.
Ribeiro, Eds. Cham: Springer International Publishing, 2022, pp. 157–183. doi: 10.1007/978-3-
030-82430-3_7.
[13] S. Törmä and N. V. Hoang, “DRUMBEAT platform—a web of building data implementation
with backlinking,” in eWork and eBusiness in Architecture, Engineering and Construction, 1st
Edition., 2016, p. 9.
[14] P. Poinet and A. Fisher, “Computational Extensibility and Mass Participation in Design,” 2020,
pp. 40–47. doi: 10.2307/j.ctv13xprf6.9.
[15] A. Kay, “A Few Thoughts About ‘OOP,’” n.d.
https://d1b10bmlvqabco.cloudfront.net/attach/i4g9dayv6xc4gn/gsmlulvh9ga/i61imjtf6ryn/kayo
op.pdf
[16] T. Berners-Lee, “Note on Linked Data,” 2006.
https://www.w3.org/DesignIssues/LinkedData.html
[17] L. Ehrlinger and W. Wöß, “Towards a Definition of Knowledge Graphs,” Sep. 2016.
[18] D. Brickley and R. V. Guha, “RDF Schema 1.1.” 2014. [Online]. Available:
https://www.w3.org/TR/2014/REC-rdf-schema-20140225/
[19] P. Hitzler, M. Krötzsch, B. Parsia, P. F. Patel-Schneider, and S. Rudolph, “OWL 2 Web Ontology
Language Primer (Second Edition),” W3C Recommendation, 2021.
https://www.w3.org/TR/owl2-primer/
[20] L. Aw, L. Livermore, and I. Kaplan, A Semantic Graph Query Language A Semantic Graph Query
Language 1. 2006. doi: 10.13140/2.1.3429.0568.
42