BOT: the Building Topology Ontology of the W3C Linked Building Data Group

Tracking #: 2224-3437

Mads Holten Rasmussen
Maxime Lefrançois
Georg Ferdinand Schneider
Pieter Pauwels

Responsible editor: 
Krzysztof Janowicz

Submission type: 
Ontology Description
Actors in the Architecture, Engineering, Construction, Owner and Operation (AECOO) industry traditionally exchange building models as files. The Building Information Modelling (BIM) methodology advocates the seamless exchange of all information between related stakeholders using digital technologies. The ultimate evolution of the methodology, BIM Maturity Level 3, envisions interoperable, distributed, web-based, interdisciplinary information exchange among stakeholders across the life-cycle of buildings. The World Wide Web Consortium Linked Building Data Community Group (W3C LBD-CG) hypothesises that the Linked Data models and best practices can be leveraged to achieve this vision in modern web-based applications. In this paper, we introduce the Building Topology Ontology (BOT) as a core vocabulary to this approach. It provides a high-level description of the topology of buildings including storeys and spaces, the building elements they contain, and their web-friendly 3D models. We describe how existing applications produce and consume datasets combining BOT with other ontologies that describe product catalogues, sensor observations, or Internet of Things (IoT) devices effectively implementing BIM Maturity Level 3. We evaluate our approach by exporting and querying three real-life large building models.
Full PDF Version: 

Major Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Simon Scheider submitted on 22/Jun/2019
Major Revision
Review Comment:

In this article, the authors introduce the Building Topology Ontology (BOT), a lightweight OWL ontology that allows reasoning with and publishing Building Information Models (BIM) on the Web, including the nested concepts building, storey, construction elements and sites as well their topological interfaces. This allows them to share building models in terms of 3D data of diverse formats, and to query over a building's nested form, e.g., in order to get all appliances in a building or the thickness of the building's walls. The authors compare BOT with the state of the art in building information models, propose a lightweight formalization and align it with DUL and other state-of-the art ontologies, show how 3D geometric models can be linked, discuss application scenarios and evaluate the ontology on three BIM models using six queries including DL and SWRL inference, listing time performance measures.

Without doubt this is a description of a solid and rather mature ontology development, based on the work of the W3C LBD community group and taking into account years of technical development in the BIM community. The design choices made sense to me and the text is well written and well argued. Also the evaluation and application scenarios are convincing.

Still I think the text would require a major revision to focus on some essential points:

- Since BOT was published in earlier papers of the authors (ref no. 50, 51), it is necessary to say more clearly what this article adds in terms of novelty.
- The introduction requires a much stronger motivation and a more concrete research goal for this particular paper. The current goals (REQ1-4) like "support of web-based information exchange" are much too vague to serve as research questions for this specific article. A good way to evaluate ontologies is in terms of concrete competency questions, by showing that questions motivated in the introduction of the paper can be translated into answerable queries later on, similar to the queries Q1-6 or the application scenarios in sect 4. I would recommend the authors therefore to formulate and motivate such concrete questions in the introduction based on their examples. It is necessary to show which specific research problems can be solved with BOT, beyond just claiming to improve information exchange in more general terms, as formulated in BIM maturity level 3. The latter goal is also problematic because difficult to show in the paper. As a matter of fact, it was not shown in the paper how BOT improves all these aspects mentioned in REQ1-4.
- What does "definitely not fully web-ready" (page 5) mean? Similarly, it remains unclear what "as the file-based exchange mechanism prevails" refers to. What is wrong with the exchange of files? RDF is also exchanged in terms of files, so what is the point the authors want to make here...? It remains unclear how this relates to the goals RE1-4. Please reformulate.
- The authors should rethink whether their goal is really to unify building ontologies, as claimed in several parts in the text, given there might be legitimate reasons to have different ontologies for different purposes. Please reformulate.
- Regarding the design choices, I was wondering what the ontological distinction between "elements" and "zones" really entails, given that these two classes have very similar/equivalent mereo-topological structures and that rooms and buildings are indeed constructed and have functions, too. What is the core distinction, and more importantly, why is it needed? This design decision now enforces a lot of repetitive formal structure which could be avoided otherwise. Similarly, the meaning of bot:Space remains a bit vague for me, and also: why is it considered an artefact?
- Why do the authors not reuse previous work in mereo-topologies to encode building topology? What about RCC8? Mereological parthood relation ontologies?
- Shouldn't interfaces overlap with at least 2 elements or zones, instead of one (Otherwise, why should it be called "inter"-face)?
- It would be helpful to explain better what a zeroPoint is (as far as I understood a reference point for turning a local coordinate into a geocoordinate?)
- The related work section lacks a discussion of how BOT relates to 3D interoperable models developed in GIS, such as CityGML

Review #2
By Yingjie Hu submitted on 24/Jun/2019
Minor Revision
Review Comment:

This paper presents Building Topology Ontology (BOT) developed for facilitating Web-based exchange of building models. The authors present the necessity of developing BOT, classes and properties of BOT, how BOT can be combined and aligned with existing ontologies, and how BOT can be used to annotate real building models to support queries and reasoning. Overall, this paper is very well written. I only have a few minor suggestions.

- Lines 103-111: The authors listed four requirements for reaching BIM Maturity Level 3. It would be great if the authors can explicitly state how the developed BOT help fulfill these four requirements in the conclusion of this article.

- Line 437: "bot:containsZone": Is it possible that two Zones occupy exactly the same 3D spatial extents? If so, can the property "bot:containsZone" be applied to such a situation? Some topological relations, such as DE-9IM, differentiate "equals" and "contains". If "bot:containsZone" is applicable, maybe the authors could add a one-sentence clarification here.

- Lines 506-507: The authors provided an example of assigning a single WGS 84 point to a bot:Site. What if one would like to provide a more accurate spatial footprint of the site by e.g., including the coordinates of four corner points of the site (assuming the shape of the site is a rectangle)? Could the authors explain how such a situation can be handled?

Review #3
By Tomi Kauppinen submitted on 05/Jul/2019
Review Comment:

My review is via the dimensions:

(1) Quality and relevance of the described ontology (convincing evidence must be provided).

This is a mature work reporting about BOT, which is released as a public draft by the authors' Linked Building Data Community Group. Authors do great job in placing the work among related work, and provide evidence via examples (of the ontology elements), via practise (when using with other ontologies), and via evaluation (both "BOT and BOT exporters").

(2) Illustration, clarity and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology.

This is a very good piece of work, very clear, lots of illustrations, excellent read. I am totally convinced that this can be published as it is.

One philosophical question & comment though. What the authors think of different kinds of "spaces" within buildings, and what they might be? In my previous projects we have listed quite a few of them, but still I am unaware of any attempt to formally represent them. Perhaps interesting future work, or is there already some substantial work done in the area? Happy to discuss this further.


Note that this is an unsolicited review. I am not recommending anything to the editors, either for acceptance or rejection of the paper. I am a colleague and coworker of Maxime Lefrançois, and a member of the Linked Building Data Community Group. Official reviewers of this paper should (obviously) not read this review before submitting their report to the editorial board.

I have a few comments on the BOT ontology and the paper. I start with the main comments and minor comments on the paper follow.

In Section 3.1, it is said that the ontology is in SRIN(D). After looking at the ontology file to date, I see that the ontology is almost in OWL 2 RL. What it needs to be classified as OWL 2 RL is the following:
- remove the axiom Interface \sqsubseceq \leq 1 interfaceOf \top. This axioms is not really useful at all in practice, and puts the ontology outside OWL 2 RL. One of the design goals of BOT is that is should be lightweight. If it's in SRIN(D), then there is no guarantee in the efficiency of reasoning algorithms. If it can be in OWL 2 RL, then relatively efficient rule-based reasoning procedures can be applied.
- schema:rangeIncludes and schema:domainIncludes should be declared as owl:AnnotationProperties (in any case, domainIncludes and rangeIncludes are not defined very precisely, as opposed to rdfs:range and rdfs:domain)
- xsd:date is not allowed in OWL 2 DL, the dates of creation and modification could be changed to xsd:dateTime. It's not very important since they are only used as a value of annotation properties, but it would not be too difficult to add the time of modification, even if it is approximate (and in the ideal case, it could be added automatically)

Fig.2 says that "bot:hasElement" is a sub-property of "bot:containsZone o bot:hasElement". This is the other way around, since OWL 2 cannot express such constraint

Similarly, in Fig.3, "bot:hasElement" is said to be a sub-property of "bot:containsZone o bot:containsElement". This is the other way around.

In Sec.3.3, the subproperty axioms are inverted, as explained above.

In Sec.3.4, the paragraph on minCardinality could be removed, according to what I said about the ontology profile above

In Sec.3.6, concerning the aligments, what does it mean that a term in BOT is aligned with a term in another vocabulary? Does it mean it is equivalent? Does it mean it is a subclass? A superclass? Something else? What does "weakly aligned" means?

Sec.4.1 should ot start with a figure.

in Sec.5.2, \bf{EL}, \bf{DL} etc are not explained.

Final remark about the ontology file: it contains statements like "bot:XYZ rdfs:label "TODO"@es". This means that the human readable name of the term is "TODO" in the Spanish language. This should not be part of the ontology. Instead, it should be commented out. More languages can be added as needed whenever they come.

Minor remarks:
- Harmonise the spelling: "organisation", "digitalization", "realization", "centralised", "conceptualization", "organised", "organising", "standardized", "formalizes", "formalizes", "localization", "geo-localize", "specialized", "visualize", "colourize", "visualized", "visualize", "colouring", "decentralized", "Visualization", "summarises", "optimisation", "decentralised"
- use \url{} and the hyperref package for the hyperlinks
- always put the footnote marks after the commas and dots
- use `` (opening double quotes) and '' (closing double quotes) instead of straight double quotes
- when referring to URLs where the current content is relevant (e.g., number of results for the "building" keyword in LOV) indicate the date of retrieval
- ontology terms like "bot:Element" should be in a different font (the term owl:minCardinality is in a distinct font that could be reused for all ontology terms). This helps differenciating normal words from RDF terms when you are not super attentive

- footnote 1 could be a bibliographic reference

- "As a result, the resulting ifcOWL" -> avoid repeating "result", e.g., "The resulting ifcOWL" or "As a result, the ifcOWL"
- "Monolithic size" -> monoliths do not have a certain size. They are just "one stone", by definition, be it small or big

- "an abstract requirements model" -> requirement

Table 1:
- There is "Mb" and "MB". If you mean "Megabyte", then it is "MB".

- "150, 000" -> 150,000

- "effort by the ." -> ???

- [40] -> where is it published?

Dear authors,

I have to say that the article is very complete and people not familiarized with the BOT ontology might find it very helpful. The section I liked most was 5.2. Many times, I find it difficult to assess an ontology, and measuring the result times of different queries for different datasets is something that the community could definitely adopt for evaluating ontologies.

I have a question regarding the alignments of BOT with the DUL ontology that are mentioned in page 10. I cannot find the mappings file online, so my question areisbased on what you wrote on the article. You mention that some BOT concepts are “weakly alignment” with DUL concepts. What does this exactly mean? What is the difference between a “weak alignment” and “normal alignment” (if it exists such types of alignments)?

I also spotted what it may be a typo in the snippets presented in pages 11 and 12. In snippets one and three the following triple is defined: a bot:Space. And in the second snippet: a bot:Element. Should three snippets be consistent in the definition of ?

Other than that, I can only congratulate you for this nice article.