This problem instance paper addresses the need for an industry wide modelling paradigm and language that allows the formalisation and representation of building knowledge by domain experts (architects, engineers). Herein, the special nature of the construction industry (e.g. its openness and semantics) in comparison to other industries and the complexity that arises from this, is recognised. The research needed covers a computation independent meta-model and accompanying modelling language and the added value of the knowledge-based configuration paradigm therein. The research outcome might spark renewed interest in an all-round universal knowledge representation language in the field of building information modelling (BIM) and even prove valuable for other 'less complex' industries.
the ’open’ nature specific to the building industry is
presented. In Section 3, the need to call some basic premises
A modelling environment for the design, construction, of previous eforts into question is addressed. Section 4
inoperation and end-of-life of buildings, in which it is im- troduces the knowledge configuration paradigm and
outpossible for the end user to make modelling mistakes lines the work of examining the possible benefits and
chalbecause of the integration of personal, company, stan- lenges of its application for building knowledge. Lastly,
dardised and regulatory knowledge, has been envisioned possible further extension of the research is outlined in
since at least 1999 [
While some attempts have been made in the field Industry
of building information modelling, also named BIM,
[
The rest of the paper is as follows. First, in Section 2, • Many parties are involved in a project and parties
change with every project. • Vast numbers of manufacturers and products for any building part (from traditional to innovative), on any scale (up to the building itself) are available on the market. • Both a product directly and an onsite composition from products might provide a solution for a required part (e.g. a wall as prefabricated masonry or on site masonry). • Project specifications often don’t prescribe spe
cific products. • Product delivery might not include some parts but only list its requirements (called ‘open systems’ in this text, as opposed to proprietary, ‘closed’ systems’).
This openness is reenforced at a European level
through regulation (Construction Product Regulation[
Designers, contractors and manufacturers refer to these documents and generally only complement them with their specific requirements.
The need for a common language for all the stakeholders is even more acute because of the challenges facing the construction industry: climate and environment, robotics, artificial intelligence, digital twins, etc. and this while facing a shrinking workforce (both engineers and workers). 3. Work Part 1: Basic Premises In light of the unsuccessful attempts to develop a universal knowledge representation language for the construction sector (see Section 1), it is necessary to first list these experiments, examine their potential shortcomings and generate new ideas and approaches. Based on this work, it will then be possible to define the premises of a meta-model and its accompanying modelling language.
A preliminary examination already allows some underpinnings of previous eforts to be called into question.
Firstly, are existing attempts suficiently intuitive? The sheer volume of available building expertise will necessitate the creation, verification and maintenance of knowledge models as a collaborative endeavour to be done by domain experts (e.g. architects and engineers) directly without a need for intermediaries like knowledge engineers.
Secondly, are these eforts ontological suficiently sound? Some examples of overlooked building ontology: • A building concept can play diferent semantic roles: it can simultaneous be a conceptual ‘container’ of parts, items, variants and positions. For instance, a window is composed of parts for its operation: generally, a frame, glazing(s) and hardware. Yet, in a project, the concept might also represent more than one window, for example, a generalisation of the 4 physical windows (items) of the front facade. The concept might also express the variants allowed in the specification (e.g. the designer allows freedom in the choice of hardware to the contractor) or ofered by the product (a window available in diferent heights).
Lastly, variability can also exist within a single
physical item (called positions in this text): a
window can be open or closed, supports for raised
ofice floors having an adjustable height or a
ventilation unit with diferent flow rates. Therefore,
at least conceptually, properties must be thought
of as potentially having diferent domains over
its parts, items, variants and positions.
• Any level of abstraction should be allowed from
the obvious generic concept ’door’, over
’partition’ (covering window, door, wall, floor, etc. ) up
to a ‘building object’ concept.
• Innovative products exist for any building part
and therefore must be expected: a generic concept
should not be confined to its traditional meaning
but allow almost unlimited heterogeneity.
• The semantics of the aforementioned ‘position’
can be further developed to also hold changes
like the onsite length adjustment of a beam, the
removal, addition or replacement of a part (e.g.
a filter change), or the diferent installation or
use options of a product. With the addition of
a ‘location‘ and ‘time’ property an item could
be tracked in space and time, with each change
being a new position. Thus covering the complete
life-cycle.
• The semantics of the hierarchical relations
between a concept and its parts and items
respectively, should not be confined to their traditional
definitions. A concept is primarily a
generalisation of its items but this relation can have a
part-like meaning through emergent properties
like cardinality, overall cost, energy loss etc.
Likewise, a concept might have properties that are a
generalisation of the part properties: for example,
a masonry wall concept enforces the same colour
domain for mortar and bricks.
• The ontology should be polyhierarchical (a single
concept occurs in more than in one place) [
Product
User
Generic concept Specification
Products
Lastly, what is the universe of discourse of the attempts? In any industry, knowledge is interconnected, but in the construction industry, due to its open nature, this is scaled to the entire industry. It might therefore be impossible to efectively isolate a particular aspect in a model while striving for its universal use. The work should therefore outline the contours of what constitutes as building knowledge.
challenges to the paradigm can already be identified.
The knowledge-based configuration paradigm defines a Can configuration cover the needs resulting from the
configuration model as a set of variables with their do- work of Section 3: the ontology, the domain of discourse
mains and with product and user constraints limiting and will it be enough to allow domain experts to take on
the possible combinations of variable values, and a solu- the role of knowledge engineers? A task resembling the
tion (a configuration) as an assignment of single values work of [
Another appealing aspect is the possibility of a
representation that is non-causal, meaning that in a particular
constraint which variables are input and which are
output need not be defined. Though the building modelling
process is largely experienced as procedural, directional,
top-down, where decisions thought of as the most
impactful, like the overall shape of the building, are taken
ifrst and then gradually more detailed decisions are taken,
it is argued that this must not be imposed by the
modelling environment. Light requirements might determine
the number and shape of windows instead of the other
way around [
In light of circularity, products available for reuse might even become requirements instead of solutions. The upcoming practice of early involvement of all stakeholders entails the registering of big and small requirements before designing is started.
The knowledge-based configuration paradigm might
even make the typical iterative design process obsolete,
creating substantial savings. Though the
knowledgebased configuration paradigm seems promising, some
• The knowledge base will be incomplete. This
because of the amount of standards, products,
etc. , the gradual nature of the design process or
confidentiality (e.g. pricing information). Also,
tacit knowledge is prevalent with construction
parties.
• As it is impossible for any product knowledge
base to contain all building products available on
the market, the user requirements (the project
specification) do no operate ‘within’ or on a
single product knowledge base, cf. Chapter 6 of [
It is rather that both constraints defining multiple products and user requirements operate in the knowledge base of the generic concept (e.g. a generic window, door, wall, etc.) and it is the intersection of the specification and products solution spaces that represents the configurations that provides a solution and this only for the known products (see Fig. 1). • The user should be presented only with valid options at any one moment in the modelling process.
It is therefore not enough to solve for one valid solution but continuously for the complete valid solution space. This is especially necessary in a multi-user environment, where parties operate in each other’s solution space. • Building industry knowledge is distributed. Not only for product knowledge (diferent manufacturers) but also generic knowledge (building regulations and standards) is generated by diferent institutions at diferent geographical levels (municipality, country, EU level, etc.). Expecting all of them to formalise their knowledge on one location seems unrealistic. The product and generic knowledge base will be distributed and maybe also the project requirements base. Consistency, verification and maintenance of distributed generic knowledge might seem especially challenging. • A solution is not always a product variant (a single product item). A product item position (a specification might require a specific height for a support, yet a support adjustable in height might be acceptable), a product item part (order the whole product to use only one of its parts) or product items combined (concrete from diferent suppliers for one single structure or products combined as parts to make up the specified whole) might prove to be equally valid solutions. • In open systems, as defined in Section 2, the constraints for the not included parts of a (supply side) product might in efect be a product independent (demand side) specification. Making it necessary to solve the product knowledge base ifrst. 5. Further Expansion of Research Once the conceptual foundation and configuration as a solution established, the research could be extended: • As touched up in the introduction, a need for
optimisation might arise. • New solving methodologies: computationally more eficient surrogate models might proof to be more practical or the use of generative design where the solution space is explored in an iterative process through single exemplary solutions. • Propositions for domain expert and end user in
terface might result from the work. • New ways of knowledge acquisition like through voluntary open collaboration of domain experts or the use of artificial intelligence (large language models, natural language processing) to extract knowledge.