made by pyLODE 2.13.2

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.

Italian Trulli
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.

Table 1:Ontology requirements specification document (ORSD)of OCQA

Ontology Requirements Specification Document

1

Purpose

 

The purpose of the OCQA is to provide a structural basis for representing project-specific inspection plan in construction execution and to support decision making in the process of inspection planning. The objective is to ensure a transparent, objective, and rule-based process for assigning building permit applications. The ontology will support civil engineers in gaining a better understanding of inspection plans. Accordingly, the ontology will provide terminology and semantics to describe inspections and inspection planning knowledge.

2

Scope

 

The OCQA aims to represent inspections and inspection plans in construction, applicable across various trades in the construction domain. The terminology conforms to DIN 55350, ISO 9000, and ISO 9001 standards. It encompasses inspections and related entities such as agents, equipment, procedures, norms, costs, instructions, and failure probabilities. The ontology is therefore designed as a domain-specific model, aligning both construction-specific and high-level ontologies to provide comprehensive knowledge representation about inspection-related entities. Furthermore, the OCQA integrates heterogeneous data from multiple knowledge domains, ensures the consistency of inspection plans, facilitates inspection coordination within a company or project, and enables information exchange among relevant parties.

3

Implementation Language

 

The implementation language for the OCQA is OWL for the T-Box and SHACL for business rules (i.e., the R-Box). This approach provides the necessary flexibility and expressiveness for modeling the complex relationships between building permit authorities, building officials, and building applications. The OCQA is operating bilingually in English and German.

4

Intended End-Users

 

The primary end-users of the OCQA ontology are stakeholders in the construction execution process and work preparation, including construction managers, experts, architects, work planners, foremen, construction workers, and suppliers. These users interact with the ontology indirectly through a software application, which serves as a user-friendly interface. Developers will directly use the OCQA as a substructure for programming software applications, enabling the storage and processing of inspection data from heterogeneous sources.

5

Intended Uses

 

The OCQA is used to support the following use cases:

  1. Description of inspection plans and relevant information
  2. Provision of knowledge to support decision making in the inspection planning
  3. (Semi-)Automated planning of inspections

6

Ontology Requirements

 

  1. Non-Functional Requirements

 

In addition to these use cases, the following nonfunctional requirements have been identified as crucial for the OCQA:

  1. Coverage and sufficiency
  2. Consistency
  3. Usability
  4. Clear and concise terminology
  5. Reusability and extensibility
  6. Reliability and transparency
  7. Modularity
  8. Adherence to the FAIR principles (Findable, Accessible, Interoperable, and Reusable)

 

  1. Functional Requirements: Lists or tables of requirements written as Competency Questions (CQs) 

 

Use Case 1: Description of inspection plans and relevant information

  1. What are the characteristics being inspected?
  2. What type of inspection is it?
  3. What are the related entities of an inspection?
      1. What inspection procedure is used?
      2. What inspection equipment is required for the inspection?
      3. Where is the inspection located?
      4. What agent processes or has processed the inspection?
      5. Which company hires the person who is responsible for the inspection?
      6. Does the responsible person has the required skills to execute the inspection?
      7. Why is the inspection required?
      8. How often does the measurement of the inspection have to be done?
  4. What is the start and end date of an inspection?
  5. How are inspections interlinked in an inspection plan and interlinked with the construction schedule?
      1. What construction activity is related to the inspection?
      2. What is the preceding/following construction activity of the inspection?
      3. What is the precding/following inspection of the inspection?
      4. Which inspection can be done on a specific point of time?
      5. What will be the best time point to do as many inspections in one site inspection?

 

Use Case 2: Providing knowledge to support decision making in inspection planning

  1. Which inspection types can be assigned or are required by an activity, building object, or location?
  2. Which entities are required for an inspection type?
  3. What are the time constraints of an inspection type?
  4. Which inspection characteristics can be inspected by an inspection type?

 

Use Case 3: (Semi-)Automated planning of inspections

  1. Which inspection should be done for the specific construction project (considering different information like schedule, contract, design (BIM), construction equipment, norms and standards)?
  2. When should the inspection start and end?
  3. What should be the frequence and scope of the inspection?
  4. Who should process the inspection?
  5. Which inspection procedure and equipment should be used to execute the inspection?

 

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.

Italian Trulli
Figure 2: Illustration of the core module

Catalog module

Prefix:ocqa-cat; Namespace:https://w3id.org/ocqa/catalog

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.

Italian Trulli
Figure 3: Illustration of the catalog module

Contract module

Prefix:ocqa-con; Namespace:https://w3id.org/contract

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.

Italian Trulli
Figure 4: Illustration of the contract module

Regulation module

Prefix:ocqa-reg; Namespace:https://w3id.org/ocqa/regulation

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

Prefix:ocqa-rule; Namespace:https://w3id.org/ocqa/rule

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.

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

Trade-specific extensions

Prefix:ocqa-screed; Namespace:https://w3id.org/ocqa-screed Prefix:ocqa-insulation; Namespace:https://w3id.org/ocqa-insulation

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.

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

Classes

Propertyc # Classes

URI http://w3id.org/seas/Property
Sub-classes Characteristicc

Equipmentc # Classes

URI https://w3id.org/digitalconstruction/0.5/Entities#Equipment
Sub-classes MeasuringEquipmentc
InspectionEquipmentc

Objectc # Classes

URI https://w3id.org/digitalconstruction/0.5/Entities#Object

Occurrentc # Classes

URI https://w3id.org/digitalconstruction/0.5/Entities#Occurrent
In domain of succeedop
simultaneop
In range of succeedop
simultaneop

Activityc # Classes

URI https://w3id.org/digitalconstruction/0.5/Processes#Activity
Sub-classes Determinationc
In range of hasActivityTypeop

actual characteristic valuec # Classes

URI https://w3id.org/ocqa#ActualCharacteristicValue
Super-classes https://w3id.org/digitalconstruction/0.5/Variables#PropertyStatec
In range of hasActualCharacteristicop

characteristic valuec # Classes

URI https://w3id.org/ocqa#AssignedCharacteristicValue
Super-classes https://w3id.org/digitalconstruction/0.5/Variables#PropertyStatec
In range of hasAssignedCharacteristicValueop

Causationc # Classes

URI https://w3id.org/ocqa#Causation
In range of hasCausationop

Characteristicc # Classes

URI https://w3id.org/ocqa#Characteristic
Description

characteristic, en: characteristic characteristic property Note 1 to term: A characteristic may be inherent or associated. Note 2 to concept: There are Quantitative Characteristics (3.4.1.5) and Qualitative Characteristics (3.4.1.9). NOTE 3 to the term: there are different classes of characteristics, e.g.: a) physical (e.g. mechanical, electrical, chemical or biological characteristics); b) sensory (e.g. relating to smell, touch, taste, sight, hearing); c) behavioral (e.g. courtesy, honesty, sincerity); d) time-related (e.g., punctuality, reliability, availability, continuity); e) ergonomic (e.g., physiological or human safety-related characteristics); f) functional (e.g., top speed of an aircraft). [SOURCE: DINENISO 9000:2015-11, 3.10.1, modified - Note 2 reworded]

Super-classes opm:Propertyc
https://w3id.org/digitalconstruction/0.5/Variables#Propertyc
http://w3id.org/seas/Propertyc
Sub-classes quantitative characteristicc
qualitative characteristicc
In domain of hasAssignedCharacteristicValueop
hasActualCharacteristicop
In range of hasCharacteristicop

Conformityc # Classes

URI https://w3id.org/ocqa#Conformity
Super-classes Documentationc
Evaluationc

ConstructionProcedurec # Classes

URI https://w3id.org/ocqa#ConstructionProcedure
Super-classes procedurec

Damagec # Classes

URI https://w3id.org/ocqa#Damage
Super-classes Nonconformityc

Defectc # Classes

URI https://w3id.org/ocqa#Defect
Super-classes Nonconformityc

Determinationc # Classes

URI https://w3id.org/ocqa#Determination
Super-classes dicp:Activityc
Sub-classes Monitoringc
ProgressEvaluationc
Reviewc
Testc
Measurementc
Inspectionc
In domain of hasStatusdp

Evaluationc # Classes

URI https://w3id.org/ocqa#Evaluation
Sub-classes Conformityc
Nonconformityc
In domain of hasCausationop
hasDocumentationop
In range of hasRecordop

ExternalResourcec # Classes

URI https://w3id.org/ocqa#ExternalResource
Description

An external resource is linked via a URI.

Super-classes Documentationc
In domain of filePathdp

Failure Categoriec # Classes

URI https://w3id.org/ocqa#FailureCategories
Description

These error categories describe possible errors that may occur in a component.

In range of detectop

Imagec # Classes

URI https://w3id.org/ocqa#Image
Super-classes Documentationc

Inspectionc # Classes

URI https://w3id.org/ocqa#Inspection
Super-classes Determinationc
In domain of hasRecordop
hasInspectionProcedureop
hasDocumentationop
hasCharacteristicop
accepteddp
appraisal costsdp
In range of hasInspectionop

InspectionEquipmentc # Classes

URI https://w3id.org/ocqa#InspectionEquipment
Super-classes dice:Equipmentc

InspectionPlanc # Classes

URI https://w3id.org/ocqa#InspectionPlan
Description

Inspection plan

Super-classes Planc

InspectionProcedurec # Classes

URI https://w3id.org/ocqa#InspectionProcedure
Description

The knowledge of a testing procedure is represented by a rule. The rule thus corresponds to a procedural instruction from which the individual test results.

Super-classes procedurec
In domain of hasInpsectionPerUnitdp
detectop
hasRequiredQualificationop
hasInspectionIntervaldp
In range of hasInspectionProcedureop

Inspectorc # Classes

URI https://w3id.org/ocqa#Inspector
Super-classes https://w3id.org/digitalconstruction/0.5/Agents#Personc

Measurementc # Classes

URI https://w3id.org/ocqa#Measurement
Super-classes Determinationc

MeasuringEquipmentc # Classes

URI https://w3id.org/ocqa#MeasuringEquipment
Super-classes dice:Equipmentc

Monitoringc # Classes

URI https://w3id.org/ocqa#Monitoring
Super-classes Determinationc

Nonconformityc # Classes

URI https://w3id.org/ocqa#Nonconformity
Super-classes Documentationc
Evaluationc
Sub-classes Defectc
Damagec

Planc # Classes

URI https://w3id.org/ocqa#Plan
Sub-classes InspectionPlanc

procedurec # Classes

URI https://w3id.org/ocqa#Procedure
Description

The term "procedure" refers to the "specified way to carry out an activity or a process"

Sub-classes InspectionProcedurec
ConstructionProcedurec
In domain of hasActivityTypeop
hasProcedureDescriptiondp

ProgressEvaluationc # Classes

URI https://w3id.org/ocqa#ProgressEvaluation
Super-classes Determinationc

Protocolc # Classes

URI https://w3id.org/ocqa#Protocol
Description

Derived from a SHACL rule using DASH functions.

Super-classes Documentationc

qualitative characteristicc # Classes

URI https://w3id.org/ocqa#QualityCharacteristic
Description

Characteristic (3.4.1.1) whose values are assigned to a scale (3.4.1.4) on which distances are not defined. Note 1 to the term: this scale is called "Topological Scale". See also Section A.7. Note 2 on the term: It may be useful to identify characteristic values of Qualitative Characteristics with a key number, i.e. with numbers. However, this does not assign a scale to the values of this Qualitative Characteristic on which distances are defined. The qualitative characteristic is therefore not converted into a quantitative characteristic by numbering the characteristic values.

Super-classes Characteristicc

quantitative characteristicc # Classes

URI https://w3id.org/ocqa#QuantitativeCharacteristic
Description

Quantitative characteristic: characteristic (3.4.1.1) whose values are assigned to a scale (3.4.1.4) on which distances are defined. Note 1 to the term: This scale is called: "Metric scale" or "Cardinal scale". On it either only distances are defined ("interval scale") or additionally also ratios ("ratio scale"). For example, on the Celsius temperature scale, only distances are defined, while on the Kelvin temperature scale, ratios are also defined. See also section A.7. Remark 2 to the term: According to the value range of characteristics (3.4.1.3), Continuous Characteristics (3.4.1.6) and Discrete Characteristics (3.4.1.7) are distinguished. Note 3 to term: A Quantitative Characteristic can be transformed into a Qualitative Characteristic by determining only whether the actual value lies within a specified range of values (which belongs to the value range of the characteristic (3.4.1.3)). Note 4 to the term: The value of a quantitative characteristic is expressed as the product of a numerical value and a unit (e.g. SI unit, currency unit, see also DIN 1301-1:2010-10) (see DIN 1313:1998-12). Note 5 to the term: tative characteristics.

Super-classes Characteristicc

Documentationc # Classes

URI https://w3id.org/ocqa#Record
Sub-classes Protocolc
Imagec
Conformityc
Nonconformityc
Videoc
ExternalResourcec
Resultc
In range of hasDocumentationop

Resultc # Classes

URI https://w3id.org/ocqa#Result
Super-classes Documentationc

Reviewc # Classes

URI https://w3id.org/ocqa#Review
Super-classes Determinationc

Samplec # Classes

URI https://w3id.org/ocqa#Sample
Super-classes owl:Thingc
In range of hasSampleop

Testc # Classes

URI https://w3id.org/ocqa#Test
Super-classes Determinationc

Videoc # Classes

URI https://w3id.org/ocqa#Video
Super-classes Documentationc

CostFeatureCatalogc # Classes

URI https://w3id.org/ocqa/contract#CostFeatureCatalog
Description

The CostFeatureCatalog is a catalog that encompasses various parameters or features related to costs in the context of quality assurance in construction execution. This can include costs for materials, equipment, man-hours, and other relevant aspects. The purpose of this catalog is to provide a structured and organized collection of cost parameters that can be used for accurate calculation and planning in construction projects.

Super-classes ocqa-con:FeatureCatalogc

FailureProbabilityCatalogc # Classes

URI https://w3id.org/ocqa/contract#FailureProbabilityCatalog
Description

The FailureProbabilityCatalog is a catalog containing various parameters concerning the probability of errors or failures in the quality assurance of construction execution. This might relate to the likelihood of specific materials failing or the efficiency of particular construction methods. The goal of this catalog is to better assess and minimize risks.

Super-classes ocqa-con:FeatureCatalogc

FeatureCatalogc # Classes

URI https://w3id.org/ocqa/contract#FeatureCatalog
Sub-classes ocqa-con:TimeRateCatalogc
ocqa-con:CostFeatureCatalogc
ocqa-con:FailureProbabilityCatalogc

FeatureStatec # Classes

URI https://w3id.org/ocqa/contract#FeatureState
Super-classes opm:PropertyStatec

TimeRateCatalogc # Classes

URI https://w3id.org/ocqa/contract#TimeRateCatalog
Description

The TimeRateCatalog is a catalog that includes parameters or features concerning time estimations in the context of quality assurance in construction execution. This can relate to the time required for various processes, such as preparation, execution, or post-processing. Through this catalog, construction projects can be better planned and optimized in terms of time.

Super-classes ocqa-con:FeatureCatalogc

Propertyc # Classes

URI https://w3id.org/opm#Property
Sub-classes Characteristicc

PropertyStatec # Classes

URI https://w3id.org/opm#PropertyState
Sub-classes ocqa-con:FeatureStatec

Object Properties

hasEquipmentop # OPs

URI https://w3id.org/digitalconstruction/0.5/Entities#hasEquipment

hasLastInstantop # OPs

URI https://w3id.org/digitalconstruction/0.5/Entities#hasLastInstant

isStartOfop # OPs

URI https://w3id.org/digitalconstruction/0.5/Entities#isStartOf

detectop # OPs

URI https://w3id.org/ocqa#detect
Domain(s) InspectionProcedurec
Range(s) FailureCategoriesc

hasActivityTypeop # OPs

URI https://w3id.org/ocqa#hasActivityType
Domain(s) procedurec
Range(s) dicp:Activityc

hasActualCharacteristicop # OPs

URI https://w3id.org/ocqa#hasActualCharacteristic
Domain(s) Characteristicc
Range(s) ActualCharacteristicValuec

hasAssignedCharacteristicValueop # OPs

URI https://w3id.org/ocqa#hasAssignedCharacteristicValue
Domain(s) Characteristicc
Range(s) AssignedCharacteristicValuec

hasCausationop # OPs

URI https://w3id.org/ocqa#hasCausation
Domain(s) Evaluationc
Range(s) Causationc

hasCharacteristicop # OPs

URI https://w3id.org/ocqa#hasCharacteristic
Domain(s) Inspectionc
Range(s) Characteristicc

hasDocumentationop # OPs

URI https://w3id.org/ocqa#hasDocumentation
Domain(s) Inspectionc Evaluationc
Range(s) Recordc

hasInspCharacteristicop # OPs

URI https://w3id.org/ocqa#hasInspCharacteristic
Super-properties hasCharacteristicop

hasInspectionop # OPs

URI https://w3id.org/ocqa#hasInspection
Range(s) Inspectionc

hasInspectionEquipmentop # OPs

URI https://w3id.org/ocqa#hasInspectionEquipment
Super-properties dice:hasEquipmentop

hasInspectionProcedureop # OPs

URI https://w3id.org/ocqa#hasInspectionProcedure
Domain(s) Inspectionc
Range(s) InspectionProcedurec

hasQualificationop # OPs

URI https://w3id.org/ocqa#hasQualification

hasRecordop # OPs

URI https://w3id.org/ocqa#hasRecord
Domain(s) Inspectionc
Range(s) Evaluationc

hasRequiredQualificationop # OPs

URI https://w3id.org/ocqa#hasRequiredQualification
Domain(s) InspectionProcedurec

hasSampleop # OPs

URI https://w3id.org/ocqa#hasSample
Range(s) Samplec

simultaneop # OPs

URI https://w3id.org/ocqa#simultane
Domain(s) dice:Occurrentc
Range(s) dice:Occurrentc

succeedop # OPs

URI https://w3id.org/ocqa#succeed
Domain(s) dice:Occurrentc
Range(s) dice:Occurrentc

Datatype Properties

maxValuedp # DPs

URI https://schema.org/maxValue

valuedp # DPs

URI https://schema.org/value

InspectionStatusdp # DPs

URI https://w3id.org/ocqa#InspectionStatus
Domain(s) dice:Entityc

accepteddp # DPs

URI https://w3id.org/ocqa#accepted
Super-properties owl:topDataProperty
Domain(s) Inspectionc
Range(s) xsd:booleanc

filePathdp # DPs

URI https://w3id.org/ocqa#filePath
Domain(s) ExternalResourcec
Range(s) xsd:anyURIc

hasInpsectionPerUnitdp # DPs

URI https://w3id.org/ocqa#hasInpsectionPerUnit
Description

per Unit can be Floor, m2, m3

Super-properties owl:topDataProperty
Domain(s) InspectionProcedurec

hasInsepctionStatusdp # DPs

URI https://w3id.org/ocqa#hasInsepctionStatus

appraisal costsdp # DPs

URI https://w3id.org/ocqa#hasInspectionCost
Description

Subclass of hasActivityCost

Super-properties hasQuality-related-costsdp
Domain(s) Inspectionc

hasInspectionFrequencydp # DPs

URI https://w3id.org/ocqa#hasInspectionFrequency
Super-properties owl:topDataProperty
Range(s) xsd:integerc

hasInspectionIntervaldp # DPs

URI https://w3id.org/ocqa#hasInspectionInterval
Super-properties owl:topDataProperty
Domain(s) InspectionProcedurec

hasLikelihooddp # DPs

URI https://w3id.org/ocqa#hasLikelihood

hasNonConfirmityCostdp # DPs

URI https://w3id.org/ocqa#hasNonConfirmityCost
Super-properties hasQuality-related-costsdp

hasNonConfirmityProbabilitydp # DPs

URI https://w3id.org/ocqa#hasNonConfirmityProbability
Super-properties hasLikelihooddp

hasPreventionCostdp # DPs

URI https://w3id.org/ocqa#hasPreventionCost
Super-properties hasQuality-related-costsdp

hasProcedureDescriptiondp # DPs

URI https://w3id.org/ocqa#hasProcedureDescription
Domain(s) procedurec
Range(s) xsd:stringc

hasRiskdp # DPs

URI https://w3id.org/ocqa#hasRisk

hasStatusdp # DPs

URI https://w3id.org/ocqa#hasStatus
Super-properties owl:topDataProperty
Domain(s) Determinationc

Annotation Properties

creatorap # APs

URI http://purl.org/dc/terms/creator

descriptionap # APs

URI http://purl.org/dc/terms/description

issuedap # APs

URI http://purl.org/dc/terms/issued

licenseap # APs

URI http://purl.org/dc/terms/license

modifiedap # APs

URI http://purl.org/dc/terms/modified

titleap # APs

URI http://purl.org/dc/terms/title

preferredNamespacePrefixap # APs

URI http://purl.org/vocab/vann/preferredNamespacePrefix

preferredNamespaceUriap # APs

URI http://purl.org/vocab/vann/preferredNamespaceUri

BGBap # APs

URI https://w3id.org/ocqa#BGB

DIN_55350:2021-10ap # APs

URI https://w3id.org/ocqa#DIN_55350:2021-10

DIN_9000:2015ap # APs

URI https://w3id.org/ocqa#DIN_9000:2015

Namespaces

default (ocqa)
https://w3id.org/ocqa#
brick
https://brickschema.org/schema/Brick#
csvw
http://www.w3.org/ns/csvw#
dc
http://purl.org/dc/elements/1.1/
dcam
http://purl.org/dc/dcam/
dcat
http://www.w3.org/ns/dcat#
dcmitype
http://purl.org/dc/dcmitype/
dcterms
http://purl.org/dc/terms/
dica
https://w3id.org/digitalconstruction/0.5/Agents
dice
https://w3id.org/digitalconstruction/0.5/Entities#
dicp
https://w3id.org/digitalconstruction/0.5/Processes#
doap
http://usefulinc.com/ns/doap#
foaf
http://xmlns.com/foaf/0.1/
geo
http://www.opengis.net/ont/geosparql#
ocqa-cat
https://w3id.org/ocqa/catalog#
ocqa-con
https://w3id.org/ocqa/contract#
ocqa-reg
https://w3id.org/ocqa/regulation#
ocqa-rule
https://w3id.org/ocqa/rule#
odrl
http://www.w3.org/ns/odrl/2/
opm
https://w3id.org/opm#
org
http://www.w3.org/ns/org#
owl
http://www.w3.org/2002/07/owl#
prof
http://www.w3.org/ns/dx/prof/
prov
http://www.w3.org/ns/prov#
qb
http://purl.org/linked-data/cube#
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
sdo
https://schema.org/
sh
http://www.w3.org/ns/shacl#
skos
http://www.w3.org/2004/02/skos/core#
sosa
http://www.w3.org/ns/sosa/
ssn
http://www.w3.org/ns/ssn/
time
http://www.w3.org/2006/time#
vann
http://purl.org/vocab/vann/
void
http://rdfs.org/ns/void#
wgs
https://www.w3.org/2003/01/geo/wgs84_pos#
xsd
http://www.w3.org/2001/XMLSchema#

Legend

cClasses
opObject Properties
fpFunctional Properties
dpData Properties
apAnnotation Properties
pProperties
niNamed Individuals