A Formalization Framework for Integrating Social Design Intentions into Digital Building Models

Abstract

Human-centered qualities (e.g., privacy, sense of orientation, etc.) significantly impact the social sustainability of buildings and the well-being of their occupants. However, due to their subjective nature, such qualities are often implicit and are not documented properly during the planning phase of construction projects. While several types of design intentions are documented throughout the lifecycle of building projects, intentions that are socially oriented and target soft aspects that reflect occupants’ experience (e.g., comfort, well-being, etc.), are evidently missing from current digital building models, hence risking constructing uninhabitable or socially unsustainable buildings. Through an extensive interdisciplinary collaboration between building scientists, practicing architects, and computer scientists, this paper addresses this gap by introducing a formalization framework, “ProFormalize”, to capture social design intentions (SDIs) in digital building models. This work presents a novel approach to digitalize SDIs in buildings, bridging a critical gap between architectural design intentions and explicit digital representations. Following a case-study-driven approach and a co-creation-based methodology, we developed the framework aiming to establish the foundations for developing a decision-support software tool (plugin) that enables architects, who are directly involved in the research process, to integrate SDIs into digital building models. The expert feedback demonstrates that the framework can make implicit SDIs explicit, which enables architects to integrate them into digital building models. Expert feedback suggested that a software tool developed based on this framework can enhance decision-making due to the traceability and analyzability of digital models.

1. Introduction

1.1. Background

The term “design intention” or “design intent” refers to the intended functional and aesthetic purpose of a building and is well-established and understood within the field of architecture and architectural research [1]. Architects are required to engage in several fundamental inquiries during the early design stages: Who is the target user of the building? What is the rationale behind its construction? What specific functions or activities will the building facilitate upon its completion? These questions are critical for establishing a coherent framework, i.e., a logical flow [2] that guides architectural design and ensures alignment with user needs and project objectives.

Certain design intents foster social intentions related to how occupants interact with one another, with the building, or how they feel and experience the building. In a previous study [3], we rigorously delineated the concept of social design intention (SDI), which encompasses elements that directly affect the experience and behavior of building occupants (e.g., eliciting curiosity, promoting comfort, etc.). Some of these intentions exist in the project specification as requirements (e.g., social, technical, economic, environmental, etc.). The social intent can be tied to the social requirements, reflecting the expectations of the building owner or developer regarding the social impact of the building. The intentions might also be introduced by other project stakeholders, who describe their intentions or wishes for how the building should impact its users. The social intents are primarily focused on promoting social aspects such as creativity, security, safety, etc. (for the complete list of social aspects, refer to [3]), which can be done through aesthetic, functional, or design-oriented choices [4].

Since those requirements come from different individual-but-interconnected specializations, they often overlap or contradict each other. For example, while larger windows allow for better daylight access in the built environment, they also risk overheating the interior space, which affects occupants’ thermal comfort, economic costs, and the building’s environmental footprint. Therefore, requirements, as a major component in the design and planning process of buildings, must be communicated efficiently for a successful building project [5]. The framework presented in this paper addresses this point by introducing a formal and explicit representation mechanism that allows stakeholders to effectively document and communicate their design intentions in the digital building model. This approach will also allow architects and other stakeholders to share their design decisions and choices along with their corresponding levels of recommendation, prioritization, and significance based on context, building type, and occupant category. Thus, the framework helps to identify conflicts early in the design process and enables focused and meaningful negotiations to resolve such disputes. The subsequent requirements exemplify social intentions within the built environment [5]:

“People should have access to sunlit space which is visually private”.

(comfort [6], privacy [7]).

“People should not be able to see directly into any other dwelling”.

(privacy [8]).

“People should feel that their dwelling is not forcing them into loneliness”.

(well-being [9,10]).

“People should feel that their dwelling is uniquely identifiable as their own”.

(belonging [11]).

1.2. Problem Statement

During the design phase of a building, the experience of social values by building occupants is introduced into the building design by stakeholders with different backgrounds and perspectives [4,12]. These social intentions relate to the occupants’ experience and how they interact with each other or with the building, which are fostered by certain design decisions, ranging from installing furniture to more extensive decisions involving walls, windows, beams, stairways, lighting, etc. They are critical for the effective functioning of a building that promotes the health and well-being of its occupants [13,14].

Major design decisions that aim to elicit particular social values are typically incorporated into the project at an early design stage (such as occupant flows and exterior vantage points for orientation) or in future rounds of renovations. However, because they are not formally documented and explicitly captured in the building design itself (i.e., on the same ontological level as walls, doors, etc.), they are often lost when stakeholders and stakeholder responsibilities change during the design process [12,15].

As a real case study that has been conducted in this work, consider the following renovating design decision made to improve the library building at Aarhus University:

“The quiet reading area is positioned far from, and oriented to face away from, both the main entrance stairway and the exterior view to the busy street outside”.

In the original design, the reading area was positioned nearby and facing the main entrance stairway and was found not to facilitate the intended activity appropriately; thus, this was one among several design modifications. Deconstructing this design decision, we define the following concepts and terms: the goal social intention is to create a quiet area both audially and visually. The decisions about the arrangement of building products (to achieve the goal social intention) are the placement and orientation of chairs and lighting that make up the area intended for reading.

What is not described explicitly in the above quote is the sensory experience of occupants that links the products with the goal [16,17]: The main stairway must not be visible from the reading area, and the sound generated by people moving up and down the stairs should not be experienced at a distracting level by an occupant in the reading area.

1.3. Research Challenges, Questions, and Contributions

This degree of rigor in representing such social design intentions is important for their documentation and the capacity to reason about them. However, this formal description is completely absent from the digital representation of buildings, i.e., Building Information Modeling (BIM) models. We formulate this challenge as the first research question:

RQ1: How can SDIs be integrated into digital building models in a way that allows for the automatic detection of structural violations (i.e., problems with the logical form of the intention) and semantic violations (i.e., problems when assessing the intention according to a given interpretation of qualitative terms) in the model?

The second challenge is the subjective nature of social intentions (e.g., sense of belonging, comfort, etc.), which varies across application scenarios and personal preferences. We formulate this challenge as the second research question:

RQ2: How can architects capture SDIs unambiguously, given their subjective and human-centered nature?

In this paper, we introduce “ProFormalize”, a formalization framework for representing and reasoning about SDIs. The ProFormalize framework is being developed as part of the large, highly interdisciplinary H2020 research project PROBONO (47 partners, 14 countries), bringing together expertise from building science, architecture practice, and computer science, and is being applied in numerous cases based in Denmark, Ireland, and Canada. This framework initiates the development of a decision-support software tool to help architects digitalize SDIs during the project’s planning phase and integrate them into digital building models. In this study, we engaged in multiple co-creation sessions with a diverse group of stakeholders.

This paper presents an intensive in-depth analysis of selected case studies that were conducted around the Aarhus University Campus. The originality of our work stems from the added value of the proposed framework, which is to provide a structured way to formalize and digitalize subjective, qualitative, and human-centered SDIs, facilitating communication between stakeholders of building projects and allowing advanced analysis of valuable statistics. This originality is summarized in two contributions:

C1: Developing the “product–goal causality model” to formalize and represent SDIs.

C2: Conducting multiple case studies within a co-creation approach to test the framework’s applicability on actual buildings where design decisions have been applied to target social criteria.

The structure of this paper is presented in Figure 1. We start by defining the theoretical background of ProFormalize based on causal logic and our formalization model. We then present details on how the selected in-depth case studies enabled us to develop the framework based on real-case SDIs. The outcomes of selected case studies are then summarized and discussed, providing insights into the applicability of the framework within architectural design processes.

2. Related Work

Building design projects encompass both qualitative and quantitative values/criteria/metrics, commonly categorized as “soft” and “hard” values [18,19]. Hard values are characterized by an epistemological framework that presumes the existence of an objective reality capable of precise description and measurement. In contrast, soft values indicate the limitations of such objectivity [12]. Various sub-disciplines within building design focus on quantifiable aspects, such as environmental life cycle assessment (LCA), energy consumption, total costs, and indoor environmental conditions, while others explore qualitative dimensions associated with social and cultural significance, such as user experience, well-being, and health in the built environment [20].

Capturing information in buildings, including design intentions, through the development of decision-support systems has been investigated by researchers and architects [21]. This information may include geometric/non-geometric aspects, building codes, and other design intentions [22]. The authors in [23] introduce the “DesignTracking” system to document design actions (e.g., moving, drawing, deleting, etc.) using BIM-based software and then visualize the sequence to track errors and review the design. In our framework, our aim is to document design decisions (e.g., installing a window, arranging furniture, etc.) as well as to explain and reason about the causal logic behind such decisions by explicitly modeling the causal relationship between building elements and the social intentions they elicit. While tools such as DesignTracking are focused on capturing procedural details in a BIM environment (i.e., sequence of actions done), they often lack the rationale behind such actions; hence, our tool, based on the developed formalization model, captures this logic, resulting in a semantically richer building model.

A review of decision-support tools for sustainability criteria (i.e., economic, environmental, and social) satisfaction in the building renovation phase found that 63% of the reviewed tools include social criteria [24]. The researchers who performed this review define the “goal-setting” area, where a specific objective is defined by the stakeholder(s) regarding the selected sustainability criteria, the definition of a sub-criterion, and the design decisions implemented to affect the mentioned criteria. In the scope of our work, stakeholders mainly include architects, but they may also include designers and facility managers. The selected sustainability criterion, to which our work contributes, is social sustainability, and the sub-criteria include socially oriented aspects such as privacy, social interaction, sense of curiosity, etc. Lastly, the design decisions that target such criteria include furniture placement, choice of material, colors, lighting, etc.

BIM, as a digital representation of both the building’s physical and functional characteristics, represents a shared and reliable source of information during the lifecycle of the building, starting from early design phases to construction, operation, and demolition [25] .

For example, documentation of design decisions has been addressed through the development of a BIM-based system to capture implicit links between design rationale and geometric configurations [26]. The researchers also provide proof of concept demonstrating the implementation of a Revit-based plugin through which the user can select building elements, display their properties, and add spatial constraints, among other aspects. This approach aligns with our focus on integrating design intention-based data into the digital building model. However, our focus is on formalizing causal relationships between physical building elements and social intentions, whereas the researchers’ focus is on capturing multidisciplinary tacit expert design knowledge, some of which might be social, such as accessibility and social integration.

The nature of BIM information involving objects, relationships, and properties allows for exploiting ontology-based modeling to create a shared set of vocabulary to represent, document, and integrate these concepts in an understandable way [25], with the help of Industry Foundation Classes (IFC).

Jia et al. [27] introduced a review of the efforts in integrating IFC and ontologies to enhance data exchange and interoperability. The authors define three modes of IFC ontology integration, which are summarized as follows: Mode 1: using ontologies for knowledge representation without changing the IFC standard. Mode 2: using ontologies to embed domain information into the IFC standard to generate semantically rich IFC models. Mode 3: using ontologies to link IFC models with other data to facilitate interoperability between BIM and other platforms.

Our work is closely related to Mode 2. We aim to extend IFC with classes that specifically represent social intentions and enable reasoning about them, resulting in a new IFC file that is semantically enriched with socially oriented design aspects that directly influence occupants’ experience in the building. Furthermore, as demonstrated in our proof-of-concept tool (presented in Section 5.3), this enables 3D visualization of the created SDIs, as well as new ways of querying an IFC file concerning social intentions for further SDI analysis.

Current efforts in BIM-based ontology development and IFC extensions target applications in the fields of energy performance [28]. Building Topology Ontology (BOT) [29,30] provides a specification of topology-relevant concepts that is intended to be further specialized for particular domains, such as OntoBIM [31,32] which provides a specialization built on BOT, originally intended to facilitate energy-efficient building design as part of the EU FP7 project “Intelligent Services for Energy-Efficient Design and Life Cycle Simulation (ISES)” [33,34]. Other applications include semantic web for data transformation [35], the generation of parametric models within the context of heritage preservation [36], facility management and diagnostics [37], and sustainable building materials [38], among others. Our work aims to address the research gap relating to the inclusion of qualitative and soft design aspects that influence the experience and subjective impression of building occupants at a broader, more general level, including accessibility, awareness, privacy, comfort, well-being, facilitating social interaction, a sense of belonging, a sense of heritage, and so on.

The interconnection between architectural design and social aspects concerning building occupants and their interaction with buildings and with each other has been thoroughly investigated in fields like spatial cognition, human-centered design, psychology, and architecture, among others. A well-established concept is that the built environment not only provides the service or function of accommodating occupants, but it also highly affects how humans experience their surroundings, act, and feel in the building [39]. Social aspects (e.g., privacy, belonging, etc.) are somehow embedded within design decisions. However, current tools cannot digitally capture and document such aspects in digital building models, which would thereby allow for such information to be traceable, queryable, and analyzable.

Space syntax [40] represents a major effort in studying movement patterns and accessibility. This approach uses various representations of space (e.g., axial maps, convex maps, and visibility graphs) to provide effective quantitative and computational methods to analyze spatial configurations and to examine how the arrangement of spaces impacts humans’ experience and perception of space. However, it does not offer a direct way to capture architectural design intentions or social aspects.

Space syntax algorithms and methodologies have been applied to improve and enhance the social dimension of the built environment, targeting aspects such as urban design [41], connectivity, accessibility, pedestrian movement, land use, street networks, housing, and energy conservation [42], and further aspects [43].

For example, researchers have applied space syntax algorithms to analyze the behavior and movement patterns of visitors at tourist sites [44]. The authors applied two algorithms: the 3D isovist analysis (representing visibility fields from a given viewpoint) and the agent-based model (providing a simulation of a virtual walking agent based on preset parameters). Since building occupants’ behavior and experience are highly influenced by what they see, we consider visibility spaces to be one of the main spatial artifacts inside which social intentions, according to our definition, are elicited. Similar to our purpose, researchers have targeted the inclusion and integration of social dimensions in spatial analysis following a space syntax-based approach, due to their direct role in improving occupant comfort levels [45].

Our approach is highly complementary to space syntax tools (i.e., those that apply to indoor environments) and operates at a different level of abstraction. We seek to formally model the design rationale applied by architects in general that traces from building elements, through occupant sensory experience and behavior, to experienced social intents (such as curiosity or privacy). Our focus is on the representation and documentation of social design intentions, and subsequent analysis and reasoning based on this formal representation. Space syntax instead has a focus on understanding building occupants and developing “syntactic measures” (space connectivity, integration, etc.) that can predict specific social values in a building design, such as intelligibility. Thus, space syntax is complementary to our approach as it can be used to justify a given social design intention that is captured and documented using our framework, if a corresponding syntactic measure has been defined. Importantly, our approach also enables the formal documentation of social intents for which no established syntactic measure has been created.

Research in environmental psychology has explored how the physical environment influences human behavior, privacy, and perception of personal space [46], in addition to psychological well-being [47]. However, this approach is not directly integrated with architectural design.

The more recent methods in design computation and generative design [48] provide performance-based modeling, with a focus on material and technical aspects rather than social aspects. In the field of BIM, multiple ontologies and data schemas have been developed to represent building elements and spatial relationships between them in a standardized manner [49]. Such approaches, including IFC, are very efficient in embedding functional data but do not natively capture social intentions as integrated objects in the digital building model. Research in BIM-based plugin development shows a limited focus on targeting social aspects. Researchers have developed plugins for claims management systems [50], energy performance [51], lifecycle assessment [52], sustainable building components selection [53], building material assessment [54], and safety and risk prevention [55].

Our framework seeks to bridge the gap between architectural formalization and computing methods in capturing SDIs. By introducing our “Product–Goal Causality Model”, which is presented in Section 3.2, we provide a domain-specific formalization language that explicitly captures the causal relationship between building elements (product level), spatial conditions, affordances, and occupant sensory configurations (domain level), and the evoked social intention (goal level). This model does not handle intentions as external annotations or expectations, but as causally linked objects within the building model. By making SDIs accessible and modifiable, our framework allows building project stakeholders to assess and communicate human-centered qualities in the built environments.

Our work differs from and complements approaches that introduce metrics and indicators for social values, such as comfort [56], privacy [57], etc. In our work, we do not create any metrics for a particular social value. Instead, we focus on capturing the design intention (for creating a social value) itself, and the logic connecting building elements to the social values. The purpose is to formally document and digitalize these social intentions so they can be checked and maintained in the BIM model as the design evolves. Failures in the logic can be detected (as presented in Section 5.3), warning the design team that the intended social value is undermined, so they can subsequently refer to other existing frameworks to measure and verify those values.

Among the major challenges of interpreting SDIs is the unclear connection between the physical design implementation and the achieved social intention. Researchers have addressed the qualitative nature of social values (e.g., privacy) in previous studies. For example, four determinants were introduced to assess the impact of building renovation on spatial quality [58,59]. As an example of the connection between a design decision and a social value, the authors highlight the impact of balcony placement on social and visual interaction among building occupants. The authors also discuss the effects of windows, doors, and internal wall placement on the occupants’ sense of privacy. Similar examples are also discussed in the case studies that we have conducted and presented in Section 5.

Another case is illustrated through the quality assessment criteria proposed by [60]. Among the defined criteria are privacy, daylight, thermal and acoustic comfort, etc. These criteria align with our definition of social intentions, as they include aspects that are social and directly related to the well-being of building occupants and can be achieved using specific building elements (e.g., windows, light, etc.) in a certain arrangement.

Additionally, researchers have addressed the effect of interior building elements on privacy and comfort, among other aspects [61]. For example, the authors mentioned the installation of lighting, ventilation devices, cabinets, storage areas, blurred glass, etc. Lastly, researchers studied the effect of windows and their size (design decisions) on daylight access and therefore visual comfort (social intention) of building occupants [62].

3. ProFormalize: A New Framework for Identifying and Digitally Representing Social Design Intentions

This section presents the foundation of the ProFormalize framework. The first part shows the connection between the framework and social sustainability. The second and third parts introduce the product–goal causality model and its class hierarchy, respectively. The fourth part presents the logical relationships used to represent SDIs. Lastly, the overall process of capturing social design intentions is demonstrated.

3.1. Social Sustainability and Social Intention

The commonly acknowledged definition of sustainability originates from the Brundtland report [63], where sustainable development is defined as “[…] meeting the needs of the present without compromising the ability of future generations to meet their own needs” [63]. Since its publication, this definition has become interconnected with the perception of sustainability as consisting of three pillars: the environmental, economic, and social sustainability [64], which Barbier first presented in 1987 [65]. The degree to which each pillar is defined, applied, and made operational varies greatly, with the social pillar being the most weakly defined [66,67,68], spanning concepts such as well-being, security, etc.

Existing approaches to social sustainability assess the degree of social sustainability based on system- or framework-defined criteria. They disregard the aspects that are not included in the selected framework, which means the systems and criteria do not assess the overarching social sustainability [3]. The work presented in this paper focuses on the contribution to individual social values, acknowledging that the inclusion of social values in buildings can contribute to the overarching social sustainability of buildings [3].

Social sustainability aspects, such as comfort and well-being, are directly affected by building elements arrangement (e.g., walls, windows, furniture, etc.) and influence occupants’ experience and interaction within the building. This combination of socially-oriented design decisions and social intention varies greatly with context, building types, and occupant categories.

Table 1. Building type vs. social intention matrix, showing the level of importance (i.e., low, intermediate, and high) of a selection of social intentions with respect to a selection of building types.

Building Type/ Social Intention	Residential	Educational	Workplace	Library
Privacy	High	Low	Low	Intermediate
Curiosity	Intermediate	Intermediate	Intermediate	Intermediate
Sense of belonging	High	High	High	Low
Daylight access	High	High	High	High
Comfort	High	High	High	High
Social interaction	Intermediate	Intermediate	Intermediate	Low

presents our estimation of the degree of importance of a selection of social intentions and how this varies across different building functions, expected occupant behaviors, and priorities based on intended occupant experience. The values in the table originate from the expert knowledge that we received from building professionals.

For example, privacy is critical in residential buildings to enable control over personal spaces, whereas in public spaces (e.g., museums, libraries, etc.) privacy is not prioritized as much. Instead, accessibility, curiosity, and wayfinding are prioritized to encourage and facilitate mobility and exploration.

Comfort, as another example, is a social intention that has high relevance and prioritization in all building types, comprising aspects such as thermal comfort, acoustic comfort, and visual comfort. However, other social intentions, such as the sense of belonging or social interaction, are highly context-dependent and are directly related to occupants’ experience and behavior. This mapping of social intentions among different types of buildings allows for a tailored approach towards accurately capturing SDIs based on case-by-case modeling.

3.2. The Product–Goal Causality Model—Social Design Intention Structure

The foundation of formalizing SDIs in our framework is the product–goal causality model shown in Figure 2 and inspired by the work of Lauesen in software requirements engineering [69]. The author introduced the goal-design scale, consisting of four levels of requirements. The three most relevant levels to our work are the goal level (specifying why a system is required), the domain level (specifying how the requirement is met), and the product level (specifying what the inputs and outputs of the system are).

3.2.1. The Goal Level

This level represents the social intentions to be achieved. It has information about the goal of the design decision, including feelings, emotions, experiences, or behaviors. Examples of predicates in this level include privacy(O), comfort(O), curiosity(O), etc., where O is a building occupant experiencing the social intention. This level represents why a specific design decision is implemented.

3.2.2. The Product Level

This level represents the means to achieve the goal-level intention. It includes building elements such as walls, doors, furniture, etc. Examples of predicates in this level include artwork(A), wall(W), light(L), etc., where A, W, and L denote an artwork, a wall, and a light source, respectively. This level also includes spatial preposition predicates representing the building elements’ direction, orientation, or position. Examples of such predicates include inside(), near(), directedAt(), etc. Hence, this level represents what building elements are used and the way they are arranged.

3.2.3. The Domain Level

Having only two levels (i.e., the product and the goal levels) does not fully represent the inference of a social intention from a design decision. For example, installing a piece of furniture (a product-level element) is insufficient to infer the evoking of a certain feeling (a goal-level element). An additional level should answer questions like where should the building occupants be located to use or see the furniture? How can different levels of visual and movement ability be modeled?

These questions led to the introduction of this third level that forms an intermediate level describing the implicit connection between the goal level and the product level. Hence, it explains how a certain design decision affects a certain social intention. The predicates of the domain level represent building occupants and their senses, and they are divided into three major categories:

• Building occupant predicates: represent occupant profiles as defined by the architect. For example, occupant(), student(), elderly(), etc.
• Spatial artifact predicates: representing regions of space that comprise a semantic value [16,17] about the space from which an object can be seen (i.e., visibleSpace()), heard (i.e., acousticSpace()), or used (i.e., functionalSpace()), etc.
• Spatial relation predicates: represent the relations or positions of spatial artifacts. For example, inside(), intersection(), union(), etc.

3.3. The Class Structure of Social Design Intentions

SDIs are represented as a class structure containing the following four classes, which are illustrated in Figure 3:

• SocialDesignIntentionSet class: this class contains one or more SDIs and has methods to query the set of SDIs.
• SocialDesignIntention class: this class contains all building elements, functions, and relations that create the SDI. Each SDI must have at least three SDIObjects representing one object from each level of the product–goal causality model.
• SDIObject class: this class contains all objects that are not functions or relations, such as building elements, spatial artifacts, occupant specifications, social intentions, etc.
• SDIRelation class: this class contains spatial relations between objects, such as directed at, above, etc. An SDI can have zero or more SDI relations.

3.4. The Causal Logic of Social Design Intentions

The structure of SDIs is defined using the characteristics of “causality”. That is, the existence of a “cause-and-effect” relationship between a design decision as a cause of an evoked social intention. The most relevant types of causal relationships for our work are the common-cause, the common-effect, and the chain causal relationships [70]. We use the concept of “situation calculus” [71], which is a second-order formalism for reasoning about actions and change, to represent our causal model. We derive our predicate structure from the following components of situation calculus [72]:

• Objects: Variables representing objects. For example, a wall denoted W.
• Situation-independent predicates: For example, wall(X) returns true if object X is a wall, independent of any situation.
• Initial database axioms: The initial state of the system. For example, wall(W).

The types of causal relationships representing SDIs are summarized as follows and are illustrated in Figure 4:

• Basic Causal Relationship (BC): represents the simplest causal relationship type. A product-level element A causes a goal-level effect B.
• Default Causal Relationship (DC): inspired by “Default Logic” [73], representing requirements. Product-level element(s) A, B, and C cause a goal-level effect D. Removing any of them breaks the argument.
• Common-Cause Causal Relationship (CC): representing an effective product-level element A causing multiple goal-level effects B and C.
• Common-Effect Causal Relationship (CE): representing multiple product-level elements A, B, and C, where each shares a contribution to a goal-level effect D. Removing any of them will not break the argument.
• Chain Causal Relationship (CH): representing intermediate steps. A product-level element A creates a goal-level effect B that causes C.
• Preserving Causal Relationship (PC): representing preserving an originally achieved goal-level effect C. Implementing a product-level element A causes an additional goal-level effect B without risking the original effect C.

Causal relationships in SDIs can be categorized into one of the six causal relationship types based on the following rules:

• The number of building elements involved in the SDI: if more than one building element is involved in the SDI, the causal relationship in this SDI is categorized as a common-effect relationship (i.e., multiple causes for a common effect).
• The number of social intentions in the SDI: if more than one social intention is targeted in the SDI, the causal relationship in this SDI is categorized as a common-cause relationship (i.e., one cause for multiple effects).
• The number of goal-level causal inferences described in the SDI: if the SDI explicitly specifies that there is more than one causal inference from the building element to the social intentions, that is, if the relationship takes the form that a building element X creates a social effect Y, which creates another social effect Z, the causal relationship in this SDI is categorized as a chain relationship.
• The existence of an original social intention: if the SDI explicitly specifies an already existing social effect that must be preserved while introducing a new building element to elicit an additional social intention, then the causal relationship in this SDI is categorized as a preserving relationship.
• The existence of a requirement: if the SDI explicitly specifies that a certain building element represents a “requirement” to achieve a certain social effect, and without it, the social intention is not attained, the causal relationship in this SDI is categorized as a default relationship.
• Any other shape of causal relationship between building elements and social intentions in the SDI is considered a basic relationship.

3.5. A New Four-Stage Process for Capturing Social Design Intentions

In ProFormalize, we developed a four-stage process for capturing SDIs, as shown in Figure 5. These stages are Elicitation, Organization, Formalization, and Implementation.

• Elicitation: in this stage, social intentions and design decisions are captured through semi-structured interviews with the architects who implemented them. The outcome of this stage is the transcribed interviews forming the basis for the following stages in the workflow.
• Organization: in this stage, the SDIs are identified in the transcript and are organized into a database consisting of a table of design decisions and their corresponding social intentions with timestamps referring to the interview recording to ensure transparency.
• Formalization: in this stage, SDIs are represented using the product–goal causality model. The product-level predicates take parameters representing building elements. The domain-level predicates take parameters representing occupants and spatial artifacts, while the goal-level predicate parameters represent social intentions.
• Implementation: in this stage, formalized SDIs are implemented in software, i.e., as instances of the class structure presented in Section 3.3. The outcomes of this stage were utilized as a proof of concept and prototype tool implemented in the Python programming language (Python version 3), resulting in the development of the ProFormalize Analyzer and ProFormalize Logical Validity Checker, allowing us to create several query services that can be applied to an SDI set, as explained in detail in Section 5.3, and in the code snippets in Appendix B.

The ProFormalize framework can also be used to identify the malfunctioning structure of the created SDIs. Hence, the following rules have been defined to detect such logical errors:

• No unmatched GUIDs: all element GUIDs in the SDI must occur in the BIM model.
• No dangling building elements: all building elements in the SDI must causally infer a social intention.
• No empty product levels: all SDIs must have at least one product-level element, from which a social intention is inferred.
• No causality cycles: all causal chains from a reference identifier to a social intention must terminate in a finite number of steps.
• No duplicated identifiers: all reference identifiers must be unique.
• Correct arity and types: all functions and relations must be used with the correct number of input parameters and input type.

4. Materials and Methods

ProFormalize is being developed gradually and iteratively through rounds of consultation with architects and academics in architecture and civil engineering, through numerous diverse building project case studies in different countries (Denmark, Ireland, Canada). This case study-based approach is an integral part of broader co-creation-based research which involves multiple rounds of activities (e.g., semi-structured interviews, focus groups, etc.). While multiple rounds of co-creation activities have already been conducted (i.e., five conducted out of seven planned), intensive and in-depth case studies are selected in this paper. Inspired by “Purposeful Sampling”, where “information-rich cases are selected to illuminate the questions of the study” [74], these case studies were selected due to their relevance to the Danish context as they represent use cases within the Living Lab of Aarhus University, a partner of the broader 47-member consortium within the framework of the PROBONO Project. This careful selection provided deeper qualitative perspectives, allowing for highly intensive analysis, which would have been difficult to accomplish with a broader group of data.

Figure 6 illustrates a Business Process Model Notation (BPMN) diagram of the events and decisions of the ProFormalize process. The overall process starts when the “stakeholder engagement” engineers send an invitation to conduct semi-structured interviews with the potential architects. The interviews are conducted either as on-site interviews, sit-down face-to-face interviews, or as online interviews. The type of interview depends on the availability of the interviewee and the accessibility of the building. On-site interviews have been preferred, but due to limited building access or geographical distances, the possibility of conducting this type of interview has been limited. Online interviews have only been conducted as a last resort when scheduling conflicts and large geographical distances have made the face-to-face interview impossible to conduct, including cases where the interviewee and the interviewer have been in different countries.

During the interview, instances of design decisions and their corresponding social intentions are collected. In our framework, we conduct narrative interviews [75] to encourage the interviewee to narrate the existing practices. This approach minimizes the risk of eliciting what the interviewee would ideally do instead of what has actually been done during the work process [75,76], as reiterated by [77].

Our approach is based on the structure presented by [78], where the interview passes through the five stages: introduction, warm-up, main body, cool-off, and closure. The introduction and closure stages contain a briefing and a debriefing [75] regarding the content of the interview, to ensure that the interviewee is informed about the subject of the interview and which/how data will be utilized.

The warm-up and cool-down stages are utilized to frame the main part of the interview. Through these stages, the interviewer gradually leads the interviewee into the thematic space of the interview and back to the interviewee’s everyday life. The main body of the interview focuses on collecting examples of social intentions and design decisions included in existing building projects in which the interviewee is involved.

In preparation for the interview, the interviewer has prepared an interview guide consisting of standardized questions to guide the direction of the interview (see Appendix A for the interview guide). The nature of the interview being conducted as a semi-structured interview means that the interview does not follow questions in a set order. The interview is instead focused on the theme of social intents and how they impact the building design, and the questions prepared in the interview protocol are utilized to guide the direction of the interview if the theme of the interview drifts away from the interview subject. The main body of the interview guides the interviewee based on descriptive and elaborative questions, aiming to encourage the interviewee to talk about different projects and elaborate on them, including how social intents have shaped the building design and if the intents have been realized.

The interviewer transcribes the recording of the interview for further editing and proofreading to ensure it reflects the recording. The interviewer analyzes the transcribed interview by performing a narrative analysis [79,80], through which the interviewer identifies social intentions and design decisions when the interviewee presents a narrative that connects the intention to the decision. The identified intents, design decisions, interview timestamps, and direct interview quotes are organized into a database. To mitigate interviewer bias, the interview and coding are checked by a researcher who was not participating in the interview.

After the interviewee’s approval, the list is sent to the “formalization” engineers, who formalize the organized list based on the product–goal causality model, which is explained in Section 3.2. The formalization aims to limit the ambiguity and to represent the SDIs in FOL formulas.

After the formalization stage, a sample of the formalized design intentions is presented to the architect for validation, to align with the architect in the way the recorded design decisions and social intentions are presented in terms of correctness, level of ambiguity, and completeness, and proceed with further refinement of the process. The last step is to represent the SDIs in a machine-readable format for further processing.

5. Case Studies

This section presents the overall case-study approach through a selection of case studies that we conducted to test the framework’s applicability to actual implemented SDIs.

Table 2. The case studies that were conducted, their locations, the number of captured SDIs, and the current progress in capturing SDIs (with respect to the ProFormalize four-stage process).

City, Country	Case Studies (Buildings)	Collected SDIs	Current Progress
Aarhus, Denmark	9	80	Stages 1–3: Completed Stage 4: In progress
Dublin, Ireland	2	9	Stages 1–4: Completed
Canada	8	>20 (final number to be determined, analysis ongoing)	Stage 1: Completed Stages 2–4: In progress
Total	19	>109

summarizes all conducted case studies, representing a total of 19 case studies (buildings) located in three different countries. In this section, four selected SDIs (all in Aarhus, Denmark) representing four different intensive, information-rich case studies were carefully chosen to be presented in detail. Firstly, three SDIs demonstrate the elicitation, organization, and formalization stages of ProFormalize and finally, one SDI is used to demonstrate the software implementation stage. Although the three selected cases are all related to buildings that are part of Aarhus University, the cases still represent significantly different building functions, user groups, and needs, including students, researchers, consultants, and office workers.

5.1. Elicitation and Organization

The three selected cases were captured during a 2-h semi-structured walk-through interview, which was transcribed to approximately 14,000 words. During this interview, we visited seven locations around the Aarhus University Campus and recorded 80 SDIs. The architect who led us in this interview is an expert in building renovation projects in Denmark. The selected SDIs are implemented from the following three building cases:

-

The Aarhus University Human Resources (AU-HR) building is designed to support the functions of a typical office building. The users of the building are the employees of the HR department, and the building, according to the design stakeholder interviewed, has been designed to foster community among the employees, as the renovation of the building was a part of the restructuring of the HR department to a single department instead of four individual HR departments. The building’s primary users are the employees of the HR department, and the building is therefore designed to support this specific user group that will have their daily workday in the building.

-

The Aarhus University Department of Molecular Biology (AU-MolBio) presents an area in the building intended for university students’ use, including group work, lunches, breaks, and a walking path connecting different parts of the building. Due to the nature of this area of the building being focused on university students, the area must both support the changing activity types throughout a week and a year (e.g., lunch breaks, group meetings, preparation before and after lectures and exam preparation), while also being an area that is welcoming/accommodating to new students entering the university each year.

-

The Aarhus University Centre for Educational Development (AU-CED) which is primarily being used as an office building, but due to the nature of the work of the AU-CED the building users range from the employees of the AU-CED (e.g., administrative staff, office workers and researchers), who have their work day in the building, to internal and external collaborators and guests visiting the building for different meetings.

Based on the transcription of the interview, we performed the organization stage, where the SDIs were organized in tables as design decisions and social intentions.

5.2. Formalization

We used 70 product-level predicates (e.g., glassWall, desk, window, etc.), 23 domain-level predicates (e.g., movementSpace, acousticSpace), and 28 goal-level predicates (e.g., comfort, belonging, spaciousness, etc.) to formalize all the 80 collected SDIs. Most of the collected SDIs represented a basic causal relationship.

Table 3. Causal relationship distribution of all the 80 collected SDIs.

Relationship Type	Number of SDIs	Percentage
Basic	68	85%
Common effect	7	8.75%
Common cause	2	2.5%
Preserving	2	2.5%
Chain	1	1.25%
Default	0	0%
Total	80	100%

summarizes the distribution of relationship types.

The number of predicates used in the formalization of the 80 SDIs is indicative, that is, it is possible that this number could change if the SDIs have been formalized in a different way or by other stakeholders. For this purpose, and in the presented formalization of the 80 SDIs, we tried to be as inclusive and generic as possible so that design teams can use the already-defined predicates when they formalize their own SDIs. Our long-term aim with ProFormalize is to enable users to define their own fully customized predicates that most accurately describe their social intentions in all three levels. Indeed, at present, any custom predicate terms can be used in an SDI with full structural verification support, including identifying the causal relationship type (as defined in Section 3.4) and checking for the six structural errors (defined in Section 3.5). This is currently supported by our ProSpect software tool [81] that provides a user interface in Autodesk Revit for defining SDIs directly in the context of a BIM model. Enabling users to easily provide the geometric definition of their own custom predicates is still a work in progress. In our prototype implementations, we build on top of Blender, IfcOpenShell, and the shapely Python package for processing geometric data.

The formalization of the three selected SDIs (i.e., SDI1, SDI3, and SDI5) was as follows:

SDI1 AU-HR: A large sofa is installed in front of the glass wall of the office, providing shelter and a sitting spot. The department head office has privacy, but is still open and accessible, and not hidden.

This case exemplifies a preserving causal relationship. The intention is to preserve the privacy of the office while being accessible. The sofa (S) is in front of the glass wall (GW) of the head office (HO). There are two slabs, the entrance (Sl1) and the one on which the sofa is placed (Sl2). There are three occupant profiles: a sofa user (O), a head office user (H), and a movement space user (M). The region of the movement space that is not inside the visible space of the working space of the head office (i.e., the difference between funcM and funcV2) is the area where privacy is elicited. Figure 7 and Figure 8 show this case.

SDI3 AU-MolBio: The hallway is visually divided by installing artwork on the wall. Walking through the hallway should be an experience.

This case exemplifies a basic causal relationship: a cause (artwork) and effect (experience) relationship. There is a slab (Sl) representing the hallway, a wall (W) installed on that slab, and an artwork (A) installed on the wall (W). The intersection of the slab’s movement space and the artwork’s visible space is the region where the sense of curiosity is evoked. Figure 9 and Figure 10 show this case.

SDI5 AU-CED: Sofas and tables, which can be used as a workplace for small meetings, online meetings, and lunch, are installed. Make the building users want to come and work from the office instead of working from home.

This case exemplifies a common-effect causal relationship. Multiple causes, i.e., a sofa (S) and a table (T), are on a slab (Sl). The intersection between the functional space of the table and that of the sofa creates a common effect. Figure 11 and Figure 12 show this case.

5.3. Implementation

The detailed implementation of the fourth selected SDI is presented in this section. We developed a prototype software analysis tool written in Python that uses the Industry Foundation Classes (IFC) extension for Blender. This enabled direct interaction with a 3D view of the IFC model, allowing query answers to be visualized in the 3D model by highlighting or hiding particular building elements. The selected SDI was captured in the library building of Aarhus University. This SDI is described as follows: “installing a bright spotlight directed at the wall will elicit a sense of curiosity among building occupants moving in the movement space of the targeted area”. Figure 13 shows the instance diagram of this case.

In this case, w, l, and s are instances of classes Wall, LightFixture, and Slab, respectively, which are subclasses of the BuildingElement class. DirectedAt is an instance of SDIRelation class, and holds between w and l. The light fixture creates a light beam lb, which creates a visible space v with respect to the occupant o, whereas the slab s creates a movement space m. The intersection relation is applied to v and m, eliciting Curiosity c.

This information is stored in a text file, as shown in Figure 14. The token “SOCIAL DESIGN INTENTION” denotes the beginning of a new SocialDesignIntention class instance. The token ELEMENT denotes an SDIElement class instance, describing a building element, an occupant profile, a spatial artifact, or a social intention space (i.e., a spatial artifact with a particular social intention elicited inside it). In each element line, the second token is a unique reference, followed by the level (from the product–goal causality model), the type, and a list of related elements, GUIDs, etc. The token RELATION represents an SDIRelation class instance, describing the spatial relations between building elements. In the library case, there are nine SDI elements and one SDI relation.

The query services that we developed as part of the ProFormalize Logical validity checker include the following:

• Query service 1: Using the “findIntention(x)” method, where x is a building element’s GUID, the user can find all the instances of SDIs where this building element has been involved.
• Query service 2: Using the “findElement(x)” method, where x is a social intention, the user can find all the building elements involved in the given intention.
• Query service 3: Using the “findCausalChain(x)” method, where x is a building element’s GUID, the user can display the steps from the product level to the domain level and, finally, the goal level.

Other services include printing out a certain SDI or a complete set of SDIs, adding elements and relations to SDIs, renaming, and exporting SDIs as a text file.

Figure 15 shows an ill-formed SDI file with three errors that demonstrate the error detection features of the validity checker. The SDI file contains a typo in the slab’s GUID, which is detected through the “findElement” or “findIntention” query services. In addition, the wall “W” that has been defined in the product level has never been used in the domain level, resulting in a “dangling building element” error detected through the “findIntention” query service. Finally, an erroneous causal cycle exists due to element “LB” being caused by element “I”, while element “I” is caused by element “V”, which in turn is caused by element “LB”. That is, element “LB” both is caused by and causes element “I”. This is detected through the “findCausalChain” query service.

Figure 16 shows an implementation example of the two SDI files shown in Figure 14 (the correct SDI file) and Figure 15 (the ill-formed SDI file). Running the first SDI file does not reveal any logical errors, while running the second SDI file shows the detection of three logical errors through our query services.

5.4. Validation Results of Case Study SDIs

After the last stage of the selected case studies, we validated the organization and formalization of the collected SDIs through an interview with the same architect. During the interview, we presented a selection of the formalized SDIs, and we asked the architect to comment on three parameters: clarity, accuracy, and the level of capturing of the social intention. The main properties that we used to evaluate the satisfaction of the mentioned parameters include correctness, ambiguity, and completeness.

Based on the results of the case studies, the architect’s feedback regarding the product–goal causality model was that the current level of detail is basic and understandable, although it lacks a connection with a specific context. This requires introducing new predicates in the product and the goal levels to include more context-specific attributes regarding properties of building elements, building occupants, and their relations, in addition to new diverse goal-level predicates. The architect also suggested that potential software implementing this framework would help architects recognize the importance of satisfying baseline needs before starting to invest in additional higher-level qualities.

The architect emphasized the concept of “several layers of goals”, especially when several building elements contribute to achieving a goal, relating to our definition of a common-effect causal relationship. The architect also argued that sometimes the goal is to make the building occupants aware of the availability of a certain social value; therefore, they can expand its applicability somewhere else, relating to our definition of a chain causal relationship.

In addition, the architect elaborated on using a specific quality in a certain space and extending it to neighboring spaces, without compromising the quality in the original space, relating to our definition of preserving causal relationships. Moreover, the architect elaborated on having a clearer connection between the product-level elements that create a visible space and the occupants’ visual abilities. For example, considering occupants with varying eyesight levels, heights, etc. Hence, we introduced new predicates in the domain level (e.g., elderly(), wheelchair(), etc.).

After the case studies, and after carefully analyzing the outcomes and the expert feedback we collected, we decided to develop a software tool for specifying SDIs. That is, a plugin integrated into Autodesk Revit, serving two purposes: to enable architects to include their SDIs into the digital representation of buildings, and to visualize these SDIs and make them more accessible and modifiable.

We have developed a seven-round co-creation plan [81], involving potential users of the tool (e.g., academics, architects, students) in the research and development process by introducing digital prototypes of the tool and having rounds of input and feedback from them [82,83,84]. The first “wizard-based” version has been completed and evaluated by professional architects and architecture students with promising preliminary results. In the first two rounds of the co-creation plan, we introduced the tool to the participants, explored the software tools they use, and identified their expectations and preferences. In addition, we discussed their current practices and how they integrate social aspects into digital building models. In the third, fourth, and fifth rounds, semi-structured interviews were conducted with architects and professionals discussing the framework outcomes and demonstrating prototypes of the software tool. The outcomes of these activities will be analyzed and integrated into the overarching framework development process.

6. Discussion

6.1. Aligning ProFormalize with Architectural Design Processes

The overall design process of a building or a space can be described as a “logical flow of information” [2]. At the beginning of the design process, the architect is provided with inputs to be fed into the design (e.g., opinions, building codes, performance baselines, etc.). In the work presented in this paper, we add to this input the designer’s or architect’s own “design intentions”, particularly those of a social nature and direct influence on occupants’ experience and interaction with the building. The next step is to encode this input and interpret it to align with the scope of the design.

The ProFormalize framework provides architects with a structured format to represent their SDIs in a formalized way based on the product–goal causality model. The architects then store the inputs (mentally or in documents) to perform their processes and make decisions. The next step is to decode the architects’ information to communicate their ideas with other stakeholders. Our framework has established the development of a decision-support software tool (plugin) that will be created to capture architects’ logic and reasoning of SDIs, formalize them in a machine-readable format, and integrate them into digital building models. The output of this flow is the design production itself, represented by drawings, reports, etc. In the workflow of our framework, the output will be a specification of the SDI that is integrated into the building digital model.

Regarding the first research question (RQ1) of the possibility of integrating SDIs into digital building models, the proposed product–goal causality model accurately captured the logic behind the 80 collected real SDIs in a consistent structure.

To position RQ1 along the classic “logical flow of information” described by Best, we argue that within this logical flow there are four main stages in the process of capturing SDIs: intention capture (turn stakeholder objectives into a list of priorities), information analysis (decomposition of each intention into its model components), digitalization (integrating the intention into the digital model using the software tool), and iteration (of the digital model, facilitating communication regarding the defined SDIs).

Regarding the second research question (RQ2) on the informative and inclusive software representation of subjective SDIs, we found that such representation is achievable by involving architects in the development process. First, we conducted several case studies on multiple buildings and collected several SDIs. This case-study-driven approach helped implement the framework in real-world practice, as actual SDIs were formalized based on the product–goal causality model.

Reflecting on RQ2, we observe that Best’s logical flow of information offers flexibility regarding the types of input data. In our study, the input data is socially oriented, characterized by being qualitative and subjective. Additionally, ensuring consistency in representation, such as in the naming and ordering of elements, is crucial for establishing a clear chain of transformations from stakeholders’ natural-language-based descriptions to machine-readable specifications based on our formalization.

While Best’s 1969 framework [2] provides a foundational understanding of the design process, contemporary research has helped refine these concepts to meet the complexities of modern architectural needs. New approaches include, for example, “architecture as a dialogical tool” [85], where researchers explore architecture’s role in social dialogue, with formalization serving as a platform for social interaction. Another example is “architecture as a mirror of social relations” [86], in which the authors examine how architecture acts as a “catalyst” in social change and transformation, and how participatory design contributes to sustainable development. These modern approaches, inspired by longstanding fundamental frameworks, highlight the critical role digital models (as outputs of the design process) can play in integrating SDIs as an inherent part of the process, leading to the development of more human-centered built environments.

In the current stage of this research and the already-conducted co-creation sessions, we have not yet employed quantitative and performance-based metrics in the assessment process of our framework. Instead, we focused on qualitative assessment approaches mainly through expert feedback during semi-structured interviews and focus group activities. In the three rounds completed thus far, we used a Likert Scale to enable participants to assess the degree of accuracy, clarity, completeness, and usefulness of formalizing SDIs using our framework on a scale from 1 to 5, where 1 is assigned to strongly disagree and 5 is assigned to strongly agree. We also used a quantitative measurement tool to assess the text similarity of the original formalization of SDIs (i.e., done by the authors) compared to the LLM-generated formalization text. The degree of similarity was represented in percentages in a study to assess the potential of using LLMs to facilitate capturing SDIs and formalize them according to our framework [87].

In the upcoming rounds of our co-creation plan, we intend to complement our qualitative-focused assessment approach with qualitative metrics, including the following:

• Usability scores (e.g., System Usability Scale SUS);
• Errors during SDI formalization (i.e., the rate of error occurrence when formalizing SDIs);
• Time to formalize an SDI (i.e., the amount of time required to fully represent an SDI based on our formalization framework);
• Number of SDIs detected that are in conflict, where the conflict was only identified after carrying out the formalization, i.e., situations in which at least two distinct design intentions have goals that work against each other.

6.2. The Role of ProFormalize in Modern Decision-Support Software Tools

The increased complexity of requirements and the development of digital design methods require more concrete, explicit, and unambiguous processes of capturing and documenting requirements and design specifications. Currently, architectural drawings (including 2D plans and 3D models) play an important role in generating a visual representation of the final design. Those drawings, described as “the building blocks of technological design” [88], are used by architects and designers to test their ideas (e.g., dimensions, furniture use, etc.) [89], generate and visualize different design scenarios, conceptualize designs, make decisions, demonstrate designs and thought process, and facilitate communication, interaction, and coordination between stakeholders [1].

Recently, there has been a need for context-based applications for specific domains that align with the expectations of the drawing recipient and allow for better documentation, searchability, reusability, traceability, and shareability, and minimize redundancy [1]. Digital drawings are considered a major communication instrument between designers and stakeholders [90]. Thinking of the design process as a communication system consisting of a sender, receiver, a message, and a channel, the software solution that encodes the message (i.e., the design specifications) can be considered as the channel between the sender and the receiver (i.e., the stakeholders) [91].

Conceptually, ProFormalize will enrich current design software tools (e.g., BIM-based Revit) with an additional layer of reasoning. That is, while current design tools focus on the functionality of designs in terms of geometry and material, ProFormalize will help architects represent and reason about the meaning (why) something is designed in a certain way. ProFormalize will enable architects to reason about their SDIs by eliminating ambiguity and explicitly describing the logic behind their decisions. This will be performed consistently with architecture workflows, facilitating modeling of spaces that contain rich semantic values (i.e., spatial artifacts [16]. The software tool that we will develop based on ProFormalize will provide a visual interface to capture SDIs and attach them to specific building elements, providing analytical and statistical data (e.g., the number of SDIs in a certain area, the affected SDIs by modifying certain elements, etc.).

7. Conclusions

This paper presented the ProFormalize framework that, to the best of the authors’ knowledge, is the first of its kind for systematically identifying, formally representing, and reasoning about social design intentions (SDIs). To this end, the project brought together diverse expertise from building science, architecture practice, and computer science, with numerous case studies in Denmark, Ireland, and Canada, collecting over 109 SDIs across 19 buildings.

Theoretical contribution: The major outcome is the underlying three-level data model for representing SDIs: the product–goal causality model. The data model was developed to conceptually distinguish between (a) building products and their arrangements (product level), (b) dynamic phenomena that exist while the building is in operation that are caused by objects in the product level, including the potential for occupant sensory experience and behavior (domain level), and (c) social intents that are caused by domain-level dynamic phenomena such as privacy, sense of heritage, accessibility, and so on (goal level). A key novelty of the data model is that it makes the domain-level explicit in combination with distinct kinds of “chains of causality” tracing from building products through to social intents, thereby enabling much richer documentation and reasoning about social design intentions than is currently possible.

To facilitate the identification and appropriate modeling of SDIs in practice using the product–goal causality model, a four-stage process was established with activities: (1) elicitation (interviewing key stakeholders to identify design decisions and social intents), (2) organization (systematically itemizing interview data into a set of SDIs), (3) formalization (deciding how to resolve ambiguities in the description of SDIs and making all relevant domain-level aspects and causal relationships explicit), and (4) implementation (bringing SDIs into software).

Practical contribution: Subsequently, an in-depth analysis of three SDIs, in three different buildings in Aarhus, Denmark, was presented. The SDIs exemplify different kinds of causal relationships, namely the preserving causal relationship, basic causal relationship, and common-effect causal relationship, with social intents of privacy, comfort, awareness, evocative experience, and affordance (usage), including a prototype SDI analysis software tool using the IFC extension for Blender. Using our tool, users can post queries about a set of SDIs, and the query answers are displayed in both the console and by highlighting or hiding building elements in the BIM model.

This work has been conducted within a broader co-creation plan involving stakeholders in the field of architecture. The analysis of the case studies is still ongoing, and their results are being integrated into the relevant rounds of the overall co-creation plan. The decision to adopt a co-creation approach was mainly based on the fact that this approach allows for real-world reflection through involving stakeholders of building projects (mainly architects) in the research and development process, to ensure that the developed tool matches the expectations of the potential users and avoid the situation where the developed tool is either hard to use, irrelevant to architectural practice, or does not represent their knowledge clearly and concisely. Moreover, the co-creation approach allowed us to avoid interfering with architectural practice. That is, our aim is not to introduce a new way for architects to document design intentions; instead, we develop a tool within the context of research activities that are consistently fed with their feedback, insights, and perspectives. We will eventually provide them with domain-specific language that enables them to represent a new type of data that is subjective, qualitative, and has never been formally and explicitly documented in digital building models before.

7.1. Limitations

Among the limitations of this work was the narrow scope of the collected SDIs. So far, the framework has been tested on SDIs from educational buildings only. That is, building occupants represent educational institutions’ students, academics, and administrative staff. This is also evident in the representation of causal relationships in the collected SDIs, as 85% of the cases represented basic causal relationships. We expect this relationship distribution to be more representative in more diverse environments.

Our approach targets cases in which architects put significant time and effort into the design to deliberately capture social values. Acknowledging that this is not always the case, the framework is not applicable when there are no instances of SDIs during the planning phase of the building. The framework is still applicable during the operation or renovation phases of buildings when digital building models experience updates and modifications. The framework currently does not address how potential contradictions between overlapping SDIs could be resolved (e.g., privacy and visual openness), although it does enable these contradicting intentions to be identified automatically and then captured and formally documented, i.e., the existence of an intersection between two regions, one in which an occupant is intended to experience privacy and the other in which the occupant is intended to experience visual openness.

Among the limitations of our approach is that our framework and software tool are based on BIM and target BIM users. This limits the applicability of our approach to stakeholders who adopt BIM as their main working environment. While the decision to develop a formalization framework that targets BIM standards and aims to extend IFC classes was based on the broad usage of BIM in the AEC industry, this decision has raised the challenge of interoperability with other standards and design approaches, especially in the very early stages of building projects, where, usually, design ideas and preliminary simulations are conducted within different environments.

7.2. Future Work

As part of future work, we will explore possible ways to visualize, communicate, and practically utilize the SDI definition in digital building models. That is, we will explore integrating SDIs natively into open BIM standards, specifically Industry Foundation Classes (IFC). For example, each SDI is modeled as an instance of IfcGroup, and each spatial artifact (e.g., visible spaces) is modeled as an instance of IfcSpatialZone, and all spatial artifacts and products in the social intention are related to the IfcGroup instance via IfcRelAssignsToGroup. Furthermore, the causal relationships between elements in design intention are to be related via IfcRelAssignsToProduct, enabling standard IFC querying tools to be used to query SDIs.

In the remaining two co-creation rounds, we will also investigate possible ways to demonstrate the effectiveness and the added value of our framework through experiments that incorporate quantitative metrics that directly focus on the impact of the design process of the framework. Additionally, we will consider recent developments in Large Language Models (LLMs), Augmented Reality (AR), and Virtual Reality (VR) technologies to document, represent, and reason about SDIs in real-world environments. Early results of a case study that we conducted to test the potential role of LLMs in capturing SDIs indicate that this approach is promising, especially in reducing the number of steps and the amount of interaction with the software interface when creating the SDI [91].