AEC3PO: Architecture Engineering and Construction Compliance Checking and Permitting Ontology

Description

The Architecture, Engineering, Construction, Compliance Checking and Permitting Ontology (AEC3PO) is an ontology developed in the context of the Automated Compliance Checks for Construction, Renovation or Demolition Works (ACCORD) project, which is a Horizon European project that aims to digitalise permitting and compliance processes. AEC3PO has been developed in order to capture all aspects of building compliance and building permitting in Architecture, Engineering, and Construction (AEC). It allows the modelling of aspects such as:

• building codes, regulations, and standards
• compliance and permitting processes and documentation
• compliance and permitting actorsACC

The ontology requirements are essentially derived from the rule formalisation methodology that aims to semantise regulations and provide an open format for machine-readable rules.

The ontology is built using Semantic Web technologies, adhering to standards like RDF, OWL, and SKOS. It makes use of well-known ontologies like Dublin Core Terms (DCT), Europe's Legislation Identifier (ELI), and more to create a structured and interconnected knowledge graph. This allows professionals to explore, query, and understand various aspects of the compliance and permitting processes more comprehensively.

Table of Contents

1. Namespace
2. Ontology Requirements
   1. ACCORD Requirements
   2. Competency Questions
      1. Compliance
      2. Permitting
3. Overview of AEC3PO Modules and Alignments
   1. AEC3PO Modules
   2. AEC3PO Alignments
4. Examples

   Namespace

   The AEC3PO ontology's namespace is https://w3id.org/lbd/aec3po/. The prefixed is aec3po:.

Ontology Requirements

ACCORD Requirements

The AEC3PO is a significant component of the Compliance and Permitting Semantic Framework developed in the ACCORD project. As part of Work Package 2 (WP2), AEC3PO plays a pivotal role in Task T2.2, building upon the foundation laid by the literature prepared in Task T2.1. Drawing inspiration from the ontologies presented in T2.1, AEC3PO establishes a structured knowledge representation that captures essential concepts, relationships, and rules related to compliance checks and permitting stages within construction projects. By aligning with the objectives of the ACCORD project, AEC3PO serves as the basis of i) rule formalization methodology (Task 2.3); ii) Domain Specific Rule Language, and iii) rule formalization tool (Task 2.3), facilitating seamless communication and collaboration among experts, stakeholders, and regulatory bodies in the AEC industry.

Competency Questions

Compliance

1. How to define the metadata of a compliance checking related Document?
2. What are the parts of a document, their unique identifiers, and their order?
3. How to represent cross-referencing in a document?
4. What type of information (Statement) does a Document contain?
5. What categories or types of check statements can a check statement inform?
6. What type of check methods need to be performed for a Statement to comply?
7. Which check statement does a check method operationalize?
8. What are the required data to perform a check?
9. Is a property of a feature of interest greater than a value?
10. Which checking act needs to be made and which check method it uses?
11. How to access the outcomes of a checking act?
12. How to transform normative documents into a single well-defined rule that can be implemented into BIM / IFC based model checking software using RASE methodology?
13. What is the coverage of a Document per Administrative Area?

Permitting

1. What are the stages of the Permitting process per Administrative Area?
2. What evidence is required in each stage?
3. Which standards the permitting stages are related to?
4. What types of checks and verifications are necessary to ensure compliance with building regulations during the permitting phase?

Overview of AEC3PO modules and alignements

AEC3PO Modules

The AEC3PO ontology is designed to represent various aspects of the construction domain, focusing on compliance and permitting. It is organised into different modules, each comprising classes, and properties. These modules facilitate the modeling of different components and relationships within the construction domain. The figure below shows an overview of these modules and the relations among them.

Below is an overview of each module and its sub-components:

1. Module 1: Document: This module describes the metadata of a building-compliance related document and its composition in terms of subdivisions (sections, tables, images) which come in a hierarchical form.

   • Classes: Document, DocumentSubdivision.
   • Properties: hasPart, hasRequiredData, forDocument, hasPermittingStage, etc.

2. Module 2: Statement: This module describes things stated in a building compliance-related document.

   • Classes: Statement, DefinitionStatement, CheckStatement, CheckListStatement, CategoryCheckStatement, CertificateCheckStatement, BooleanCheckStatement, NumericalCheckStatement, HumanEvaluatedCheckStatement, etc.
   • Properties: hasSubdivision, hasRequiredData, hasEvidence, hasDefinition, definitionOf, etc.

3. Module 3: DataRequirement: This module describes all data requirements that are dictated from the statement. The format of data requirements adopted by ACCORD is IDS.

   • Classes: DataRequirement, IDS.
   • Properties: hasFormat, etc.

4. Module 4: Evidence: This module describes all evidence that can be provided to assess the validity and relevance of the statement. The evidence comes in different format such as an expert report, a certificate etc.

   • Classes: Evidence.
   • Properties: hasFormat, forDocument, etc.

5. Module 5: CheckMethod: This module describes pieces of information that operationalize check statements in documents.

   • Classes: CheckMethod, BooleanCheckMethod, ComponentCheckMethod, SHACLCheckMethod, CompositeCheckMethod, FuncionCheckMethod, etc.
   • Properties: hasUnit, hasTarget, operationalizes, operationalizedBy, etc.

6. Module 6: FeatureOfInterest: This module describes objects whose conformance against checks is verified, and those aspects of a feature of interest that are intrinsic to and cannot exist without the feature of interest, that must be checked for conformance.

   • Classes: FeatureOfInterest, Property, PropertyKind, QuantityKind
   • Properties: hasProperty, hasQuantityKind, hasPropertyKind, hasDesign, hasContext, etc.

7. CheckingAct: This AEC3PO module describes the act of checking some entities for something and generating a compliance verification report.

   • Classes: CheckingAct, ProcessVerifier, etc.
   • Properties: usedMethod, madeBy, hasReport, checks, etc.

8. Compliance Verification Report: This AEC3PO module describes results of some aec3po:ProcesVerifier checking some entity via a aec3po:CheckingAct. Entities may be validated or repudiated.

   • Classes: ComplianceVerificationReport, result, ValidationResult,Severity, etc.
   • Properties: conforms, focus, resultMessage, resultSeverity,etc.

9. Design: This AEC3PO module describes descriptions of some design of features of interest, in terms of structure, geometry, and function.

   • Classes: Design, PropertyDesign.
   • Properties: hasDesign.

10. Legal Verifier: This AEC3PO module defines state and private verifiers.

    • Classes: LegalVerifier, PrivateVerifier, StateVerifier.
    • Properties: hasDesign.

11. Model: This AEC3PO module describes BIM models.

    • Classes: Model, Phase, Element, Classification, etc.
    • Properties: name, description, location, locationCoverage, material, hasBuildingPhase, hasDimensions, hasElementPhase, hasClassification, etc.

12. Table: This AEC3PO module describes tables as representations of data in rows and columns. Tables are described by captions.

    • Classes: Container, Table, Column, Row, Cell.
    • Properties: contains, isContainedIn, caption.

Each module encompasses classes that represent specific entities or concepts in the construction domain. For example, the Document module deals with different types of statements, evidence, and related properties. The CheckMethod module focuses on different types of check methods, such as procedural, declarative, boolean, component, SHACL and composite checks. Similarly, the Design module includes classes representing design-related concepts, while the FeatureOfInterest module deals with features like building components and spaces. The CheckingAct module represents different verifier roles, their associated methods, and the ComplianceVerificationReport stores the outcomes of the check, their validation results and the corresponding messages.

AEC3PO Alignments

AEC3PO contains five modules, each of them imports an external ontology, and specifies a set of alignment axioms to connect the terms of the imported ontologies with each other. The figure below illustrates the alignment of the AEC3PO ontology with various other ontologies, showcasing how different domains and concepts interconnect for a comprehensive representation of compliance and permitting in the AEC industry.

In the figure, the AEC3PO ontology is positioned at the center, with arrows extending outward to connect with other related ontologies. Each ontology is represented as a distinct node, emphasising the integration of diverse knowledge domains. The alignment signifies the synergy achieved by harmonising multiple ontologies to enhance the overall understanding and modeling of compliance and permitting processes in the AEC sector.

The figure above effectively conveys the interconnectedness of different ontologies with AEC3PO for a holistic understanding of compliance and permitting processes in the construction industry. This alignment facilitates cross-domain information sharing, enabling more accurate and comprehensive modeling of the complex construction ecosystem. The table below lists all the external ontologies, the namespaces and the suggested prefix for each ontology modules is also provided.

Examples

The folder examples contains a collection of Turtle files that demonstrate the instantiation of the AEC3PO ontology in the context of the demo countries Finland, Estonia, Spain and UK. Each Turtle file within the folder represents a specific scenario where the ontology is instantiated to model compliance checking and permitting processes for a different use case from the demo countries use cases. The purpose of these examples is to showcase how AEC3PO can be applied to real-world scenarios and adapted to specific regulatory contexts. The folder contains sub-folders with the name of the demo countries. Each sub-folder contains the turtle file and related documentation. Every example is documented in the corresponding readme file.

The following table represents a summary of the use cases:

AEC3PO Dissemination

Building Compliance and Permitting Ontology, Linked Data and Ontologies, The Third Building Digital Twin International Congress, Antwerp, May 3rd, 2023, Belgium.

1th Linked Data in Architecture and Construction Workshop (LDAC 2023), 15-16 June 2023, Italy. In this workshop, AEC3PO has been presented as part of the Industrial Talk titled "Semantisation of Rules for Automated Compliance Checking"

Pre-commits

run pre-commit install to set up the git hook scripts:

$ pre-commit install
pre-commit installed at .git/hooks/pre-commit

now pre-commit will run automatically on git commit!

you can also run pre-commit once on all files:

pre-commit run --all-files

CI/CD pipeline

A CI/CD pipeline validates the ontology, generates the ontology artifacts, and release the ontology.

The public folder is automatically generated as described in .asimov/README.md and pushed to the server. It is therefore ignored by git.