OntoAgency: An agency-based ontology for tracing control, ownership and decision-making in smart buildings

.


Introduction
The rise of digitalization and smart systems is widely seen as an opportunity to address societal and environmental challenges more effectively, while building more user-centred systems.For example, key international initiatives such as the EU Green Deal [1] and the EU Renovation Wave [2] coalesce on the EU Energy Performance Directive of Buildings [3] and EU Energy Efficiency Directive [4] to promote digital/smart technologies amongst facilitators of energy and sustainability transitions.Smart technologies promise optimized energy flows to and from the built environment, improved efficiency in managing building systems (e.g.efficient supply demand, efficient maintenance and fault detection), improved comfort and indoor environmental quality within buildings, as well as numerous other conveniences [5][6][7].Together with initiatives such as the EN ISO 55000 series [8,9] and the EN ISO 19650 series [10][11][12], the shift also involves an increasing servitization of buildings, where different elements of the building and its functionalities are subjected to specialised service contracts.These initiatives and standards also push the building industry, via accreditation bodies [13][14][15][16], towards developing Digital Twins to understand how performance in-use deviates from performance as-planned, introducing new decision-makers in the design process (e.g., sustainability consultants, BIM managers).With these changes come new market opportunities for provisioning new services and promoting new types of social interactions, either at the human-human or at the human-building levels [17,18] as well as new decision-making actors in the design and operation processes (e.g., data service providers, data managers).The use of digital technologies consequently leads to changes in expectations on what buildings are about, what they provide and what they can afford [19][20][21][22].
While the complexities of designing and operating buildings increase as result of these changes [18,[23][24][25], the authors argue that the new interactions and changes in relationships between social and technical systems in buildings are still poorly understood by decision-makers.Professionals involved in the design and operation of buildings 'reflect in action' [26]; they reflect on their decisions while deciding upon them but tend not to trace the consequences of their actions to the different stakeholders involved in a project, particularly end-users.Their 'reflection in action' focuses on experimenting via problem framing, i.e., by developing experiments to check how well the proposed solutions fit what they have identified as the problem to be solved [26,27].To do so, they reason with, and are assisted by digital environments based on several ontologies disconnected from each other, none enabling decisions to be traced or referred to stakeholders owning, controlling and/or deciding upon the design solutions proposed.For example, building designers work with construction ontologies such as BIM [28][29][30][31]; building services engineers tend to work in mixed digital environments which include elements of construction (BIM) as well as elements of building performance (e.g.dedicated software such as EnergyPlus [32]) and sometimes systems operation (Brick Schema [33]).Building control engineers, rarely involved in the building design stages, are now asked to contribute to integrating smart controls systems in building services design and operation (ISO 52120 [34]) and potentially share ontologies with building services engineers (Brick Schema [33]), working in disconnection from building designers.
Design and operation responses always come with constraints, persuasion, affordances, and opportunities to the different stakeholders involved in a project [35].Many of these responses have clear implications in ownership, control, and data sharing while they shape and are shaped by power relationships among the different stakeholders involved in building design and operation.Professionals now work in a fragmented industry and need to deliver smart and efficient buildings without having the means to assess if what they are delivering is fulfilling wider sustainability and ethics agendas.They are also unable to protect themselves from the liabilities involved in not fulfilling these agendas 1 as there are no tools for relating building design and operation decisions to the consequences they have for those occupying, owning, investing in, and managing buildings.
This paper aims to address this gap by providing a relational agencybased ontology to enable practitioners and decision-makers to map project design and operation requirements, their corresponding design responses as well as the stakeholders deciding upon requirements and responses when smart systems are to be implemented.It also maps who owns and controls design responses to assess alignment of interests, goals and the fulfilment of design requirements.The ontology builds on ontologies deployed in practice and is non-judgemental, that is, it does not classify what is ethical or unethical.It rather allows practitioners to understand from the products and services they are assigned to deliver, who owns each part of a building and/or its systems, who controls them and who decides upon these products and services on behalf of themselves and/or on behalf of other stakeholders.
To address this aim, the paper first provides an overview of existing ontologies used in smart building design and operation with regards to their purpose and current use in practice, highlighting gaps in knowledge.It then explains the methodology used to develop the proposed ontology.This is followed by a full description of the ontology -Onto-Agency -its functionalities and applications concluding on its diversity of use and highlighting avenues for future work.

Problem definition
Engineering-and design-related building control and information ontologies deal with physical assets, functionalities, and relationships between them without considering who owns, controls, and decides about these different functionalities and assets.They are detached from any social context and, therefore, cannot be used to assess the consequences of design and operation in stakeholders' agency, with consequences ranging from designs not working through to social and economic injustice.
Besides, studies coming from Social Sciences do not offer concrete information for technicians to systemically understand the consequences of their actions [36], let alone to assess the implications of their actions in market uptakes.No models to trace the complexities behind control, ownership and decision-making in smart buildings exist that would be compatible with engineering control and/or other types of building information models.This results in technical people, regulators and policy makers not having comprehensive and systemic views on the consequence and actual process of implementing smart technologies in the built environment.
This section provides evidence to this argument.It shows an overview of ontologies commonly used by professionals (building designers, building services engineers, control engineers and building physicist) in practice and the most cited ontologies found in the academic literature related to these knowledge domains.Ontologies were selected through a Scopus search, specifically addressing 'smart building ontologies' in the subject area of engineering.From the selected papers, particular attention was given to ontologies which are currently used in main ISO and EU standards, as well as ontologies currently promoted by main EU and International Energy Agency (IEA) Annex initiatives.The reason is these are the ontologies currently used in practice and/or to be adopted by practitioners based on forthcoming regulatory instruments.Ontologies found were categorised based on their use within the building design process, following international building design Plans of Works described in Ref. [37].Use within the design process was assessed based on a combination of domain knowledge and primary focus of the ontology (what is the ontology mostly used for), with an overview on types of entities and relationships they describe (Table 1).Ontologies related to smart cities, smart grids, smart infrastructure, cybersecurity, and manufacturing were excluded to keep the focus on buildings.

Existing ontologies and their detachment from the social context
Requirements-oriented ontologies are normally developed to aid design decision-making and are broad in scope.Mainly these ontologies refer to product design rather than building design and focus on describing abstract entities related to customer needs [38], converting customer needs to design requirements [39], decomposing functional requirements [40] and connecting requirements with product design parameters [41].Specific building design ontologies like DogOnt ontology [42] supports domotics focusing on connecting services functionalities with service delivery.They map network components, services location, service functionality, service delivery state and device features (controllable of uncontrollable).Ideally, they would be useful to inform pre-design stages when briefs are being developed and requirements are being elicited.However, like the ontology proposed in Ref. [43], these ontologies do not build on existing ontologies commonly used by the building industry, and therefore have classes not fit-for-purpose to be used in building design decision-making.
Construction-related ontologies describe primarily the objects designs deliver to fulfil design requirements.They provide detailed descriptions of physical entities present in a building, including mechanical and electrical systems.Classes include construction entities, built spaces, construction elements and construction properties as well as construction processes, construction resources and construction management information.Called Building Information Management (BIM) [28][29][30][31], they are the most common type of ontology used in building design processes, from design to end-of life.Interestingly, they do not describe design requirements.They are also limited to describe sensors, controls, and operational relationships, and despite widely used in practice are not as powerful as [33] for facilities management.
Operation-Behaviour ontologies account for human-buildingsystem interactions, extracting standard relationships between occupants and these systems so they can be predicted and considered in 1 Wider political agendas cascaded down to implementation via accreditation bodies [93], are pushing building designers, operators and other decision-makers to assess the consequences of their actions in terms of ethics, equality, diversity and inclusion.Together with that, frameworks are put in place to trace liabilities to decisions which can negatively affect end-users [16].
C. Bleil de Souza et al.
building design.They aim to identify behavioural patterns that affect the operation of systems and devices but also include occupant sensing, and object properties related to controllability of equipment by occupants.They include end-user behaviour drivers, needs and actions [44] and can be extended to account for contextual and demographic information about occupants, include physiological information [45] as well as indoor and outdoor environmental conditions and energy flows [46].Some extend to modelling electric energy flows to assess integration with the grid and renewables [47,48].These ontologies are developed to be used in design development to enhance building performance simulation models as they account for energy-related human behaviour when predicting building energy efficiency [44].However, they are not commonly used in practice mainly due to liabilities involved in predicting occupant behaviour (see Ref. [35] for details).
Operation-Facilities management ontologies are used to describe building systems, the sensors, controls and operations associated to them.Building meta-data ontologies like [33,49], which contain a description of building equipment, built spaces, control systems, and resources with relationships developed to understand composition, topology and telemetry describe how components are controlled in detail.Sophisticated operation ontologies such as PhysSys [50] extends composition relationships to topology, mereology and systems theory detailing processes and mathematical functions of multiple types of engineering solutions, describing building systems, services and logistics.These ontologies are useful to facilities managers and have been recently promoted in practice as they are more comprehensive than BIM to describe complex building operation.
End-user assistance ontologies are set to discover relationships among users, activities and services related to them, by inferring information from sensors, devices and agents to develop context aware systems [51][52][53].These ontologies tend to appear in large number in the literature and are mostly related to smart homes.They focus on producing data sources to feed machine learning algorithms to infer relationships between users and devices contextualising their needs for the following purposes: to automatically deliver services to fulfil them [54,55]; to derive end-user activity profiles [56,57] and to deliver custom-based patient care [58] or assisted living [59].Specific uses for these ontologies include assisted living [57,58,60,61], and smart buildings in general with a particular emphasis in domotics [42,59,62,63].These ontologies are not used in design development but mainly after hand-over.They do not cover decision-making in design or construction and do not map ownership of building and system components.

The rationale behind a systemic ontology
Digital models are now supposed to be ubiquitous in design, construction and operation.These models (also called BIM models) are comprehensive and federated, enabling design, construction and operation teams to coordinate the development of solutions and exchange information from conception, manufacturing and assembling up to asset management [64].They are structured around the deliverables of different disciplines involved in building projects and share standardized ontologies [28,29] developed to reduce fragmentation from design to operation [65].
OntoAgency is compatible with Building Information Modelling (BIM), building operation (BRICK Schema [33] & SAREF [66]) and Smart Readiness Indicators' (SRI) ontologies; ontologies commonly used in practice and/or ontologies promoted by the EU to implement ISO and EU standards related to energy transition into practice.Therefore, it fits with the digital models practitioners are used to work and reason with as well as with the main standards being developed to widely implement them.It adds new classes and object properties to connect design and operation requirements with the equipment, spaces and smart services delivering them as well as stakeholders deciding upon, owning and controlling them.It formalises links between design requirements and design parameters poorly explored by BIM and SRI ontologies, while fitting within these links the implications of decisions made for the different stakeholders involved in design and operation processes.
OntoAgency is a product of a collaborative effort.It was built out of several discussions with engineers and architects involved in the IEA Annex 79, particularly working with occupant-centric design ontologies, and involved in modelling occupant behaviour.The main author was heavily involved in the Annex contributing with domain knowledge in building design and building performance simulation, having worked with models and modelling in both disciplinary domains.The co-authors are human geographers specialised in energy transition and smart homes dealing with stakeholders and policy makers in understanding their needs and concerns in relation to social justice, economic disparities and end-users' agency.Close collaboration in development and peer review have included an ontology specialist, an engineer specialist in the operational performance of buildings and an electrical engineer specialised in building energy smart systems.

Methodology
OntoAgency was built following main principles commonly found in the literature related to engineering ontologies [38,[67][68][69] according to the following steps: (i) Scope of the ontology (ii) Conceptualization (iii) Reusable knowledge or reusable parts from existing ontologies (iv) Formalization (v) Implementation (vi) Validation and evaluation.
The ontology scope was defined based on Actor Network Theory (ANT), a theoretical approach used to explain "humans and their interactions with inanimate objects" [70].ANT explains socio-technological reality as relational practices [71].The approach comes from science and technology studies but has now been widely utilised across social science disciplines.ANT is appropriate because it enables one to capture the socio-cultural, economic, political, institutional, and regulatory factors and relations that bring about smart

Table 1
The place for different types of ontologies throughout the building design process (Design stages based on [37]).
C. Bleil de Souza et al.

buildings.
Conceptualization involves describing and defining root concepts for the taxonomy to be used in an ontology.Root concepts in this research were based on the existing literature about design research, engineering and smart building ontologies, and project management.Once core classes were defined, re-useable parts from existing ontologies were adapted to further develop the taxonomy within each root concept.In this case, parts of the Brick ontology [33] were re-used, in compatibility with the SAREF ontology [72], together with the Uniclass labelling [31] commonly used in the UK in Building Information Management (BIM) ontologies.In addition, new taxonomies were created by re-using knowledge from concepts underpinning SRI impact, services and functionalities [73] as well as concepts behind defining and classifying the different stakeholders involved in the design and operation of buildings.Key stakeholder classes were defined based on the actors involved in the whole life cycle of a project [74] in combination with their position in the market and society [75,76], considering they span from local to global levels at the physical, social, political and economic spheres.
Formalization involves the definition and formal specification of the relationships or object properties for the ontology.The rationale behind relationship descriptions comes from design research underpinned by ANT and was built fit-for-purpose to illustrate power relationships and control.Design research [77] was used to specify relationships between different services, functionalities and the physical entities delivering them together with the benefits they provide to the different stakeholders involved in building design and operation.
The ontology was implemented in Protégé 5.6.1 for Windows [78] using RDF/XML syntax but can be converted to OWL/XML syntax (in Protégé), being interoperable with widely used ontologies from building operation and design, respectively BRICK Schema [33] and ifcOWL [30].As stand-alone in Protégé, OntoAgency is portable as models can be recalled from the web and used to create knowledge graphs that illustrate control, ownership and decision-making involved in designing and operating smart buildings for several purposes.Models can be manipulated by inserting, editing and removing entities, therefore enabling different scenarios of control, ownership and decision-making to be generated and assessed.Knowledge graphs can be produced for these models by for instance using the OWLViz [79] and the OntoGraf [80] Protégé Plugins to respectively illustrate class hierarchy and relationships among classes.
Validation was undertaken inside Protégé to check for coherence and consistency.Evaluation was undertaken through practical examples.Scenarios related to changing a heating system simulated by one of the researchers while investigating hypothesis for their own house were simulated using OntoGraf to depict knowledge graphs in combination with discussions related to assessing sufficiency of relationships or object properties descriptions.Root concepts sufficiency as well as the sufficiency of the integrated taxonomy were considered initially valid as they were based either on existing ontologies or widely accepted concepts from existing knowledge domains.Extensive testing and evaluation will be done using the ontology in specific case studies and addressed in future work, which will also discuss specific applications of the ontology in detail.

OntoAgency description
OntoAgency is a descriptive and visual ontology that captures ownership, control and decision-making in smart building design and operation.Its visual power relies on a graph-readable format; a quick and easy way to illustrate flows of control, decisions, and ownership.Classes are re-used from existing ontologies (see prefixes in Fig. 1) in combination with fit-for-purpose developed classes and relationships (denoted by OA prefixes in Fig. 1).OntoAgency can be retrieved in OWL or RDF format from Ref. [81].
By following provision chains, decision-makers can qualitatively gauge how design solutions are meeting design and operation requirements and reverse engineer the design process for quality control purposes, knowledge sharing and liability tracing.By following control chains, decision-makers can assess who is responsible for delivering the different benefits and experiences in a project as well as the complexities and level of automation behind this delivery, including the data flows associated to them.By tracing who decides upon a given benefit or experience, decision-makers can verify whether the stakeholder behind the delivery of a decision is the same one deciding upon the benefit and experience being delivered with the consequences thereof in terms of fulfilling expectations, efficient delivery, vulnerabilities, and target meeting for the different stakeholders involved in a project.By tracing ownership, decision-makers can assess their portfolio while at the same time evaluate overlaps and nested assets, therefore, predicting liabilities involved in care responsibilities and change on building ownership, foreseeing hidden issues for end-users, policy implementation and market uptakes.
The rationale behind the definition of classes and their relationships or object properties are described in this section.The description intends Fig. 2. 'OA Design Requirements' with 'OA benefits and Experiences' and a sample of 'SRI Building Operation Services' and 'SRI Functionality Levels of Smart Services'.
to show that OntoAgency is extensible and flexible as classes are nonexhaustive and can accept new additions and constant enhancement and refinement.

Main classes
Classes are "named categories with intentional meaning (definition) used for grouping entities" [82], which are representations of what is being modelled.They are organised hierarchically based on a series of existing ontologies.Fig. 1 illustrate the four main classes of OntoAgency, namely: 'OA Design Requirements', 'OA Design Parameters', 'OA Agents' and 'OA Stakeholders'.

OA design requirements and its sub-classes
'OA Design Requirements' are groups of classes which describe what a smart building needs to accomplish for its stakeholders and in what manner.They describe what the smart building will do (functions) and how well it will do (quality attributes); both need to be clearly communicated across the design and development team [83].
At a technical level, they translate stakeholders' needs into actions for designers to respond to when designing (e.g., provide heating, provide cooling).At a socio-technical level, they are where the needs of the client are translated into the functions and qualities the project needs to fulfil, following asset management principles [8].This means seeing end-users as customers whose needs, and expectations are to be considered together with the ones from other stakeholders, internal (organization employees, shareholders, owners, etc.) and external (suppliers, contractors, taxpayer, invertors, etc.) to the organization managing the building.At a social level, they are where the business domain meets with the engineering and architecture domains as they bring asset management and asset value to the core of design, construction and operation, to reduce the performance gap between design and in-use.Requirements are always abstract but need to be clearly specified so they can be audited, recorded, stored and re-used [8,10,29].They are likely to be standard at the top level but highly custom-based at the bottom level.Requirements are elicited by the brief and are exhaustive for each given project.
'OA Benefits & Experiences' are the collection of ultimate deliverables a smart building needs to fulfil.They are the main design requirements behind a smart building project and can be decided upon by multiple stakeholders.Some are standard across smart building projects (Fig. 2) and are based on the 'Impact' classes from Ref. [73] in combination with overarching benefits commonly found in the building literature and core tasks defined by SAREF [66].However, they are highly abstract and need to be decomposed into more concrete requirements for designers to achieve with their designs, primarily leading to design action.
'SRI Building Operation Services' are a collection of standard functions a building or its content needs to fulfil to provide many of the benefits and experiences expected by its stakeholders.Sub-classes of 'SRI Building Operation Services' are based on the different domains in which the services within a building operate, for instance, heating, cooling, controlled ventilation.Each domain contains several sub-classes, which are an abstraction of the service "enabled by (a combinations of) smart ready technologies but defined in a neutral way" [73].These sub-classes are a mirror of the ISO 52120 [34] but can be expanded to include sub-classes from for instance SAREF 'Tasks' [84], e.g., washing, drying, cleaning.
'SRI Functionality Level of Smart Service' are a collection of abstract descriptions of the functions a group of systems delivers once in operation.These levels are technology neutral and refer mainly to functions related to performance control (e.g., indoor air quality, energy efficiency, etc.), energy storage capability in connection with other functions, connection capabilities between different service parts in general, and reporting on performance or on maintenance issues in general (from fault detection to prediction).They mirror the definitions from Refs.[34,73], namely 'Not-Smart', 'Smart Level 1', 'Smart Level 2', 'Smart Level 3', and 'Smart Level 4' with their respective sub-classes.

OA design parameters (solutions) and its sub-classes
'OA Design Parameters' are groups of classes which describe how a smart building does what it has to do.They are physical variables responding to the different functions and quality attributes a smart building needs to have.They also need to be clearly communicated across the design and development teams.
At a technical level, they are the design deliverables; the assemblage of the different spaces, equipment, and interfaces a design will deliver to fulfil client needs.At a socio-technical level, they are the tangible product delivered to the client which needs to abide by a set of standardized asset management principles [8] and systems [9].As part of these principles, deliverables related to customers (building end-users) are supposed to be measured according to the level of services a given asset (building) provides them in relation to meeting their needs and expectations [8].At a social level, they are a financial asset with clear market value exchange, "the operation of which often revolves around shared conventions and agreed forms of standardized description, measurement and provision" [85].They are also likely to be standard at the top level but highly custom-based at the bottom level and therefore prone to classification.
'SL Built Spaces' is a Building Information Management (BIM) class defined by Ref. [29], to denote a collection of spaces in the built environment that host specific activities and/or equipment.These spaces are labelled based on the types of activities they host which are standard across building projects.Examples for standard activity labels can be found in NBS Uniclass [31] or in the 'Space' class from the Brick ontology [86].'SL Built Spaces' are scalable as they can accommodate different resolutions related to building descriptions, from spaces to full buildings (as per Uniclass ontology).Since the examples developed in section 5 refer to a smart home, typical 'SL Built Spaces' found in homes are used as an example for this class in (Fig. 3).
'Brick Equipment' are a collection of standard solutions or devices delivered to the client to fulfil design requirements.This class and its sub-classes are based on the Brick ontology [87], more comprehensive but still compatible with SAREF class 'Device' [88].'Brick Equipment' components work together with specific 'SL Build Spaces' or the whole building to deliver the different 'SRI Building Operation Services' specified in a design project.This class is of particular importance to smart buildings as it contains all the systems and apparatus that effectively delivers the different smart buildings functionalities.

'OA agents', 'OA stakeholders' and their sub-classes
'OA Agents' represent a fit-for-purpose class developed to express agency behind an 'SRI Functionality Level of Smart Service' to be delivered.'OA Agents' can be an 'OA Person', an 'OA Company' or an 'OA Machine'.If an 'OA Person' or an 'OA Company', they overlap with the 'OA Stakeholders' class.If an 'OA Machine', they overlap with the 'Brick Equipment' class.When 'OA Machines' are set as 'OA Agents', there will be one or more 'Brick Equipment' either directly operating or coordinating the operation of 'SRI Functionality Level of Smart Services' to be delivered (Fig. 4).This is a fit-for-purpose class which shows who or what is ultimately responsible for providing a specific 'OA Benefit & Experience' (see full scheme in Fig. 2).
'OA Stakeholders' is also a fit-for-purpose class developed to denote a collection of people, communities or companies with an interest, concern, stake, control, decision-making power, or ownership of the different entities involved in smart buildings' design and operation.Classes are defined based on the different interests stakeholders have in a building [10], in combination with their position in the market [75,76] and the roles and responsibilities they have in regulating, controlling and delivering the different tasks involved in a project [89].Stakeholders are at the center of this ontology as they define who owns a building, its systems, services, and parts ('SL Build Spaces' and 'Brick  Equipment') as well as who decided upon the 'OA Benefits & Experiences' to be provided by a project.
'OA Stakeholders' decide upon 'OA Benefits & Experiences' to be provided by a building but they do not directly operate 'SRI Functionality Levels of Smart Ready Services' delivering them unless they overlap with 'OA Agents'.Note that a lack of overlap (e.g., Figs. 6 and 7) needs to be carefully inspected to assess if goals behind those deciding upon an 'OA Benefit & Experience' match with goals behind those proving them.Overlaps, on the other hand, should also be carefully inspected (e.g., Fig. 5) to assess if efficiencies in deciding upon 'OA Benefit & Experience' and those providing them can be optimized, potentially making robust cases for increasing the 'SRI Functionality Level of Smart Service' to be delivered towards, for instance, meeting health or energy efficient targets.

Relationships or object properties
Relationships or object properties define the types of links between entities [82] and are organised based on four different principles: Possession, control, provision and exchange (Fig. 1).These principles are defined to explicitly show the social context behind the different benefits, experiences, requirements and solutions delivered by smart buildings.
Relationships are presented with a full description of what they mean and examples of how they can be used.Clear indications about where data to model relationships can be obtained is provided, followed by their applications to a set of cases in section 5 to illustrate how useful they are to enable tracing chains of ownership, control and decisionmaking in smart buildings design and operation, highlighting points of information leakage with their associated security issues.
Compositional relationships, which define that one entity is made of other entities, in this ontology are captured by class hierarchy (e.g., heating services contain heating emission services, heating generation services, etc.) and not discussed in detail in this paper.This is because the focus of this ontology is to explore the consequences of design and operation decisions in stakeholders' agency rather than to trace resources or information flows.

Possession relationships
Possession is expressed as ownership either of a physical entity, using the form of OA:isOwnedBy, or as ownership of a decision OA:isDeci-dedBy (Fig. 1).The expression OA:isOwnedBy denotes who owns the physical parts of a building or its systems (i.e., who owns 'Brick Equipment' and 'SL Built Spaces').It is a powerful resource to show clients where exactly their investments are going, since ownership denotes which assets they possess.At the same time, the relationship highlights which assets are likely to overlap, be nested with or within each other and, if having different owners, provide evidence for discussions related to Rights to Property for these overlapping and/or nested assets.For instance, in Fig. 7, the heat pump belongs to 'Company Z', but the building still belongs to 'Sam'.This example illustrates the case of nested assets as the heating generation inside the building does not belong to the same stakeholder who owns the building.This expression enables one to gauge the share each 'OA Stakeholder' has of a building or its systems to effectively assess their asset portfolio in each project while at the same time foresee legal implication involved in asset nesting and/or overlapping.
The expression OA:isDecidedBy shows who decides upon the 'OA Benefits & Experiences' a building provides rather than who are the beneficiaries.This is an important distinction as it shows many decisions are not actually made by beneficiaries, who many times are supposed to be the end-user (see examples in section 5) or society in general (in case of reducing emissions), but by other 'OA Stakeholders' involved in the design process 'on behalf' of the end-user and society in general.Labelling who decides is important to attribute responsibilities and traceability of decisions from design to operation, potentially exposing liabilities and vested interests along the way.It is a powerful resource to show 'OA Stakeholders' interests and end-goals in a clear way, facilitating the negotiation of design and operation objectives as well as aiding conflict resolution.In addition, it enables one to gauge the share on decision-making each different 'OA Stakeholder' carries in a design project to effectively illustrate their decision-making power.For instance, in Fig. 7, 'Company Z' is deciding on two benefits whereas other 'OA Stakeholders' are only deciding on one benefit each.Assuming 'the degree of strength' of benefits and decisions are all nominally equal between themselves, this potentially indicates 'Company Z' is twice more powerful in deciding about the heating and electricity services provided in this project than any other 'OA Stakeholders' involved in it, showing that end-users effectively share 1/3 of the decisions in this situation.
Possession relationships are always extracted from real data and might be generalizable to country level if the relationship is explicitly stated as part of a given country's legislation or regulation (e.g., in many countries utility companies are normally the owners of building electricity and gas meters).Real data to model these relationships needs to come from contracts, legislation, regulations, or interview with stakeholders involved in building design and/or operation processes.

Control relationships
Control relationships are transitive and expressed as OA:IsCon-trolledBy (Fig. 1).They connect design requirements with 'OA Agents' and enable one to gauge what proportions of each building function are at the hands of machines or individuals, i.e., to quantify the amount of automation in a building.
The expression OA:IsControlledBy shows which type of functionality is controlling a specific service being delivered, exposing the degree of smartness this service effectively holds.Note that both the service delivered, and the functionality level associated to it, are design requirements.They are both abstract but clearly express the type of data being collected together with how this data will be acted upon.For instance, in Fig. 5, no smart functionality is controlling heating emission, therefore, no data is being collected about it.However, in Fig. 6, heating emission is controlled by 'Individual Room Controls', meaning data related to heating emission will be collected (e.g., room temperatures), processed and acted upon for each room independently (e.g., changing the amount of heating delivered to each radiator so setpoint temperatures at each radiator are individually met).
The expression OA:IsControlledBy is transitive, therefore, it also shows who is responsible for the functionality requested, i.e., who is authorising data collection and processing so the service is provided according to the level of functionality set.Note that 'OA Agents' are not, but can overlap with, 'OA Stakeholders' and/or 'Brick Equipment'.Connecting functionality levels of smart services either to an 'OA Machine', 'OA Person' or 'OA Company' enables a clear display of how much automation is used to operate the different building services delivered as well as who is behind the data flows involved in these deliveries (see section 4.1.3for overlaps between 'OA Agents' and 'OA Stakeholders' and section 5 for examples of how to trace data flows to specific 'OA Stakeholders').Note that, in Fig. 5 there are no 'OA Machines' in operation whereas in Figs. 6 and 7, 'OA Machines' are operating all functionalities for the different services being delivered, ultimately controlling them.However, Figs. 6 and 7 do not have the same type of 'OA Stakeholder' behind the data flow involved in the delivery of these functionalities as the 'Brick Equipment' delivering them is owned by 'Sam' or 'Company Z' respectively.Real data to model the first part of the control chain can be extracted from Refs.[34,73] or project documentation.The second part of the control chain can either be obtained through interviews with stakeholders or, most of the times, directly inferred from the 'SRI Functionality Level of Smart Service' associated with a given 'SRI Building Operation Services' (e.g., when 'SRI Lighting Services' have 'Manual on-off Switch', they are directly controlled by the building occupant).

Provision relationships
Provision relationships are also transitive and expressed by OA: isProvidedBy (Fig. 1).They express how design requirements are ultimately achieved, i.e., they connect the 'OA Benefits & Experiences' to be achieved with the physical assets that deliver them.They are important relationships to aid design auditing in terms of checking how design requirements are being met.
The expression OA:isProvidedBy shows which services provide the different benefits and/or experiences needed in a building.It is important for a design team to see which services provide the same benefits as well as which benefits are achieved with combinations of different services, supporting reasoning within design and operation teams, facilitating the negotiation of design and operation objectives as well as aiding conflict resolution.For instance, in Figs. 5 and 6, 'Thermal Comfort' is provided by two different types of heating services which need to be properly coordinated to ensure the benefit they are supposed to provide.Once this is clearly seen by design and operation teams, it becomes easier to coordinate solutions to be proposed.
Since the expression OA:isProvidedBy is transitive, it also shows which 'Brick Equipment' and/or 'SL Built Spaces' deliver the services required by a project.I.e., which specific design parameters deliver each different design requirement.Having histories of what chains of design requirements lead to what specific design parameters, 'Brick Equipment' and/or 'SL Built Spaces', delivering them in an easy-to-interrogate format is highly attractive.These chains facilitate interdisciplinary collaborations [90,91], make expert reasoning transparent, expose flaws, prevent future errors and fallacies, and enable version control and accountability to be traced [90] as a full record of the process is in place to be audited.
Provision chains streamline qualitatively what design parameters meet what functional requirements, facilitating reverse engineering of design and operation decisions.Since they express clearly how design responds to stakeholders needs, they are the nexus for tracing consequences of design and operation decisions in any project.I.e., they show the origin of each decision behind the different consequences they have afterwards.For instance, in Fig. 7, the decision to provide heating via 'Smart Heating Emission' delivering it through 'Smart Radiators' is at the centre of understanding how this delivery happened and who were the 'OA Stakeholders' behind it.Real data to model provision relationships come from project documentation, in-situ inspections or interviews with stakeholders involved in building design and/or operation processes.

Exchange relationships
Exchange can be expressed as either contractual through OA:share-sInformationWith or involuntary through OA:hasAccessToInformation-From (Fig. 1).They express data flows between 'OA Stakeholders' and 'Brick Equipment' (Fig. 1).Contractual exchanges imply 'OA Stakeholders' consent, whereas involuntary exchange implies data can be accessed by 'OA Stakeholders' through 'Brick Equipment' connected to the Internet of Things (IoT).
Exchange relationships show the consequences of design and operation decisions to 'going smart' for the different 'OA Stakeholders' involved in a project.More specifically they show what are the consequences of including 'Smart' design parameters for end-users' privacy, since they explicitly imply data sharing of some sort.Note that once a decision for going smart is made, access to internet is established therefore opening the door for involuntary exchange to happen (e.g., Fig. 6 IoT tag sharing information with 'Anonymous').If the 'Smart Equipment' does not belong to the end-user, there are generally contractual clauses of consent to share information with the owner of this 'Brick Equipment' in place (e.g., Fig. 7), meaning end-users consent to lose privacy of some sort through contractual data sharing.This is particularly the case when 'OA Machines' are set as 'OA Agents' so data can be processed and acted upon to enable a specific service to be delivered.
Information on contractual exchanges come from real data and might be generalizable to country level if the relationship is explicitly stated as part of a given country's legislation or regulation (e.g., installing smart metering necessarily involves sharing end-user data with energy supply companies).Real data to extract contractual exchanges either comes from contracts (e.g., smart meter contracts which imply consent of the stakeholder to share information on energy use) or is sourced by interviews with stakeholders.Involuntary exchanges are always inferred based on 'Brick Equipment' connection to the IoT.Whenever connected to the internet, an entity from the 'Brick Equipment' class is inferred as a gate to information, flagged by an IoT tag.Connection to the internet can be inferred based on the 'SRI Functionality Level of Smart Ready Service' controlling the entity of the 'SRI Building Operation Domain' associated to each 'Brick Equipment'.Involuntary exchange of information creates issues with cyber security as they open opportunities for hacking, intrusion and information manipulation and control via 'Anonymous' Stakeholders.
The modelling of contractual and involuntary exchanges can be expanded using the SOUPA ontology [92] which has a special set of classes to represent policies related to security and privacy as well as rules that either permit or forbid the execution of certain actions.Since actions related to information exchange go from requirements set up in service providers' contracts to country data protection laws, interesting overlaps can be unfolded from these explorations.An example would be building owners requesting access to energy use from tenants when this data overlaps with Right to Property (e.g., when tenants do not heat their houses, condensation is likely to happen, creating asset maintenance problems which can lead to asset devaluation).

Attributes or data properties
IoT Tags are specific attributes of interest from an entity which can be connected to the Internet of Things (IoT) such as sensors that capture voice, image and/or any other type of 'Brick Equipment' that is connected to the internet and, therefore, can be used to retrieve information (e.g., Cameras, video cameras, microphones, appliances or systems with internet connection, etc.) or remotely monitor and control components delivering 'SRI Building Operation Services'.They do not define an entity but are used for easy retrieval or filtering of points of information flow, monitoring, control and/or leakage.IoT Tags are defined by the data property OA:hasConnectionToInternet and will have their domain in 'Brick Equipment' classes with their range assigned as xsd:boolean.Data properties will be assigned to individuals within the 'Brick Equipment' class.Further attributes might be defined once the authors expand this ontology based on case studies which will further detail its design and application.

Validation and evaluation
OntoAgency was validated using Protégé Pellet reasoning in combination with Protégé Debugger and rated as coherent and consistent.This session evaluates ontological relationships, illustrating how to read control chains, decisions upon benefits and experiences as well as ownership and data flows in a set of three scenarios.The scenarios are specifically developed to assess the consequences of increasing smartness in a simple house heating system as faced by one of the authors while assessing different possibilities of heating retrofit for his/her house namely 'SRI Not smart', 'SRI Smart Level 2' and 'All electric house'.Scenarios were built based on quotes, information and website searches; therefore, names of the stakeholders were changed to avoid disclosing people's and companies' identities.The example is useful to evaluate the proposed ontology in relation to sufficiency of relationships or object properties descriptions, since root concepts sufficiency as well as the sufficiency of the integrated taxonomy were considered initially valid as they were based either on existing ontologies or widely accepted concepts from existing knowledge domains.

Scenario 1 -not smart
Fig. 5 illustrates the example's scenario 1, the baseline scenario, a family house with a non-smart heating system.By following the provision chain, it is possible to see that 'Thermal Comfort' is provided by a basic heating system delivered by a boiler and radiators with 'No Automatic Control' function associated to their operation.By following the control chain, one can see that the 'OA Agent' responsible for delivering the 'SRI Functionality Level of Smart Ready Service' is 'Sam', the 'End-User' and 'Domestic-Client' as the system has no automation embedded in it, and 'OA Stakeholder' and 'OA Agent' overlap.
Since 'Sam' is the 'OA Stakeholder' deciding upon the 'OA Benefit & Experience' of 'Thermal Comfort', but also the 'OA Agent' controlling its delivery, (s)he has to effectively judge when to turn the heating on or off whenever appropriate, acting upon it, and/or run it on a fixed schedule set to operate the boiler.Whereas this enables him/her to freely control the system and decide upon its operation, it places a responsibility on him/her to do all the work.Economies of energy are difficult to control in this scenario as 'Sam' cannot fine tune his/her operation of the 'Heating Emission Control' to make the best use of boiler efficiencies and is not able to constantly assess indoor air temperatures either.
The result is the house has a simple heating system design that is not energy efficient and is difficult to operate because it requires constant engagement of the 'End-User'.However, a reasonable level of 'Thermal Comfort' is provided, and households have full agency on their heating system and full Right to Property on the house, despite the inefficient heating system which is likely to reduce the value of the house in the market.

Scenario 2 -SRI Smart Level 2
Fig. 6 illustrates the consequences of implementing scenario 2, when the house heating system is upgraded to 'SRI Smart Level 2', an affordable package offered by many service providers.By following the provision chain, one can see that 'Thermal Comfort' is provided by a smart heating system, which includes a 'Smart Boiler' with 'Smart Radiators' and a 'Wireless Thermostat'.The thermostat enables 'Individual Room Control' and since more than one room can be controlled individually, it also enables the control of thermostatic valves to operate 'Heating Emission' individually, therefore enabling the boiler to be operated based on 'Variable Temperature Control Depending on Load'.By following the control chain, it is possible to see that the 'Agent' now responsible for delivering the 'SRI Functionality Level of Smart Ready Service' is an 'OA Machine', meaning heating is now automatically controlled.
Since 'Sam' is the 'OA Stakeholder' deciding upon the 'OA Benefit & Experience' of 'Thermal Comfort' but not the 'OA Agent' delivering it, (s)he can still decide when to turn the heating on or off but does not have to act upon the heating demand to match it anymore.(S)he simply needs to provide the setpoints and/or schedules for the thermostat to operate as heating delivery is controlled automatically.This means (s)he is still the ultimate decision-maker in relation to 'Thermal Comfort' but now has a better indoor comfort condition as supply and demand are automatically aligned, giving the extra benefit of 'Gas Energy Saving'.
The 'Wireless Thermostat', however, is sold associated to a service package which includes monitoring 'End-User' energy consumption to deliver reports via a mobile phone/computer app.This service implies contractual data sharing with 'Company Y' but since it involves using the IoT, it also implies involuntary data sharing leaving 'Sam' vulnerable to get his/her thermostat accessed by hackers online.'Sam' has the right to opt out from the app and leave the monitoring scheme, but (s)he cannot disconnect the thermostat from the wireless network as this is needed to control heating emission.'Sam' retains large degrees of agency on her heating and gains the benefit of improved 'Thermal Comfort' and 'Gas Energy Saving' but is now vulnerable to hackers (represented by 'Anonymous'), losing agency over his/her data, despite being able to disconnect from 'Company Y' at any time.
In this scenario, the house has still a reasonably simple heating design, now more energy efficient, which is easy to operate because it requires only checks and settings rather than constant monitoring.It can be attacked by hackers but does not depend on the services of 'Company Y' to function.Households retain Right to Property and the house now has a higher market value due to a more energy efficient heating system.

Scenario 3 -all-electric house
Fig. 7 illustrates the consequences of implementing scenario 3, when the house is converted into all-electric.It shows what happens if 'Sam' decides to lower energy costs, while at the same time upgrade her house Energy Performance Certificate (EPC) to comply with government transition programs. 2'Sam' has no money to invest upfront and knows the payback time is long, meaning loans are not an option.Therefore, (s) he decides to lease an all-electric package of space heater, temperature control and solar device which includes a heat pump, PV panels and battery plus a special energy rate if (s)he buys her energy from 'Company Z'.This is a subsidy free scheme with a competitive price for those who cannot afford high upfront costs.It works as a 'solar lease' where a third-party company, installs, owns, and maintains the PV panels, storage and heat pump.It enables 'End-Users'/'Domestic-Clients' to afford major heating renovation, transitioning to clean energy generation and phasing off from in-situ CO 2 emissions while at the same time upgrading EPC ratings which, in theory, would increase market value to their houses.
By following the provision chain, one can see that 'Thermal Comfort' is provided by a smart heating system, which includes 'Z Heat Pump' and a 'Wireless Thermostat', resulting in an internal heating provision like scenario 2. By following the control chain, it is possible to see that besides the 'Wireless Thermostat' another 'OA Machine Agent' is added to the system, 'Z Control Centre' to automatically coordinate electricity demand and supply as the in-situ electricity generation trades with 'Company Z' accordingly, a job that no human can manage alone.Note that, the control chain becomes now far more complex as the heating system is part of an in-situ electric generation system which needs to fine tune the amount of energy it buys and sells back to the grid considering heating as a factor within it but not its single determinant. 3This control chain involves data exchange with 'Company Z' as 'Sam' cannot trade in-situ electricity generation without sharing data with it.(S)He remains vulnerable to hacker attacks by connecting to the IoT, however, contrarily to scenario 2, (s)he cannot opt out from data sharing with 'Company Z' as this would make energy trading impossible.The result is 'Sam' loses agency over her personal data and increased her vulnerability as her ultimate interaction with the system is now controlled by 'Company Z'.
As in scenario 2, 'Sam' is the 'OA Stakeholder' deciding upon the 'OA Benefit & Experience' of 'Thermal Comfort' providing the setpoints and/ or schedules for the thermostat to operate it, having the power to switch the heating on or off at any time.(S)he has the extra benefits of 'Electric Energy Savings' which (s)he shares with 'Company Z'.However, 'Company Z' decides upon the benefits related to 'Electricity Energy Savings' as well as benefits related to 'Contributions to the Grid'.This is because it is 'Company Z', not 'Sam', that trades with the grid.Since 'Sam' trades with 'Company Z,' (s)he is not able to influence and negotiate energy prices with peers and has no opportunity to directly participate in decentralised generation schemes.'Sam' is now tied to 'Company Z' as her/his energy supplier potentially having to cope with price increases incurring on his/her lease contract and not being able to take advantage of tax incentives and solar rebates which might be available in the future, therefore not directly influencing her/his own energy savings.The result is 'Sam' has no agency over 'Electric Energy Savings' and 'Contributions to the Grid'.
In this scenario, the house has a complex heating and electricity supply design with a higher EPC rating, but still reasonably easy to operate as 'Sam' only has to deal with thermostat and/or schedule settings.Households constantly share data with third parties and lose ownership of their heating generation system which now belongs to 'Company Z'.They also have no ownership of the electricity generation system and storage, a situation which, together with losing ownership on the heating generation system, complicates Rights to Property.'Sam' cannot sell the house with the package provided, unless (s)he buys it from 'Company Z' or ensures the new homeowner signs a deal with 'Company Z' to uptake the lease.Transferring the lease to a new house would mean selling his/her house with no heating generation.Any of these sub-scenarios are likely to affect the value of the house in the market, with the latter one potentially lowering the EPC rating of the house.In the end, 'Sam' is partially dispossessed, has no agency over his/her personal data and no agency over 'Electric Energy Savings' and 'Contributions to the Grid'.

Implications for decision-makers
These scenarios illustrate how the ontology can be used to enable building owners (and other stakeholders) to assess the impact of decisions related to changing degrees of smartness in buildings.They also illustrate what happens when 'OA Benefits & Experiences' are provided by different or multiple 'OA Building Operation Services', delivered by different 'Brick Equipment' and controlled by different 'SRI Functionality Level of Smart Service'.Broadly, the scenarios illustrate what can happen when higher levels of smartness towards achieving stringent energy transition targets are imposed on end-users, but no affordable mechanisms are provided for them to uptake these changes.They are also useful to potentially show the indirect consequences of increasing technical complexity and its impact on management, maintenance, and capital costs, which open market opportunities, on the one hand, but are likely to disempower end-users on the other hand.
The scenarios demonstrate, for example, that with an increasing servitization of the functions that a building performs, 'the bundle of rights' that constitute homeownership becomes increasingly more fragmented and illusive, because it is no longer specified at the level of the building as a whole but rather at the level of building components.Components may be owned and controlled by external providers, who also impose limitations on the homeowner's right of access, management, exclusion, alienation etc.Over these components.The service providers also control data flows associated with these components.In an extreme scenario, homeownership may become residualized and largely replaced by a 'bundle of services' which would split the building into a set of many subsystems none of which the 'homeowner' would own.In this sense, the scenarios anticipate case studies for policy makers, legislators, and regulators as they clearly connect energy transition with complexities related to Right to Property and data sharing.They also provide food for thought to the market by showing to what extent the servitization of building components can be sold as a benefit to end-users.
Conventional engineering models neglect the impact of changing ownership, control, and decision-making on end-user/owner agency.OntoAgency lets decision makers assess the practical and systemic implications of, for instance, implementing energy transition programs without direct incentives to owners/end-users.The scenarios show the ontology is systemic, illustrating its versatility to capture the power of each stakeholder involved in a project. 3Household electricity consumption for lighting and appliances would also be factored in this trade but are not modelled in this scenario to reduce cluttering.
C. Bleil de Souza et al.

Conclusions
OntoAgency places smart buildings in a relational social context.It is a socio-technical ontology that explicitly models the interconnectedness between the different stakeholders designing and operating smart buildings, interwoven with the functionalities delivered by different smart building components which together deliver the smart building 'experience'.It enables the exploration of decision-making consequences, changes of ownership, variations in contractual requirements specifications through to the identification and prediction of interagents' relationships involved in the adoption of smart technologies throughout building design and operation.
The ontology is consonant with the decision-making process of professionals involved in design and operation who 'reflect in action' as it enables the implications of each decision to be assessed in relation to their impact into the multiple stakeholders involved in a project, so experimental scenarios can be built on the go.Models expose relationships of control, ownership, and decision-making, being an interesting instrument to illustrate the consequences of policy making, design and operation decisions.They are a useful tool to reflect in action particularly if policy makers, designers and building managers want to understand the ramifications and impact of their actions from a systemic perspective (including social, economic, financial, and legal).
The ontology is dynamic and enables different types of 'disruptions' to be modelled, as for instance the different scenarios discussed in section 5. To this end, it can be used to, for instance: • Explore what happens when changing decision-makers deciding upon the 'OA Benefits & Experiences' being provided in a project.• Analyse how the relationships between different agents and/or stakeholders and their degree of control over different building systems change upon installing and altering smart systems in building operation.• Explore different types of decisions related to energy efficiency and indoor air quality in buildings considering the 'OA Agents' that will be controlling and operating functionalities related to them.• Trace and potentially quantify the contribution of each 'OA Stakeholder' in decision-making, control, and ownership in relation to a given 'OA Benefit & Experience'.• Show optimum levels of smartness for the different 'OA Stakeholders' involved in a project towards reaching concerted actions from deciding upon project priorities up to implementing energy transition programs.• Extract issues which need to be regulated not to disempower 'End-Users/Domestic-Clients'.• Extract market opportunities and develop further models to assess their impact on the different 'OA Stakeholders' involved in a project.• Enable investors, designers, building services and building control engineers to develop models of preferences for different clients to better cater for their needs.• Enable regulators to develop and assess different models of ownership and control behind smart buildings.
The ontology is easy to use and is stand alone, meaning models can be developed in Protégé directly without the need for more sophisticated tools.However, since the ontology is object-oriented and modular and runs in either RDF/XML or OWL/XML syntax, it is also interoperable with BIM and BRICK Schema, meaning it can be connected to existing ontologies to support decision-making in design and operation considering very detailed decisions and models.Protégé has a graph data explorer to enable relationships to be filtered, ranked, traced, queried, and replaced for different scenarios generation.Alongside this, multiple knowledge graphs can be stored, displaying common relationships, common functionalities, different levels of functionality, common power relationships, etc.Such capabilities enable one to produce and curate an intelligent database for smart building models, to evidence-base discussions, enabling practitioners, owners and policy makers to make decisions with regards to the smart functionalities they want to have and the 'price' they want to pay for them in association with their ability to own and control the different parts of their building and its functions.
Future work will focus on deploying OntoAgency to different cases to evaluate the usefulness of its classes and relationships to aid decisionmaking in design, operation and policy making.The authors expect to undertake a careful exploration on how 'SL Built Spaces' and 'Brick Equipment' work together to deliver smart co-living experiences, so 'SL Built Spaces' are further described and integrated to the ontology.Future work will also include exploring models with variable (seasonal) and/or shared ownership of 'Brick Equipment' and 'SL Built Spaces' to further refine the object property OA:IsOwnedBy and explore whether it can accommodate dynamic market subversions of rights to property.The authors will also expand the ontology, so that it becomes fully interoperable with IFC.

C
. Bleil de Souza et al.

Fig. 4 .
Fig. 4. 'OA Agents' and a sample of 'OA Stakeholders' with sub-classes showing examples of overlaps between them.

Fig. 6 .
Fig. 6.Model of the implementation of scenario 2 highlighting decision-making and ownership from 'Sam'.

Fig. 7 .
Fig. 7. Model of the implementation of scenario 3 highlighting decision-making and ownership from Company Z.

C
. Bleil de Souza et al.

2
European Commission.2013b, COMMISSION DELEGATED REGULATION (EU) No 811/2013 of 18 February 2013 supplementing Directive 2010/30/EU of the European Parliament and of the Council regarding the energy labelling of space heaters, combination heaters, packages of space heater, temperature control and solar device and packages of combination heater, temperature control and solar device.