AN ONTOLOGY-BASED COST ESTIMATION FOR OFFSITE CONSTRUCTION

SUMMARY: Design for manufacturing and assembly (DfMA) has been widely applied to support the decision-making process in offsite construction. With a DfMA approach, cost estimation requires taking product design and production processes into consideration. Current studies conduct cost estimation built upon quantity take-offs. However, they do not provide a vocabulary to relate cost estimates to offsite construction processes. This paper presents a new domain ontology, Offsite Housing Ontology (OHO) using the NeOn methodology framework to support cost estimation considering products, resources, and production processes. OHO semantically defines offsite construction domain terminology and relationships. This supports a unified model, required for efficient collaborative design management. The efficiency and effectiveness of the OHO approach are demonstrated in a real-world DfMA scenario through the development of a Knowledge-Based Engineering tool to automate cost estimation. The approach can be adapted and extended to accommodate a very wide range of offsite housing, delivering important optimization and automation benefit from DfMA solutions.


INTRODUCTION
Offsite construction aims to standardise and automate production processes in a factory environment through applying manufacturing design concepts (Hairstans and Smith, 2018).To construct offsite effectively and efficiently, it requires products to be designed systematically through adopting Design for Manufacturing and Assembly (DfMA), a philosophy and design methodology (Boothroyd, 1994).DfMA evaluates and improves the design by considering downstream processes of manufacturing and assembly in the early design stage (Lu et al., 2020).DfMA is comprised of Design for Manufacturing (DfM) and Design for Assembly (DfA).DfM targets the selection of materials that minimise wastage, optimise processes and sub-processes, optimise parts and systems and fulfill tolerance requirements (Stoll, 1986), whereas DfA focuses on minimising the number of modules for assembly and optimizing the assembly process (Bogue, 2012).In practice, DfMA contains a list of design guidelines (Bogue, 2012;Emmatty and Sarmah, 2012;Swift and Brown, 2003).An example of the guidelines can be avoiding undercuts or other features which require special operations and/or tools.
Although it is common practice to use Building Information Modelling (BIM) for design and production of information, DfMA has not been widely applied in building design due to the lack of information and structured knowledge (Ayinla et al., 2020;Blismas and Wakefield, 2009), big data sources (Gbadamosi et al., 2019), and documented sources of information on process modularisation (Murtaza et al., 1993;Pasquire et al., 2005).There are efforts to develop DfMA frameworks, e.g. the synthesis of construction-oriented DfMA guidelines (Tan et al., 2020), but there is not yet an approach to systematise DfMA knowledge that enables designers to evaluate modular design.One main obstacle to apply DfMA in designing modules is the lack of tools that evaluate modular design, typically requiring input from several professionals with expertise in off-site production, costing and scheduling.Current practice relies largely on either heuristics or broad estimates, without an analysis of the relations and interactions of processes and sub-processes to the activity level (Shi et al., 2008).For DfMA to be applied widely, an appropriate data modelling approach and corresponding data models need to be developed.
In this regard, this study aims to integrate manufacturing information into BIM-based building design.Semantic web technologies has proved to facilitate data integration from heterogeneous data sources in the construction industry (Farghaly et al., 2019).However, through a literature review on current ontologies, we found that no ready-to-use and similar solutions can be adopted to integrate building design and production knowledge.Therefore, a new Web Ontology Language (OWL) domain ontology (i.e.Offsite Housing Ontology (OHO)) is proposed here to represent the domain knowledge of DfMA.The ontology developed was used to build an online knowledge-based engineering tool for estimating cost for modular house construction to demonstrate the use of OHO.In the end, the OHO was discussed to accommodate a wide range of offsite products.

LIMITATIONS AND POTENTIALS OF DATA MODELS FOR DFMA
The introduction of BIM provides an opportunity to structurally embed data in relation to processes and other attributes within a three-dimensional (3D) building model (Hijazi and Omar, 2017;Taylor and Bernstein, 2009).For instance, it is common to have process-related data, typically used for the scheduling (i.e.4D BIM), and cost data, typically for estimating of building costs (i.e.5D BIM), integrated to the BIM model.While the data for scheduling are process-related, they refer mainly to activities onsite.Cost estimating during design development, on the other hand, does not use process-related data at all (Dave et al., 2018).
Although there are tools attempting to integrate the process and cost data to enable simultaneous 4Dand 5D modelling, their application in practice is limited due to data and disciplinary silos (Mayouf et al., 2019).The use of DfMA offers an opportunity to break the silos as the manufacturing and assembly processes are defined in the design development stage.Unlike how geometric information is kept and represented in BIM models, there is a lack of manufacturing concepts defined in the models, e.g.manufacturing processes in relation to particular modular design, which increases dramatically the data exchange requirements.
Industry Foundation Classes (IFC) (Domingue et al., 2011), a standard platform-neutral schema, is widely used in practice to support representations in semantic web formats (e.g., OWL).However, it does not represent the processes of manufacturing production (Ding et al., 2017).Thus, the use of the IFC schema alone will miss the chance to implement DfMA that requires knowledge representation of the production and assembly attributes as well as cost (Boothroyd, 1994).For instance, setting a competitive price is found as one main challenge for prefabricated house builders (Masood et al., 2021).

RELATED WORKS: ONTOLOGIES AND DATA MODELS
Semantic web technologies allow the development of a formal representation of information, irrespective of the adopted tool.They have been used in the AEC domain for heterogeneous data formats from different sources and domains (Curry et al., 2013), supporting flexible data exchange and distributed data management, and providing a basis for logical inference using rules and ontologies (Pauwels et al., 2017).DfMA in construction has been interpreted from three perspectives: (1) a holistic product design strategy; (2) an evaluation system for the efficiency of manufacturing and assembly process; and (3) prefabrication and modular construction technologies (Gao et al., 2020).To cover the concepts of those three perspectives, as well as the cost analysis, three categories of ontologies have been reviewed, including building design and construction ontologies, production ontologies and cost-estimation ontologies.The limitations of these ontologies for the purpose of DfMA implementation have also been identified.

Building design and construction ontologies
The conceptual schema for IFC is defined using EXPRESS, a data specification language (Patil et al., 2000).Using IFC, data from a BIM model can be exchanged between heterogeneous software applications.However, IFC itself is not a web-compliant standard.The use of semantic web technologies (Grimm et al., 2011), including OWL and the Resource Description Framework (RDF) resolves this limitation and can make IFC data widely available and accessible over the web.The IFC schema has been converted into an ontology in the OWL (i.e.ifcOWL) to make it usable with semantic web technologies.This makes is possible, for instance, to make inferences using Description Logic (DL) rules (Pauwels and Terkaj, 2016).
The latest version of IFC scheme, namely IFC4 consists of 1293 classes and 1572 object properties.The complexity and the counter-intuitiveness with Semantic Web Principles (Pauwels and Roxin, 2016) of this ontology makes reasoning and management very hard and inefficient, and inevitably, increases the need to develop separate modules based on the existing core IFC modules.An implementation of a modular IFC ontology was proposed (Terkaj and Pauwels, 2017) and has initiated several research initiatives, such as the W3C Linked Building Data (LBD) Community Group, that focus on how to modularize the IFC ontology to improve its extensibility.
BIM adoption has been an industrial interest and various countries and communities have their trajectories to map BIM's development (e.g.Digital Built Britain in the UK (Innovate UK and Infrastructure and Projects Authority, 2017)).To support the communication inter-disciplinarily, the domain ontologies for BIM are supposed to be extendable according to the concept of Linked Building Data (LBD) (Werbrouck et al., 2019).In this regard, the Building Topology Ontology (BOT) forms a small part of a broader concept of LBD, in which additional domain ontologies can be proposed to further extend the core of BOT, e.g. with building element classifications and properties.The BOT ontology is adopted to answer the competency questions (CQs) relating to the concepts of Zone, Site, Building, Storey, Space and Elements (Janowicz et al., 2020).Building domain specific ontologies have the capacity to include more building related information.For example, the Building Product Ontology (BPO) aims to describe complex building products with assembly structures and component interconnections.The ontology needs to be extended with more product features to support manufacturing analysis (Cao et al., 2022).
A construction knowledge management ontology, Domain Ontology for Construction Knowledge was introduced in 2013, DOCK 1.0 (El-Diraby, 2013).DOCK 1.0 is a traditional construction management specific ontology that provides defined key concepts in construction (such as actor, resource, product and state).Similarly, the BIM4EE project has very recently proposed digital construction ontologies, DiCon, as shared representations of construction domain knowledge that describes construction activities (Zheng et al., 2021).The aim of DiCon is to integrate heterogeneous construction workflow information to support site management tasks such as assessing site environmental conditions, quality inspection and scheduling of works.Although DiCon has the class of activity and attempts to develop process-based knowledge, the knowledge representation and relationships defined are for the onsite context, which is not suitable for modelling the knowledge for offsite activities.

Production ontologies
The Manufacturing's Semantics Ontology (MASON) is a manufacturing upper ontology that establishes a common semantic vocabulary in the manufacturing domain (Lemaignan et al., 2006).It is organized in three main concepts: Entities, Operations and Resources.Entities give an abstract view of the product in terms of geometric features, raw material and cost entities.Operations describe all processes linked to manufacturing including machining operations, control or assembly and logistic operations, human operations and launching operations as well.Resources classify all resources linked to manufacturing such as geographic resources, machine tools, human resources etc. (Lemaignan et al., 2006).While the ontology is a standard for the manufacturing domain, its application to modular construction products is limited.
Extending from a MASON-based approach, An et al. (An et al., 2019) developed extended ontologies for wood frame assemblies.The authors identified the limitation of using the BIM model alone to explain how wood frame is assembled for production, i.e. it does not include information about how the product is fabricated.Three classes are created, they are product, operation and resource.The ontology developed helps to identify the required manufacturing operations for wood panel frame construction.However, the ontology does not cover the knowledge to perform cost and time estimations and to explain the sequence in which a product is assembled.

Cost estimation ontologies
BIM technologies are used in cost estimation making the cost estimation process more efficient, mainly because standard machine-readable formats can be used in combination with standard measurement methods to automate the construction cost estimation.BIM-based cost estimation tools, such as CostX and BIMMeasure, are designed to streamline the quantity measurement processes, with some degree of automation built-in in those tools.However, data models are not to have process-related data incorporated and thus, those tools have not been developed to be able to populate or extract process related data to facilitate early phase design evaluation.
Differing from traditional approach to estimate cost that demands individual professionals to either measure or extract quantities, link quantities with unit rates and present cost report, the use of ontology can automate the estimation processes.The use of semantic web technologies has been proposed for almost 20 years.However, the existing ontologies for cost estimation are either building component-based (e.g.elemental costing) (Abanda et al., 2011;Staub-French et al., 2003;Zhiliang and Zhenhua, 2012) or resource-based (Lee et al., 2014;Li et al., 2020).Either of them has little account for processes.For instance, Abanda et al. proposed a cost estimating ontology based on the New Rules of Measurement 1 (NRM 1) (Abanda et al., 2011).Its data structure breaks down a building into elements, sub-elements, group elements and components and has NRM 1-based rules of reasoning, to enhance reasoning.Liu et al. (Li et al., 2020) adopted a semantic approach using Autodesk Quantity Take-Off (QTO) and the Revit data model for the preparation of a light-frame building estimate.A constructionoriented product ontology was defined and used to provide an ontology-augmented BIM model in RDF.Neither of the ontologies proposed is suitable for process analysis.Other researchers have looked at more specific problems, such as automating the costing of tiling works (Lee et al., 2014), labour costs (Li et al., 2020) and labour content (Liu et al., 2016).These studies are small in scope, and do not allow for generalisation, especially for modular production concepts in DfMA.

Building design and construction
Product structure Manufacture and assembly process

Research gap
DfMA is aimed to capture the constraints in the manufacturing process in the design process.An ontology for DfMA needs to contain common building vocabularies, offsite activities, manufacturing processes and concepts, and cost aspects.By comparing the existing ontologies (in Table 1), It shows that while existing ontologies capture product concepts, none of them can be applied directly without further ontology development, particularly for most in the aspects of manufacturing processes and concepts.For example, BOT and BPO only capture the building element classifications and properties, but do not include semantics for offsite manufacturing.Also, they are mainly developed to support a product-based or component-based design approach, typically not supporting the consideration of the resources, activities and processes in production directly.DOCK 1.0 and DiCon develop semantics for processes of construction works but are largely based on a site management context.Manufacturingoriented methodologies, such as MASON, fail to capture the richness and complexity of buildings.Finally, existing cost estimation ontologies adopted for producing estimates are building component-based or resource-based rather than process-based.The latter is needed to assess the cost implications for offsite systems, as individual systems have corresponding production methods, which will incur cost differently (Nguyen et al., 2008;Ning et al., 2020).
To overcome the limitations above, a DfMA-specific ontology (i.e.OHO) was developed in this study to represent manufacturing processes as well as the associated cost.Key terms and relationships in relation to production and assembly, are explicitly defined.OHO complements ontology in the building and construction domain by adding new offsite construction knowledge (terminology and relationships), defining specific core vocabulary that can be used in DfMA practice.The developed ontology is further validated in a knowledge-based engineering tool for estimating cost of modular house construction.

Ontology engineering method
The methodology used to design OHO follows best practices for defining such domain ontologies, including the use of competency questions, re-using existing ontological resources (e.g.process maps for production), creating links to other ontologies (e.g.ifcOWL), and using competency questions to assess the ontology.The development of OHO followed the NeOn methodology framework, which is a scenario-based methodology aiming to speed up the development of ontologies through reusing existing ontologies, non-ontological resources and ontology design patterns (Lee et al., 2014).There are various models comprising various phases and scenarios to implement NeOn.The Six-Phase Waterfall Ontology Network Life Cycle Model was chosen as it incorporates 2 phases, i.e. reuse and re-engineering phases that are very relevant to the context of OHO, in addition to the base 4-phase model comprising initiation, design, implementation and maintenance phases.For each phase, NeOn has a number of scenarios (9 in total) for users to define the tasks for individual phases.Fig. 1 shows the phases and the corresponding scenarios chosen according to NeOn framework for OHO development.
A summary of the Ontology Requirements Specification Document (ORSD) was produced (Table 2) in the Initiation phase.Then, an analysis of non-ontological resources such as BIM model, manufacturing process reports etc. was done in the Reuse phase.In the Re-engineering phase, a literature review was conducted on: i) existing ontologies based on IFC; ii) existing ontologies for building design, construction, and related domains; iii) concepts and relations in addition to what was identified in i) and ii).The review identified a lot of shortcomings for DfMA implementation and concluded that the existing ontologies do not represent offsite construction sufficiently.
Then, a set of competency questions were drafted with reference to the guide for developing an ontology from Stanford University (Noy and McGuinness, 2001) in the Design phase.The competency questions guided the discussion with the stakeholders and experts of the offsite house production case involved, who are the architect, the production engineer, site engineer, steel manufacturer, client and cost consultant (Hereafter, the term 'group of experts' is used to refer to this set of respondents).There were 4 rounds of group discussions and a number of one-to-one interviews.The competence questions were identified and agreed with the group of experts in the first meeting.Then, a meeting was carried out to agree on the data structure for the various OHO modules.One to one interviews were then conducted to clarify and confirm the concepts and relationships defined in the ontology individually with the relevant experts that hold the expertise in which OHO attempts to represent.The OHO ontology were then reviewed and refined in the last two group meetings.Finally, the OHO ontology was formalized in a machine understandable format using the OWL language in the Implementation phase.

Table 2: Ontology Requirement Specification Document
Scope: The ontology focuses on the products and components of a modular house designed using DfMA (hereafter named as DfMA house), the process of manufacturing and assembling products, the resources consumed, and their cost and carbon emissions quantitative impact.

Intended Users:
- Ontology Requirements: Group of Competency Questions defined in the OHO Competency Questions section.

OHO OVERVIEW
OHO is a DfMA domain ontology, which complements existing ontologies.It defines a model of categories within the offsite construction manufacturing Universe of Discourse (UoD), plus sufficient knowledge about those categories to allow process reasoning and automatic cost calculation.OHO is intended as a Common Reference (CORE) model for offsite construction.The proposed ontological model is language independent, using the broader term 'terminology' for a semantic model linked to the offsite construction manufacturing domain.
At the core of the OHO ontology, a limited number of very high level concepts is needed, such as OHO:Production.This high-level schema is a prerequisite for good integration with other data models.This principle is similar to the principle behind BOT as a central core ontology (Rasmussen et al., 2017).This OHO core is illustrated in Fig. 2 and it responds to the following requirements: 1) Fits closely with building standards especially in applications for design and manufacturing assembly or in the retrieval and classification of OHO concepts.
2) Sufficiently general to be used in different applications for decision support and interoperability.
3) Formally defined in OWL Description Logic (DL) 4) Acts as a general-purpose modelling language for offsite manufacturing.
5) Supports OWL-DL reasoners to allow core OHO concepts to be combined to create new descriptions of classes and instances constructed according to constraints implemented within the ontology.
6) Supports intuitive and practical collaboration between different groups, being easily understood and application independent.

FIG. 2: Illustration of the OHO core classes
Furthermore, the OHO core has two domains of specialisation, which are presented here as two modules that extend the core, OHO-Pro and OHO-Cost.An ontology module is a reusable component of a larger or more complex ontology (Doran et al., 2007), which is self-contained but has connections and associations with other ontology modules, and can be viewed as an extension of the original ontology (Algergawy et al., 2020).OHO-Pro represents the production module (Production Section), allows the definition of production line data, and imports the OHO core.OHO-Cost, the costing module (OHO Costing Module Section), facilitates the cost estimation of a DfMA house.The OHO-Core, OHO-Pro and OHO-Cost are linked via explicitly defined relations as illustrated in Fig. 2.These ontologies are defined in the namespaces and prefixes listed in Listing 1.
To support the detailed development of OHO, the scope and purpose of the OHO ontology was defined using the following competency questions.
• CQ1: What are production methods for a certain building product?
• CQ2: What are the stations for a production line method?
• CQ3: What are the activities carried out in each station of a production line method?
• CQ4: What type of material is required to produce a product?
• CQ5: What type of labour profile is required to work in each activity?
• CQ6: What is the cost of a DfMA house?
• CQ7: How long does it take to produce a Product / DfMA Product?
• CQ8: What are the components of a Product?
• CQ9: What are the resources needed for the production of a Product?

OHO core module
The OHO core module describes the core parts of a house constructed with the DfMA approach.Given that manufacturing is a major part of DfMA, this core module also includes production line aspects.The main classes of the OHO core ontology are: • oho:House defines the house to be produced and built with the DfMA approach oho:House); • oho:Product categorizes the modular products produced for the scope of the DfMA house (e.g.wall panels are represented as oho:Product); • oho:Component gives the details of finished modular components installed in a DfMA house (e.g.kitchens or bathroom are represented as oho:Component); • oho:Interface is a generic class that defines the type of relationship that connects products or components together; • oho:Production defines the production line that produces an oho:product (e.g.panelized systems are represented as oho:Production);

House
In DfMA the design of the house and its individual components integrates production line concepts.In order to represent this semantically, the oho:House class functions as a central concept, combining all aspects that have to be defined in order for a house to be produced and built with the DfMA approach.The oho:House class can also have the object properties oho:composedOf, pointing either to a oho:Product or oho:Component.

Product
The class oho:Product defines an object that is manufactured in factory using a DfMA production line.The definition of an oho:Product, and associated properties such as its cost, take into account the manufacturing concept of the production line.The oho:Product class is elaborated further with the subclasses such as oho:Pod, oho:Panel and oho:PodFrame.Details of the production line and product attributes are required to describe such a product, using the object property oho:producedBy which relates the product to a oho:Production object.

Component
The oho:Component class represents a part used to compose a house or a product, which is directly procured in a finished state (i.e.outside the DfMA production line), either as discrete components (e.g.windows, doors), or complete modular components (e.g. a kitchen).The subclasses of oho:Component are listed in Table 3 and can be easily expanded given new product design.The composition of a DfMA house can be defined and inferred to a high level of granularity (e.g. up to the level of individual bolts in a connection), using transitive property oho:composedOf between OHO classes.The oho:composedOf property has oho:House and oho:Product classes as a definition domain and oho:Component and oho:Product classes as a range.For example, if a DfMA house is composed of panels, and the panels are composed of studs, windows, studs etc., then it can be inferred that the DfMA house is composed of the window, the studs etc. as well.

Interface
An interface in the OHO ontology represents a physical connection layer between a product and a component, between components or between products.The oho:Interface class allows to define interfaces between products and components as needed.For example the connection points between multiple components of a product (subassemblies) can be represented with an interface.At a higher level, an interface may also be used to define the connections between multiple products in an oho:House.Conceptually, this class draws from the bot:Interface class of the BOT ontology, but adjusted to a DfMA context.Products and components are linked with interfaces using the oho:isInterfaceOf property.The domain of this is an oho:Interface class and the range is defined by oho:Product and oho:Component classes.

Production
The class oho:Production describes the methodology used in producing an oho:Product.As the aim was to develop a modular and extensible ontology, detailed subclasses and object properties were not introduced in the core ontology.Instead, this core ontology was extended with a dedicated ontology aimed at the representation of production methods (Section 5.2).This approach allows: • the use of other ontologies to define production processes, while still relying on the OHO core, • the use of the simpler and more general OHO core in case no production details are present, • management of the OHO Production ontology with appropriate scope and focus.

OHO production module
The

Method
The number and type of stations that constitute a production line are imposed by the production method.For example, a panelised system production line has a different production line compared to a pod system production line.A class oho-pro:Method is therefore defined to reflect the production line method and each method is connected with the different stations needed to complete the production (object property oho-pro:hasStation).However, stations are defined as single instances and can be reused in different methods; e.g. a "Loading Station" can be defined once and the same instance reused in different production methods.A decision was made not to define production sub-methods directly in the OHO ontology.These, however, can be defined as subclasses of oho-pro:Method.

Activity
Capturing the activities that take place in a production line is an important part of a successful representation.The definition of those activities also enables the definition of constraints and checks on these activities.In this regard, OHO clearly divides production processes into activities that produce directly, e.g.oho:CladdingAsssemblyLine, and activities that support production (e.g.loading, packaging and transporting).For example, a cladding assembly line is an automated activity that is defined as a production activity; a constraint placed on it is that it can only start after the frame assembly line has been completed; a property of it is that it consumes labour.The constraints in Listing 2 indicate how such restrictions can be included in the data.
Listing 2: Assembly line definition including constraints that can be set on activities and resources these activities consume.

Station
A oho:Station class defines a work station in the production line which covers CQ2.Each work station performs one or more production activities (e.g., cladding assembly line automation, frame assembly line) and needs time and resources (e.g., labour, material, component, overhead, etc.) to produce a product.These stations perform activities (related to CQ3), and those activities in turn use resources (define in a oho-pro:Resources property) and time (defined in a (oho-pro:hasProcessingTime property -CQ7).These stations are crucial to the production system in the OHO ontology.The resulting structure is shown in Fig. 4.
A method of production (oho-pro:Method) has one or more stations (oho-pro:hasStation) and each station has one or more activities (oho-pro:hasActivity).The last property is used in a property chain axiom that formalises the following transitive relationship: if a method has a station that has an activity, then the method has that activity as well (Listing 3).
Listing 3: Property chain axiom for stations activities and methods represented in Turtle Syntax.
Similarly, a property chain axiom for resources is defined: if an activity performing on a station of a production method uses some resources, then the station where the activity takes place, uses these resources as well (Listing 4).
Listing 4: Property chain axiom about resource activity and station presented in Turtle syntax.

Resource
Resources in OHO are classified in these subclasses: oho-pro:Material, oho-pro:Labour, oho-pro:Plant and ohopro:Overhead.The oho-pro:Material class collects instances that represent the different types of material needed and used for the production of a product such as a wall panel.This class is described in more detail in the following section.The oho-pro:Labour class captures data about the type of labour that is engaged in the production process and is sub categorized as oho-pro:Skilled, oho-pro:SemiSkilled and oho-pro:Unskilled.This categorisation responds to CQ5.Different payment rates can be assigned to different labour types using the ohopro:hasPaymentRate data property and the activity it is allocated to (oho:workingOnActivity) for a specified amount of time.The class oho-pro:Plant gives details about the plants (e.g., movable tools, static tools) used in the production process and oho-pro:Overhead defines activities of type cleaning, security etc.
The oho-pro:Material class defines the types of material used in different activities of the DfMA house production and assembly (related to CQ4).Each material is represented as an instance of this class and is semantically enriched with details for: its cost (oho-pro:hasCost); the source (oho-pro:hasSource) of information such as a reference database of rates; the conversion factor (oho-pro:hasConversionFactor); the quantity of the material (oho-pro:hasQuantity).Cost rates are affected by both the vendor and the time.In order to model this relationship, theoho-pro:hasSource property is used to capture the vendor, and the state property is used to capture the time.The latter is inspired by the OPM ontology (Rasmussen et al., 2019).
A sample list of the directly procured materials for producing a Pod sub-assembly extracted from a BIM model is listed in Table 5.The class oho:Material is useful in many way such as to get information about the material used in producing a product or in cost calculation or estimation.

OHO costing module
While many ontologies in the LBD community are oriented towards the definition of the geometry and semantics of a building or its elements, one of the advantages of the OHO ontology is that it combines this with the capacity to produce cost estimates.The second OHO ontology module that was developed facilitates the cost estimation of a DfMA house (related to CQ6).The main drivers of the cost estimation of a DfMA house (Fig. 5) are defined in the following classes: • oho-cost:BussinesOperation, • oho-cost:DesignAndEngineering, • oho-cost:OffsiteProduction, • oho-cost:Transportation, • oho-cost:OnsiteProduction, • oho-cost:InUse.
The cost estimation for a DfMA house is activity-based, which accounts for the chain of activities in the offsite production.In order to capture this process, the oho:OffsiteProduction class is defined with a high level of granularity and detail.

EVALUATION OF OHO
This a normal text.According to the NeOn methodology, there are three evaluation criteria: i) Domain coverage, ii) Quality of the modeling and iii) Suitability for an application or task.An additional criterion suggested according to NeOn, i.e.Adoption and use, can only be evaluated over time, and thus is excluded from this study.OHO was assessed by the group of experts working in the AEC domain.

Domain coverage
The first version of the ontology was built by extracting knowledge from non-ontological resources and reviewing existing ontologies.Subsequent to the release of the first version, a monthly focus group meeting over an 8-month period with the group of experts were conducted to refine OHO.The domain experts come from a variety of construction sectors, including engineering firms, contractors, manufacturers.The proposed CQs are covered with the ontology.Additional concepts and relationships were defined, ambiguous concepts were clarified, and some terms were amended to facilitate common understanding.The development follows the waterfall approach with each month representing a stage.Table 6 shows the stage of the OHO evaluation and the examples of feedback concluded made for each stage subsequent to feedbacks given in the meeting.

Quality of the modeling
This evaluation criterion assesses the quality of the ontology based on a set of metrics and a list of attributes of the ontology development process.OHO contains 151 classes, with 61 object properties, and 77 data properties.It was tested using Pellet reasoner in Protégé to demonstrate that the schema is consistent.A comparison between OHO and other ontologies is presented later in this article.The following attributes are used to evaluate the ontology development process (Vrandečić, 2009): • Accuracy: The accuracy evaluates whether the ontology capture and represent correctly aspects of the real world.The ontology development process was assisted from the group of experts in the DfMA domain.The processes were supported by highly accurate non ontological resources such as the BIM model among other sources.
• Adaptability: The adaptability evaluates whether the ontology can be extended to offer a conceptual foundation for a range of anticipated tasks.OHO is a modular ontology and each module can be used independently and this provides reusability and extensibility.The OHO-Cost module can be used to estimate traditional construction project as well as offsite construction and OHO-Pro can be reused for other types of production lines.
• Clarity: The clarity evaluates whether the ontology communicate effectively the intended meaning of the defined terms.All the defined terms contain non-ambiguous names and are labelled with definitions and supplementary information to ensure common understanding.
• Completeness: The completeness evaluates whether the ontology defined all competency questions.The OHO ontology can answer all the competency questions defined in the ontology requirement specification.
• Efficiency: The efficiency evaluates how fast can the usual reasoning services be applied to the ontology.Querying the ontology using the SPARQL query language protocol was tested in the Protege framework and in GraphDB1.The queries run in milliseconds in each of these environments. •

Conciseness:
The conciseness evaluates whether the ontology include irrelevant axioms with regards to the domain to be covered.The knowledge modelled in the OHO ontology and its modules was captured from domain trusted sources, i.e. knowledge shared from the group of experts in this case.
• Consistency: The consistency evaluates whether the axioms lead to contradictions (logical consistency).Reasoning based on OHO was performed using the Pellet reasoner2.No inconsistencies were found.

DfMA house wall panels and components of a wall panel
In order to demonstrate the functionality of the OHO ontology, a case study of a DfMA house composed of 32 wall panels was registered by instantiating the ontology.Different queries were executed (such as "what are the components of a wall panel?", "what is the production time?") in order to extract the captured and inferred data.The wall panels were modelled by describing their attributes, and the production line was detailed in terms of the activities required to produce a wall panel (Fig. 6, 7).
All activities are related to each other, they are the first activity (oho:hasStartingActivity), after or before another activity (oho:hasNextActivity) or in parallel to another activity.The knowledge represented in the ontology was used to estimate cost per each activity and the overall cost of producing a sample product (e.g. a wall panel).By estimating the cost per each activity, a designer can get insights about the related activities and the assigned overhead costs.They can revise the design if needed.
The following are example SQWRL (Semantic Query-Enhanced Web Rule Language) queries that were executed with the Protégé 5 SQWRL plugin in relation to our example.The sqwrl prefix is used to denote the SQWRL operator and swrlb for identifying SWRL built-ins.
Q2: What are the parts (related to CQ8) of the product WallPanel01 wall panel?
Listing 6: List of the components of a wall panel.
Listing 7: Starting and upcoming activities for producing a wall panel.

Querying a Pod product
The level of granularity OHO enables many applications, including knowledge extraction using semantic search.Listings 8 to 10 show a number of relevant SPARQL queries to extract knowledge from a pod product.The queries are executed from Protégé 5 Snap SPARQL Query plugin and the inferred knowledge is leveraged, benefiting from the rules used.
Listing 8: Select the list of directly procured material needed for the pod production and their cost.

Cost estimation of DfMA using a semantic rule language
Rules in the form of the Semantic Web Rules Language (SWRL) are used to provide more powerful deductive reasoning capabilities than OWL alone.For example, the rule in Listing 11 enables the calculation of the labour cost.
Listing 11: Labour cost per activity calculated from a SWRL based on the time spent on an activity and the labour rate.
Activities(?a),Labour(?s),hasLabourHrRate(?s, ?r), hasProcessTime(?a, ?p), workingOnActivity(?s, ?a), multiply(?result,?p, ?r) -> hasActivityCost(?a, ?result)Also, a dedicated set of SWRL rules has been created in addition to the presented OWL ontology modules, in order to evaluate their accuracy for cost estimation.A hypothetical project containing the offsite production of 200 houses of different types (i.e.detached, semi-detached and terrace) that uses an automated production method were registered as input to the ontology using the terms of the OHO core, production and cost ontology modules and the full list of requirements defined as shown in Table 7.As the OHO-Cost ontology module applies activity-based costing methodology, all activities are instantiated with their respective cost values.A starting activity is defined (oho:isStartingActivity) and associated with other cost activities using the oho:hasNext property.SWRL rules were set to chain the cost value instances together and at the same time sum them up to an accumulated cost (oho-cost:hasActivityCost) for each activity stage.Furthermore, a final overall inferred estimated cost is calculated at the end of the final activity (ohocost:hasActivityCostFromStart).The rules that support the cost estimation of an offsite housing project are presented in Listings 12 and 13.
Listing 12: Assigning the cost to the starting activity of a process.
hasActivityCost(?a, ?c) ^ isStartingActivity(?a, ?b) -> hasActivity-CostFromStart(?a, ?c) The rule on Listing 12 states that if an activity a is the starting activity of a chain of activities and has a given cost c then the value of oho:hasActivityCostFromStart will be c also.The main purpose of this rule is to initialize the oho:hasActivityCostFromStart data property.
Listing 13: Updating the overall cost estimation after each activity is added.
Rule 3: swrlb:add(?nptd, ?ptd, ?npd) ^ hasNextActivity(?p, ?np) ^ hasActivityCostFromStart(?p, ?ptd) ^ hasActivityCost(?np, ?npd) -> hasActivityCostFromStart(?np, ?nptd) The oho-cost:hasActivityCostFromStart is updated by adding the value of the current cost activity found in ohocost:hasActivityCost.The new value is assigned to the current cost activity ?np and is a result of the cost activity np and the cost carried on the oho-cost:hasActivityCostFromStart property from the start of this chain of cost activities (Listing 13).
Overall, the instantiated cost values along with the SWRL rules, and reasoned by the Pellet reasoner provided exactly the same result with the estimation form a Quantity Surveyor expert.Explanations for the semantic reasoner (e.g., Pellet) inferences is available in the justification of results that is provided as an advanced functionality in Protégé.For the expert that does the evaluation directly using the OHO ontology and the SWRL rules for cost estimations, an ontology-based approach can provide the insight into the reasons behind estimations.
The available explanations can serve as a white-box proof of the results and hence, plays an important role in building trust of OHO.

Validating data integrity with SHACL
OWL and SWRL are based on logic, do not support non-monotonic reasoning and use the OpenWorld Assumption (OWA) where the missing data is assumed as not identified yet.In cases where validating data integrity is crucial, there is a need to use the Closed World Assumption (CWA) in order to notify a constraint violation or take action by adjusting data to a standard format.SHACL shapes is one of the newest technologies that has filled this gap in the Semantic Web architecture stack.Listing 14 shows an example of a SHACL shape for validating the properties (oho:hasHeight, oho:hasWidth etc.) of a oho:WallPanel instance before it goes to production.SHACL validation will ensure that geometric inputs conform to the required standards.
Listing 14: Data integrity validation using SHACL model.

KBE tool development
The OHO ontology was used to implement a Knowledge-Based Engineering (KBE) tool for cost estimation of housing projects using the DfMA approach.The application is implemented according to the Representational State Transfer (RESTful) architectural pattern, with an application programming interface (API) offering intermediary services to other web frontend endpoints and acts as a gateway to the OHO ontology and database servers.A web-based user friendly interface is provided for potential users such as architects, production engineers, structural engineers, steel suppliers, clients and cost consultants, etc.

Input of the KBE tool
DfMA houses are platform-based with standardised design prototypes.To evaluate the cost of a DfMA house, the following input is required: 1) Choice of sub-assembly system 2) Offsite sub-assembly approach 3) Batch size and expected batch delivery period 4) Project site location 5) Project size in terms of house numbers and types of houses 6) Design choice 7) Service installation choices They are defined according to a set of entries in an evaluation form as shown in Fig. 8.The data used are based on a platform-based modular house developed in a UK government funded industrial research project by implementing DfMA design methodology.Detailed information was produced for the construction of a prototype of the modular house.The source of data includes a BIM model in an IFC format as well as cost data sheets and machining process data sheets.Built upon those data input, the KBE tool can be used for the cost estimate (Fig. 9).

Output of the KBE tool
The cost estimation module produces cost estimation as well as the breakdown of the costs.In addition to the overall cost estimations, there are 4 levels of breakdown: activity group, activity, sub-activity, and resource.As the focus of the prototype is on Manufacturing and Assembly, all four levels of breakdown are available for the activities in relation to the manufacturing and assembly processes.The estimations and breakdown are shown in an interactive dashboard for the ease of visualisation.A screenshot of the dashboard is shown in Fig 10.

KBE Architecture
The KBE tool architecture (Fig. 11) is designed with the capability to integrate and process heterogeneous data formats and to accommodate semantic web and web technologies.At the core of it is a Knowledge Graph defined as a knowledge bases that store factual information in form of relationships between entities (Nickel et al., 2016) described with formal semantics of OHO.

FIG. 11: Web-Application Architecture
The Data layer stores different file formats that contain information used for cost calculation, such as BIM model in IFC format of the house, productivity datasheets, and other sources of information.The Transformation Layer parses the different data sources and transforms the relevant information into the RDF format.At this stage the data is fed into the DfMA Knowledge Graph and is semantically described with the OHO ontology concepts and relations creating a DfMA Knowledge Graph.The OWL API (Horridge and Bechhofer, 2011) library is used to facilitate the conversion of these semi structured data to a LBD format.The SPARQL query protocol or other Query API serves as an intermediate layer between the user Application layer and the other layers of the architecture.The user sends queries by entering filtering information and receives a visualized response.

Validation of the KBE tool
The KBE tool were validated by replicating the relationships in an Excel spreadsheet by the quantity surveyor as it is one come method that quantity surveyors use in practice to estimate building costs in the design cost.The estimates of >20 cases, based on random inputs of the evaluation form, were found to be identical to the output of the cost estimates from the KBE tool suggesting that the relationships in the tool were represented correctly.Since there is no cost data base available for light weight modular houses to compare against the outputs of the KBE tool, the accuracy of estimates can only be verified based on whether it is within the modular contractor's anticipation of the costs.Table 8 shows a set of estimated outputs for the KBE Tools.The estimates are within the range expected by the modular contractor.

CONCLUSION AND DISCUSSIONS
A new domain specific ontology, OHO, was designed and validated to represent and bring together disparate and isolated knowledge and data from various fields.The main contribution of the paper is the very detailed ontologies developed for offsite house construction that supports building design using DfMA.The concepts and relationships defined particularly about the production and costing enable users to retrieve knowledge that can support DfMA design.The use of it is demonstrated from the answers to the competence questions as well as the KBE cost estimation tool.
OHO expanded the existing building and construction ontology and used a real-life use case production lines to test and demonstrate the benefits of the semantic digital twin in obtaining data of the manufacturing for assessment.Analysing the specifics of the production processes we identified the need for OHO to grow as a separate domain ontology.Naturally, many aspects of a completed DfMA project, such as the building geometry or the material properties, can be represented accordingly.However, as a process with roots in industrial engineering, DfMA engages more with procedural and optimisation aspects, and introduces concepts, such as "assembly" or "subassembly", with different semantics from current BIM and construction technology practice.As such, a separate ontological domain was considered necessary in order to avoid semantic and ontological conflicts, as well as to implement DfMA concepts appropriately.Ideally, OHO is able to facilitate a two-way conversation: enable AEC practitioners to apply DfMA design concepts in a BIM workflow, while simultaneously acting as an introduction to the DfMA concept for BIM-literate AEC practitioners.Furthermore, such modular extension approach also entirely fits the recommendations put forward by the W3C Linked Building Data Community Group, as well as linked data communities at large.By aiming at a separate domain, such recent research initiatives are followed and implemented, thus moving away from a monolithic ontology approach.Attempting to capture all possible aspects of a building (or any other concept) in a single ontology, mapped to a super-schema, has innate limitations and lacks the flexibility to accommodate different design concepts (i.e.extensibility).DfMA is the future innovative philosophies and practices for construction.It is likely to face similar challenges in BIM implementation.
The OHO ontology can be aligned with the IFC ontology by asserting that every oho:Building is an IfcBuilding and every oho:Product is an IfcProduct.An exploitation of OHO alignments with other standardised AEC ontologies such as BOT ontology are made such as an alignment in the instance level i.e. a DfMA product such as Pod (oho:Product) is a bot:Element and a DfMA house (oho:House) is a subclass of a bot:Building.The current version of OHO can be added as a module of a standardised ontology, and to make links on instance level (for web of linked data).A formal alignment approach will be developed further after OHO reaches a more mature stage.The instance linking proposed in the paper is recommended as a priority over more stringent ontology alignments due to practical implementations and research initiatives.
There are many directions that the base OHO ontology can be expanded to or used for when building DfMA applications.For example, in this paper, the OHO core semantic model was applied to develop the production and costing modules for cost estimation tool.The use of the OHO ontology has also been experimented in different environments in order to accommodate diverse users' needs with varying levels of knowledge of the underlying semantic web technology including some users with a computer science background and most from the AEC community.Users with knowledge of using an ontology editor (e.g., Protégé) are able to directly interact with the semantic model, while less experienced users required a frontend application that uses an API (e.g.OWL API) to connect with the OHO ontology as discussed in the OHO Evaluation Section.
A deep analysis of the best approach to follow in terms of efficiency, complexity and ease of use will be part of future works.Finally, the OHO ontology paves the way to the implementation of Digital Twins that integrates production information of houses with BIM models.Future developments of this work will focus on further iterations of the OHO ontology development life cycle, by expanding and improving the ontology based on more cases of production processes for offsite construction.
1: Cost estimation (demonstrated in this paper) -Use Case 2: Life cycle carbon emissions (future work) -Use Case 3: Semantic digital twin of DfMA (future work) -Use Case 4: Time monitoring using sensor information (future work) -Use Case 5: Production waste classification (future work) FIG. 3: Illustration of the oho:Production class, its subclasses and examples of instances e.g.static method as an instance of the class oho-pro:Method5.2.1 Production lineThe oho-pro:Method gives a semantic description of a production line.It is composed of station (oho-pro:Station) and assigned to a oho:Product via a oho-pro:hasMethod.The semantic information is used to answer CQ1.Table4shows a number of classes available in the OHO Production ontology, with corresponding real-world examples (i.e.implementation instances).This clearly indicates that a lot of diversity is present in stations, production lines, components and activities.Table 4: OHO taxonomy of major elementary categoriesEntity Production Station Example of Activity Cladding-Assembly-Line CP-Boarding-Station T10-Frame-transfer T11-Load-and-Place-CPB T12-Mechanical-Fixing Adhesive-Station T31-Feed-Adhesive T32-Dispense-Adhesive Briquette-Apply-Station T35-Place-Briquettes Briquette-Load-Station T34-Feeding-Briquettes shall include company's overhead and design cost for modular unit and prototypes.-Theterm "Specifiers" were used instead of "developer" as a module construction decision can be made by clients who are a private developer, housing association or contractor.--Intendeduse can include development of semantic digital twin, time monitoring and production waste in addition to cost and carbon footprint as originally planned.ii)Determine ontology competency questions (CQs) -Competency questions set shall be about production as the core focus of the ontology is production iii) Clarify and confirm the concepts and relationships in the ontology -The production method (i.e.oho-prod:Method) shall include 4 types of methods, i.e. static method, panelised method and 2 types of volumetric methods instead of 1. iv) Review and refine the ontology -Quality-Inspection is added as a supporting-activity v) Develop the KBE tool --Interactive pie charts are preferred or other chart types to present the breakdown.% and cost of components are shown when the cursor is put on the segment of the pie chart.vi) Test KBE tool by use cases -No adverse comments were received for the alpha and beta versions of the tool vii) Evaluate the KBE tool -Estimate of the cost are found to be viii) Provide documentation for the KBE tool -A report of the KBE tool was produced and agreed by the experts

Table 3 :
A list of the subclasses of oho:Component class

Table 5 :
Directly procured material for Pod sub-assembly Listing 9: Select the method of production for pod frame therefore the stations and activities.

Table 7 :
Project requirement specification

Table 8 :
Estimated Design and Construction Costs based on various inputs in the Evaluation Form