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.
The AEC3PO ontology's namespace is https://w3id.org/lbd/aec3po/.
The prefixed is aec3po:.
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.
- How to define the metadata of a compliance checking related Document?
- What are the parts of a document, their unique identifiers, and their order?
- How to represent cross-referencing in a document?
- What type of information (Statement) does a Document contain?
- What categories or types of check statements can a check statement inform?
- What type of check methods need to be performed for a Statement to comply?
- Which check statement does a check method operationalize?
- What are the required data to perform a check?
- Is a property of a feature of interest greater than a value?
- Which checking act needs to be made and which check method it uses?
- How to access the outcomes of a checking act?
- 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?
- What is the coverage of a Document per Administrative Area?
- What are the stages of the Permitting process per Administrative Area?
- What evidence is required in each stage?
- Which standards the permitting stages are related to?
- What types of checks and verifications are necessary to ensure compliance with building regulations during the permitting phase?
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
-
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.
-
Compliance Verification Report: This AEC3PO module describes results of some
aec3po:ProcesVerifierchecking some entity via aaec3po:CheckingAct. Entities may be validated or repudiated.- Classes: ComplianceVerificationReport, result, ValidationResult,Severity, etc.
- Properties: conforms, focus, resultMessage, resultSeverity,etc.
-
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.
-
Legal Verifier: This AEC3PO module defines state and private verifiers.
- Classes: LegalVerifier, PrivateVerifier, StateVerifier.
- Properties: hasDesign.
-
Model: This AEC3PO module describes BIM models.
- Classes: Model, Phase, Element, Classification, etc.
- Properties: name, description, location, locationCoverage, material, hasBuildingPhase, hasDimensions, hasElementPhase, hasClassification, etc.
-
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 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.
| Ontology | Namespace | Prefix | Description and Usage |
|---|---|---|---|
| DCMI Metadata Terms | http://purl.org/dc/terms/ | dct: | The Dublin Core Terms (DCT) ontology is used within the "AEC3PO" ontology to provide a standardised framework for describing and managing metadata related to documents and other resources in the construction compliance and permitting context. |
| eli | http://data.europa.eu/eli/ontology# | eli: | The European Legislation Identifier (ELI) ontology is used within the "AEC3PO" ontology to provide a standardized framework for referencing and managing legal and legislative information related to documents, regulations, and other legal entities within the construction compliance and permitting context. |
| Stages | https://w3id.org/digitalconstruction/0.5/Stages | dicstg: | The Digital Construction Stages vocabulary is used within the "AEC3PO" ontology to define product lifecycle stage frameworks and their specific stages as individuals according to some standards like BS_EN_16310, HOAI, ISO_22263, RIBA. |
| LifeCycle | https://w3id.org/digitalconstruction/0.5/Lifecycle# | dicl: | The Digital Construction LifeCycle vocabulary is used within the "AEC3PO" ontology to define the evolution of information through LOD levels and over the construction lifecycle. |
| FOAF | http://xmlns.com/foaf/spec/ | foaf: | The Friend of a Friend (FOAF) ontology is used within the "AEC3PO" ontology to define agents and organisations such as the Legal Verifier. |
| schema.org | https://schema.org/ | schema: | The schema.org ontology is used within the "AEC3PO" ontology to define the BIM model as a 3D Model, and the different formats that an evidence might have such as image, stillImage (for drawings), etc. |
| QUDT | http://qudt.org/2.1/schema/qudt | qudt: | The QUDT (Quantities, Units, Dimensions, and Data Types) ontology provides a standardised way to represent quantities, units of measurement, and their relationships. It is used within the "AEC3PO" ontology to define the quantities and units represented in a Statement or related to a feature of interest. |
| Unit | http://qudt.org/vocab/unit/ | unit: | The Unit Ontology (Unit) is a resource that provides a standardised way to represent units of measurement and their conversions. It is used within the "AEC3PO" ontology to provide standardised units for the properties and values. |
| ifcOWL | https://standards.buildingsmart.org/IFC/DEV/IFC4/ADD2/OWL/ | ifcowl: | The Industry Foundation Classes (IFC) ontology in OWL (ifcOWL) is a standardised ontology for representing building and construction information. It is used to serve as a reference or a source of domain-specific knowledge that complements the information represented in "AEC3PO." |
| Open Graph Protocol | https://ogp.me/ns# | og: | The Open Graph Protocol (OGP) ontology provides a standardised way to describe and represent the properties of a web page or resource. It is used within the "AEC3PO" ontology to define the URLs of the bSDD contexts of properties and features of interest. |
| Function | https://w3id.org/function/ontology# | fno: | The Function Ontology is a lightweight ontology designed to represent functions and their relationships in various domains. It is used within the "AEC3PO" ontology to represent the functional relationships between different components, systems, and elements in the built environment. The function can be related to an implementation. I.e. SPARQL, Shacl - or a microservice. |
| SKOS | http://www.w3.org/2004/02/skos/core# | skos: | The Simple Knowledge Organization System (SKOS) ontology is commonly used to represent and manage controlled vocabularies, taxonomies, and thesauri. Within the context of the "AEC3PO" ontology, SKOS is used in various ways to enhance the representation and organisation of concepts and terms related to compliance, design, construction, and permitting processes. |
| DUL | http://www.ontologydesignpatterns.org/ont/dul/DUL.owl# | dul: | The DUL (DOLCE + DnS Ultralite) ontology, which is an upper-level ontology, is used in the "AEC3PO" ontology to provide a foundational framework for modeling and representing various concepts and relationships in a more coherent and structured manner, such as the CheckMethod, qualities, CheckingAct, etc. |
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:
| Demo Country | Use Case | Description | Source |
|---|---|---|---|
| Finland | FI2 - Accessibility | This example represents the ramp check. The rules are defined in Section 2/Subsection 2 from the English tranlation of the Finnish Accessibility document (More details). |
link |
| Finland | FI3 - CO2 Emission | The rules are defined in the English translation of the Decree of the Ministry of the Environment on the climate assessment of buildings (Draft 30.9.2022, consultation round) (More details). | link |
| Estonia | EE1 - Fire Safety | Two rules related to the operational map of the building have been selected from the Estonian legistlation issued on 01-03-2021 (More details). |
link |
| Spain | ES2 - Cultural Centre | Two rules have been selected to check the conformance of the cantiliver of the cultural centre with the regulations. These rules are defined in the POUM document, which is the Municipal Urban Planning Plan Regulations document, definitively approved by the Barcelona Territorial Planning Commission on 13-07-2005 (More details). |
link |
| UK | UK1 - Timber Structure | This example represents check in compression parallel to the grain in timber structures, as described in the latest version of Eurocode 5 (EN 1995-1-1:2004+A2:2014) (More details). |
link |
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"
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
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.