https://w3id.org/ocqa#
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.
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.
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:
|
6 |
Ontology Requirements |
|
|
|
In addition to these use cases, the following nonfunctional requirements have been identified as crucial for the OCQA:
|
|
|
|
Use Case 1: Description of inspection plans and relevant information
Use Case 2: Providing knowledge to support decision making in inspection planning
Use Case 3: (Semi-)Automated planning of inspections
|
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.
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.
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.
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).
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.
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.
URI | http://w3id.org/seas/Property |
---|---|
Sub-classes |
Characteristicc |
URI | https://w3id.org/digitalconstruction/0.5/Entities#Equipment |
---|---|
Sub-classes |
MeasuringEquipmentc InspectionEquipmentc |
URI | https://w3id.org/digitalconstruction/0.5/Entities#Occurrent |
---|---|
In domain of |
succeedop simultaneop |
In range of |
succeedop simultaneop |
URI | https://w3id.org/digitalconstruction/0.5/Processes#Activity |
---|---|
Sub-classes |
Determinationc |
In range of |
hasActivityTypeop |
URI | https://w3id.org/ocqa#ActualCharacteristicValue |
---|---|
Super-classes |
https://w3id.org/digitalconstruction/0.5/Variables#PropertyStatec |
In range of |
hasActualCharacteristicop |
URI | https://w3id.org/ocqa#AssignedCharacteristicValue |
---|---|
Super-classes |
https://w3id.org/digitalconstruction/0.5/Variables#PropertyStatec |
In range of |
hasAssignedCharacteristicValueop |
URI | https://w3id.org/ocqa#Causation |
---|---|
In range of |
hasCausationop |
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 |
URI | https://w3id.org/ocqa#Conformity |
---|---|
Super-classes |
Documentationc Evaluationc |
URI | https://w3id.org/ocqa#ConstructionProcedure |
---|---|
Super-classes |
procedurec |
URI | https://w3id.org/ocqa#Damage |
---|---|
Super-classes |
Nonconformityc |
URI | https://w3id.org/ocqa#Defect |
---|---|
Super-classes |
Nonconformityc |
URI | https://w3id.org/ocqa#Determination |
---|---|
Super-classes |
dicp:Activityc |
Sub-classes |
Monitoringc ProgressEvaluationc Reviewc Testc Measurementc Inspectionc |
In domain of |
hasStatusdp |
URI | https://w3id.org/ocqa#Evaluation |
---|---|
Sub-classes |
Conformityc Nonconformityc |
In domain of |
hasCausationop hasDocumentationop |
In range of |
hasRecordop |
URI | https://w3id.org/ocqa#ExternalResource |
---|---|
Description |
An external resource is linked via a URI. |
Super-classes |
Documentationc |
In domain of |
filePathdp |
URI | https://w3id.org/ocqa#FailureCategories |
---|---|
Description |
These error categories describe possible errors that may occur in a component. |
In range of |
detectop |
URI | https://w3id.org/ocqa#Image |
---|---|
Super-classes |
Documentationc |
URI | https://w3id.org/ocqa#Inspection |
---|---|
Super-classes |
Determinationc |
In domain of |
hasRecordop hasInspectionProcedureop hasDocumentationop hasCharacteristicop accepteddp appraisal costsdp |
In range of |
hasInspectionop |
URI | https://w3id.org/ocqa#InspectionEquipment |
---|---|
Super-classes |
dice:Equipmentc |
URI | https://w3id.org/ocqa#InspectionPlan |
---|---|
Description |
Inspection plan |
Super-classes |
Planc |
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 |
URI | https://w3id.org/ocqa#Inspector |
---|---|
Super-classes |
https://w3id.org/digitalconstruction/0.5/Agents#Personc |
URI | https://w3id.org/ocqa#Measurement |
---|---|
Super-classes |
Determinationc |
URI | https://w3id.org/ocqa#MeasuringEquipment |
---|---|
Super-classes |
dice:Equipmentc |
URI | https://w3id.org/ocqa#Monitoring |
---|---|
Super-classes |
Determinationc |
URI | https://w3id.org/ocqa#Nonconformity |
---|---|
Super-classes |
Documentationc Evaluationc |
Sub-classes |
Defectc Damagec |
URI | https://w3id.org/ocqa#Plan |
---|---|
Sub-classes |
InspectionPlanc |
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 |
URI | https://w3id.org/ocqa#ProgressEvaluation |
---|---|
Super-classes |
Determinationc |
URI | https://w3id.org/ocqa#Protocol |
---|---|
Description |
Derived from a SHACL rule using DASH functions. |
Super-classes |
Documentationc |
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 |
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 |
URI | https://w3id.org/ocqa#Record |
---|---|
Sub-classes |
Protocolc Imagec Conformityc Nonconformityc Videoc ExternalResourcec Resultc |
In range of |
hasDocumentationop |
URI | https://w3id.org/ocqa#Result |
---|---|
Super-classes |
Documentationc |
URI | https://w3id.org/ocqa#Review |
---|---|
Super-classes |
Determinationc |
URI | https://w3id.org/ocqa#Test |
---|---|
Super-classes |
Determinationc |
URI | https://w3id.org/ocqa#Video |
---|---|
Super-classes |
Documentationc |
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 |
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 |
URI | https://w3id.org/ocqa/contract#FeatureCatalog |
---|---|
Sub-classes |
ocqa-con:TimeRateCatalogc ocqa-con:CostFeatureCatalogc ocqa-con:FailureProbabilityCatalogc |
URI | https://w3id.org/ocqa/contract#FeatureState |
---|---|
Super-classes |
opm:PropertyStatec |
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 |
URI | https://w3id.org/opm#Property |
---|---|
Sub-classes |
Characteristicc |
URI | https://w3id.org/opm#PropertyState |
---|---|
Sub-classes |
ocqa-con:FeatureStatec |
URI | https://w3id.org/ocqa#detect |
---|---|
Domain(s) | InspectionProcedurec |
Range(s) | FailureCategoriesc |
URI | https://w3id.org/ocqa#hasActivityType |
---|---|
Domain(s) | procedurec |
Range(s) | dicp:Activityc |
URI | https://w3id.org/ocqa#hasActualCharacteristic |
---|---|
Domain(s) | Characteristicc |
Range(s) | ActualCharacteristicValuec |
URI | https://w3id.org/ocqa#hasAssignedCharacteristicValue |
---|---|
Domain(s) | Characteristicc |
Range(s) | AssignedCharacteristicValuec |
URI | https://w3id.org/ocqa#hasCausation |
---|---|
Domain(s) | Evaluationc |
Range(s) | Causationc |
URI | https://w3id.org/ocqa#hasCharacteristic |
---|---|
Domain(s) | Inspectionc |
Range(s) | Characteristicc |
URI | https://w3id.org/ocqa#hasDocumentation |
---|---|
Domain(s) | Inspectionc Evaluationc |
Range(s) | Recordc |
URI | https://w3id.org/ocqa#hasInspCharacteristic |
---|---|
Super-properties | hasCharacteristicop |
URI | https://w3id.org/ocqa#hasInspection |
---|---|
Range(s) | Inspectionc |
URI | https://w3id.org/ocqa#hasInspectionEquipment |
---|---|
Super-properties | dice:hasEquipmentop |
URI | https://w3id.org/ocqa#hasInspectionProcedure |
---|---|
Domain(s) | Inspectionc |
Range(s) | InspectionProcedurec |
URI | https://w3id.org/ocqa#hasRecord |
---|---|
Domain(s) | Inspectionc |
Range(s) | Evaluationc |
URI | https://w3id.org/ocqa#hasRequiredQualification |
---|---|
Domain(s) | InspectionProcedurec |
URI | https://w3id.org/ocqa#simultane |
---|---|
Domain(s) | dice:Occurrentc |
Range(s) | dice:Occurrentc |
URI | https://w3id.org/ocqa#succeed |
---|---|
Domain(s) | dice:Occurrentc |
Range(s) | dice:Occurrentc |
URI | https://w3id.org/ocqa#InspectionStatus |
---|---|
Domain(s) | dice:Entityc |
URI | https://w3id.org/ocqa#accepted |
---|---|
Super-properties | owl:topDataProperty |
Domain(s) | Inspectionc |
Range(s) | xsd:booleanc |
URI | https://w3id.org/ocqa#filePath |
---|---|
Domain(s) | ExternalResourcec |
Range(s) | xsd:anyURIc |
URI | https://w3id.org/ocqa#hasInpsectionPerUnit |
---|---|
Description |
per Unit can be Floor, m2, m3 |
Super-properties | owl:topDataProperty |
Domain(s) | InspectionProcedurec |
URI | https://w3id.org/ocqa#hasInspectionCost |
---|---|
Description |
Subclass of hasActivityCost |
Super-properties | hasQuality-related-costsdp |
Domain(s) | Inspectionc |
URI | https://w3id.org/ocqa#hasInspectionFrequency |
---|---|
Super-properties | owl:topDataProperty |
Range(s) | xsd:integerc |
URI | https://w3id.org/ocqa#hasInspectionInterval |
---|---|
Super-properties | owl:topDataProperty |
Domain(s) | InspectionProcedurec |
URI | https://w3id.org/ocqa#hasNonConfirmityCost |
---|---|
Super-properties | hasQuality-related-costsdp |
URI | https://w3id.org/ocqa#hasNonConfirmityProbability |
---|---|
Super-properties | hasLikelihooddp |
URI | https://w3id.org/ocqa#hasPreventionCost |
---|---|
Super-properties | hasQuality-related-costsdp |
URI | https://w3id.org/ocqa#hasProcedureDescription |
---|---|
Domain(s) | procedurec |
Range(s) | xsd:stringc |
URI | https://w3id.org/ocqa#hasStatus |
---|---|
Super-properties | owl:topDataProperty |
Domain(s) | Determinationc |
https://w3id.org/ocqa#
https://brickschema.org/schema/Brick#
http://www.w3.org/ns/csvw#
http://purl.org/dc/elements/1.1/
http://purl.org/dc/dcam/
http://www.w3.org/ns/dcat#
http://purl.org/dc/dcmitype/
http://purl.org/dc/terms/
https://w3id.org/digitalconstruction/0.5/Agents
https://w3id.org/digitalconstruction/0.5/Entities#
https://w3id.org/digitalconstruction/0.5/Processes#
http://usefulinc.com/ns/doap#
http://xmlns.com/foaf/0.1/
http://www.opengis.net/ont/geosparql#
https://w3id.org/ocqa/catalog#
https://w3id.org/ocqa/contract#
https://w3id.org/ocqa/regulation#
https://w3id.org/ocqa/rule#
http://www.w3.org/ns/odrl/2/
https://w3id.org/opm#
http://www.w3.org/ns/org#
http://www.w3.org/2002/07/owl#
http://www.w3.org/ns/dx/prof/
http://www.w3.org/ns/prov#
http://purl.org/linked-data/cube#
http://www.w3.org/1999/02/22-rdf-syntax-ns#
http://www.w3.org/2000/01/rdf-schema#
https://schema.org/
http://www.w3.org/ns/shacl#
http://www.w3.org/2004/02/skos/core#
http://www.w3.org/ns/sosa/
http://www.w3.org/ns/ssn/
http://www.w3.org/2006/time#
http://purl.org/vocab/vann/
http://rdfs.org/ns/void#
https://www.w3.org/2003/01/geo/wgs84_pos#
http://www.w3.org/2001/XMLSchema#
c | Classes |
op | Object Properties |
fp | Functional Properties |
dp | Data Properties |
ap | Annotation Properties |
p | Properties |
ni | Named Individuals |