Ontology for Construction Quality Assurence (OCQA)

Metadata

URI

https://w3id.org/ocqa#

Creator(s)

Sebastian Seiß

Modified

2024-03-18

Issued

2022-01-01

Imports

http://w3id.org/digitalconstruction/0.5/Units
https://w3id.org/digitalconstruction/0.5/Information
https://w3id.org/ocqa/catalog
https://w3id.org/ocqa/contract
https://w3id.org/ocqa/regulation
https://w3id.org/ocqa/rule

License

https://creativecommons.org/licenses/by/1.0

Ontology RDF

RDF (turtle)

RDF (jsonld)

Description

Table of Contents

1. Overview
2. Specification
3. Modules
4. Classes
5. Object Properties
6. Datatype Properties
7. Annotation Properties
8. Named Individuals
9. Namespaces
10. Legend

Overview

This document provides a description of the Ontology for Construction Quality Assurance (OCQA), which is designed to represent explicit knowledge about the domain of quality inspection planning. The ontology is intended to provide a standardized vocabulary for describing concepts, entities, and relationships relevant to inspection planning in construction execution. It is based on a set of axioms that define the properties and relationships of the concepts within the ontology. This document includes an overview of the ontology structure, the types of entities and relationships represented, and the intended applications of the ontology. It also provides guidance on how to use and extend the ontology, and describes the processes used to develop and maintain it. The development of the OCQA follows the Linked Open Terms (LOT) methodology and is encoded using Semantic Web Ontology Language (OWL) to ensure machine-readability and alignment with other ontologies. According to LOT, we provide the ontology requirements specification document (ORSD), which can be found in the specification section. The OCQA is evaluated using various approaches, including automatic consistency checking, competency questions, criteria-based evaluation, and focus group interviews.

The OCQA is based on four modules to fully describe the required data (see Figure below). Each of these modules reflect construction domain knowledge that is directly related to the OCQA and thus to inspection planning. In particular, DiCon is reused in the OCQA as a module to provide the basic terminologies and concepts related to construction execution, as shown in Figures 4 and 6. DiCon is a higher-level domain ontology that generically represents construction workflow knowledge with related entities and properties. The DiCon ontology contains basic concepts for describing components, construction activities, materials, agents, and more. For example, the goal of an inspection can be related to a component, activity, or person, thus satisfying the high variance of inspections and possible inspection characteristics. Furthermore, DiCon has built alignments with existing relevant ontologies that enable the direct integration of heterogeneous systems in the construction domain. For example, DiCon has aligned with ifcOWL and BOT to integrate building information models, organizational descriptions, and schedules. DiCon is implemented in the OCQA as hard reuse via owl:imports, which reuses the imported ontology as it is and as a whole. In turn, the OCQA is itself an extension of the DiCon ontology. The OCQA-Catalog module is used to store quality-related information. The catalog module contains parameters about failure probabilities, performance and cost rates, which can be used for example to estimate costs and durations of inspections. The OCQA-Regulations module is used to store the corresponding norms, guidelines and standards, to which inspections or contracts refer. Contracts are described via the OCQA-Contract module.

To keep the ontology lean and flexible, inspection-specific contents of the inspection planning were modeled as extensions according to their trade-specific terminology. These extensions specify the classes of the OCQA to fit their trade-specific terminology. The extensions are not limited to the OCQA but can also be applied to modules like trade-specific regulations or catalogs. The extendibility of the ontology enables the use of the OCQA in different contexts and the customization of the ontology depending on the needs of a project. The extensions can be added to the ontology as needed, for example, to add the trades that are required for the construction project or that are covered by a construction company. Moreover, the modularization into trades not only simplifies the further development of the ontology, allowing different users to extend it, but also paves the way for an expansive compilation of diverse trades.

Figure 1:Overall architecture of OCQA

Specification

The objective of this section is to provide a formal specification document utilizing competency questions (CQs) as requirements. The CQs are extracted from use cases, which are based on the intended purpose and scope of the relevant ontology during the specification process. The subsequent table represents the ontology requirements specification document (ORSD), which provides all results of the specification process.

Modules

OCQA - Core module

Building upon this foundations Figure 6 illustrates a simplified structure of the proposed concept of the OCQA, with the class ocqa:Inspection in the center. The OCQA is designed to represent detailed inspection plans. Therefore, the OCQA represents inspections and associated entities of an inspection, like inspection equipment, inspectors, inspection objects, and inspection methods in detail. An inspection is designed as a subclass of dicp:Activity in the OCQA. For this reason, an inspection can be assigned a start and end date as well as a duration according to the activity.

The approach to model an inspection as an activity enables a deep integration of the inspections into the construction process including the schedule and the alignment with various entities of the construction process itself. Construction related entities are represented by the DiCon ontology and their alignments. Together with the contract, regulation and catalog module the OCQA provides all relevant inspection planning information. In addition, this enables the inspection planners to describe planned inspections in detail and answer all the required W-Questions.

Likewise, entities to be inspected, such as dice:Location, dice:BuildingObject or dicp:Activity can be assigned. The objective of an inspection can be any entity, which includes several characteristics to be inspected. For this reason, the inspection refers not only to the entity to be inspected but also to the inspection characteristics of the entity itself. The inspection characteristics are modeled as ocqa:Characteristic and are aligned to the object being inspected as well as to the inspection itself. The class ocqa:Characterisitc refers to an ocqa:AssignedCharacteristicValue as a requirement to be achieved and an ocqa:ActualCharacteristicValue as a determined actual value. Accordingly, the ocqa:AssignedCharacteristicValue can be used as a direct comparison value to determine the conformance of the object regarding the inspection characteristic. The assigned characteristic value is required by regulations like norms or any other entity defining specific requirements for the object in question. Following the structure, the comparison of the assigned and actual characteristic can be done by standardized rules using a query or rule language.

Figure 2: Illustration of the core module

Catalog module

To support the inspection planning process with essential data and knowledge, a catalog module is developed. The master data comprises, for example, information on failure probabilities, performance rates for inspection execution, and cost rates for failures or inspections. The feature catalog module is able to describe several master datasets that are integral to inspection planning. The values of these master datasets are stored as ocqa-cat:Features in a data catalog and are linked to ocqa:Inspection or other classes via ocqa:hasFeature (see Figure 7). To provide fitting value relations, ocqa-cat:hasFeature can be specialized by sub-properties, such as ocqa-cat:hasFailureProbabilityFeature to describe the failure probability of an inspection. The features are stored in the catalog called ocqa-cat:SubFeatureCatalog, which is defined as a dataset of ocqa-cat:FeatureCatalog. The ocqa-cat:Feature represents a subclass of opm:Property and can therefore be updated with actual costing values according to the Ontology for Property Management (OPM). The catalogs are designed according to the Data Catalog Vocabulary ontology and can be differentiated into a main catalog and a sub-catalog. Resulting estimations for costs or time efforts based on features can be aligned to inspections via a direct property.

Figure 3: Illustration of the catalog module

Contract module

The contract module will handle individual contracted quality requirements. Individual quality requirements are contractually agreed upon directly between the project participants via individual contract components. These requirements extend or reduce the general contracted quality requirements, which are contract regulations that set only the minimum quality requirement. The agreed contractual terms not only define the quality requirements but also specify inspections to be performed. The tasks of the contract module are to support the planning of inspections and to refer planned inspections to the specified inspection requirements defined in contractual documents. The contractual module is therefore based on several classes, as illustrated in Figure below.

performance description occurs via a functional performance description or a BOQ. Accordingly, ocqa-con:FunctionalPerformanceDescription and ocqa-con:BOQ are modeled as subclasses of ocqa-con:PerformanceDescription. The BOQ is defined as a structured description of required work by a set of ocqa-con:BOQItems, including a number, description, quantity, unit, and price. Both BOQs as well as functional performance descriptions can directly require inspections, which is considered by the relation ocqa-con:requiredby. Further contractual components that have to be considered in inspection planning are ocqa-con:GeneralTerms and ocqa-con:GeneralTechnicalTerms.

Figure 4: Illustration of the contract module

Regulation module

To handle inpsection planning knowledge provided by norms, standards, and guidelines we provide the regulation module. The regulation module is used as a reference for all kind of rules relevant for inspection planning. It does not matter, if this rules are provided by company internal standards or guidelines or by external organisations like DIN or ISO.

Norms, standards, and guidelines are modeled in the OCQA as a regulation module to provide knowledge of norms and standards for inspection planning. A norm is based on the consensus of experts participating in a norming process. On the other hand, a standard refers to the standardization of dimensions, types, procedures, and other factors without necessarily being based on a set of rules, a consensus, or a specific procedure. A further aspect that has to be considered in the planning of inspections is manufacturer guidelines, which also provide detailed requirements for the product and inspection tasks. Moreover, company-specific guidelines can be represented in the ontology to ensure a comprehensive mapping of possible sources of rules described in the rule module. Regulations are represented by the class ocqa-reg:Regulation and the subclasses ocqa-reg:Norm, ocqa-reg:Standard, and ocqa-reg:Guideline (see Figure 4).

Rule module

The rules module accommodates different types of inspections, which 1) check the consistency of input data for inspection planning, 2) perform inspection planning, and 3) validate planned inspections. These rules share a common goal of supporting the inspection planner in the inspection planning process. It is important to note that the described use cases for inspection planning are not exhaustive and can be expanded to include compliance checks if necessary.

The rule module is remodelled according to the rule ontology illustrated by Zheng 2022. The rules are represented by the class ocqa-rule:Rule and are linked to the dice:Entity through the object property ocqa-rule:inferredBy (see Figure 5). This relationship ensures that each subclass of dice:Entity such as ocqa:Inspection, dicp:activity, ocqa:InspectionEquipment or ocqa:InspectionProcedure can be inferred by a rule. This distinction allows rules to be categorized based on the inspection characteristics, which have to be planned by the rules, as described earlier.

The rules are linked to a SHACL shape, which defines the content of a rule using either a sh:NodeShape or a sh:PropertyShape. In SHACL, a NodeShape is a type of shape that focuses on validating individual nodes in an RDF data graph. When a target class is associated with a NodeShape, it means that the constraints defined within that shape apply only to instances of the specified target class, including any subclasses of dice:Entity. A PropertyShape, on the other hand, focuses on validating the values of a specific property for a node in an RDF data graph. The properties to get validated are defined as dicv:Property and are related to the dice:Entity. The rules themselves are defined based on regulations, represented by ocqa-reg:Regulation. The connection between a rule and a regulation is necessary to describe the rule's source and to identify all rules that must be applied due to contractual constraints.

In addition, the rules within the system can be categorized into two types: generic rules and specific rules, denoted as ocqa-rule:GeneralRule and ocqa-rule:SpecificRule respectively. Generic rules are designed to guide the planning of inspections for specific classes of inspections. An example of a generic rule is setting the earliest start or end time for an inspection. Another instance is the automated generation of geometric inspections based on the information extracted from the BIM model. On the other hand, specific rules are tailored to address explicit requirements derived from the contract or regulations module. For instance, a specific rule may dictate that the evenness of a screed must be assessed prior to installation. For further classification of the rules, subclasses according to the task of the rule are defined like ocqa-rule:InspectionPlanningRule, ocqa-rule:InspectionPlanningEvaluationRule and ocqa-rule:InspectionEvaluationRule. Furthermore, the rules have additional information about the creator via dice:Agent, the version of the rule using ocqa-rule:hasVersion and the creation date of the rule using ocqa-rule:HasCreationTime.

Figure 5:Screed-specific extension of the OCQA by subclasses.

Trade-specific extensions

Task-specific inspection planning is covered by trade-specific extensions of the OCQA ontology. For example, the extension OCQA-screed covers all inspections regarding the trade screed. The extensions are defined in separate OWL-Ontologies, such as OCQA-Screed for the trade screed or OCQA-Insulation for insulation trades. To ensure compatibility with the OCQA, these ontologies have to be aligned with the OCQA core and modules. The extension is done by using rdfs:subClassOf to expand the generic classes of OCQA and its modules for trade-specific use cases. An example of the extension for screed and insulation is given in Figure 6. The use of extensions enables improved reusability of the ontology as it becomes easier to share and extend trade-related knowledge between users. Furthermore, the complexity of the ontology is reduced since only the trades necessary for the user have to be represented in the ontology.

Figure 6:Screed-specific extension of the OCQA by subclasses.