Introduction

A modelling environment for the design, construction, operation and end-of-life of buildings, in which it is impossible for the end user to make modelling mistakes because of the integration of personal, company, standardised and regulatory knowledge, has been envisioned since at least 1999 [1]. In addition, the introduction of environmental, social, cost, organisational, etc. objectives would further automate the modelling process through optimisation.

While some attempts have been made in the field of building information modelling, also named BIM, [2][3] [4], the quest for a universal knowledge representation language has also been met with scepticism [1] [5]: claiming that immediate practical needs should be prioritised or even that this is not (yet) feasible. It can even be argued that the field has adopted a pragmatic approach by focusing on information (as opposed to knowledge) [6], its translation from one environment to another [7], and constraint verification only after modelling [8]. Our proposed research returns to an idealistic view, but finds it promising if based on revised conceptual foundations and the knowledge-based configuration paradigm.

The rest of the paper is as follows. First, in Section 2, the 'open' nature specific to the building industry is presented. In Section 3, the need to call some basic premises of previous efforts into question is addressed. Section 4 introduces the knowledge configuration paradigm and outlines the work of examining the possible benefits and challenges of its application for building knowledge. Lastly, possible further extension of the research is outlined in Section 5.

Building Industry as an 'Open' Industry

The need for a universal knowledge representation language (or at least a common meta-model) and the research challenges this provides, arise from the fact that the building industry is possibly the most open industry [1]:

• 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). This openness is reenforced at a European level through regulation (Construction Product Regulation [9], public procurement [10]) and standardisation (CEN -European Committee for Standardization). This openness entails that most knowledge is generic and generally available in ample building regulations and standards. 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).

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 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 efforts to be called into question.

Firstly, are existing attempts sufficiently 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 efforts ontological sufficiently sound? Some examples of overlooked building ontology:

• A building concept can play different 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 offered by the product (a window available in different 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 office floors having an adjustable height or a ventilation unit with different flow rates. Therefore, at least conceptually, properties must be thought of as potentially having different 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 different 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) [11]: for example, products exist that act as roof boards and roof insulation or the window grille is simultaneously part of the window and the ventilation system. • Within the partonomy there is also a need for the idea of 'breakdowns': different ways of breaking down a concept into parts. These ways can be disjunct (variants): for example, the choices for the building structure might be frame-like (e.g. wood or steel) or mass-like (e.g. prefab concrete or masonry). Breakdowns can also be conjunct (within a single variant): a building can be subdivided into its structure and total air volume or into floors (with each floor incorporating part of the structure and air volume). Each breakdown (and its parts) can be needed for the representation of knowledge or user requirements.

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 effectively 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.

Work Part 2: Applying Knowledge-based Configuration

The knowledge-based configuration paradigm defines a configuration model as a set of with their domains and with product and user constraints limiting the possible combinations of variable values, and a solution (a configuration) as an assignment of single values to all variables consistent with the constraints (e.g. a valid configuration), as in Chapter 6 of [12]. Knowledgebased configuration is a matured and successful area of artificial intelligence, used and integrated across many industries for more than 40 years, as presented in Chapter 1 of [12]. The configuration paradigm will feel intuitive and familiar for most building professionals: a (product independent) specification as a solution space; a building as a configuration; design choices as constraints; configurable products like drywall systems, roof systems, insulation systems. An intensional, declarative representation through domains and constraints might therefore prove to be a good fit for construction knowledge 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 first 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 [13], or standard sizes of plywood sheets determine the size of a construction to avoid waste [13]. 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 Right: relationships between generic concept, project specification and products solutions space in a configuration task for a building project part challenges to the paradigm can already be identified.

Can configuration cover the needs resulting from the work of Section 3: the ontology, the domain of discourse and will it be enough to allow domain experts to take on the role of knowledge engineers? A task resembling the work of [14].

Will the configuration paradigm be able to fully absorb the open character discussed in Section 2?

• 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 [12]. 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 (different manufacturers) but also generic knowledge (building regulations and standards) is generated by different institutions at different 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 different 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 effect be a product independent (demand side) specification. Making it necessary to solve the product knowledge base first.

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 efficient 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 interface 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.