Version |
0.3 (BFO ISO compliant) |
Next version |
|
Status |
Ontology Specification Draft |
Digital technologies are increasingly used in all stages of construction lifecycle. Existing buildings and sites are mapped with scanning technologies, designs are created using the tools of building information modeling (BIM), design and management information is consumed at the site through mobile devices, the progress of construction is monitored with sensors (position, occupancy, activity state) and scanning devices, and facility management is based on data gathered by building automation systems (BAS) and sensors. While the digital point solutions can mean great advances for individual tasks, the improvement of construction productivity depends also on what happens between the tasks: how the information produced in one task can and will be utilized by other tasks. This requires agreements and implementation, but before that can be done, there needs to be shared understanding of interoperability at technical, syntactic, and semantic levels.
In digital construction large volumes of heterogeneous data will be produced at each lifecycle stage. It is a significant challenge to process and interrelate different pieces of data into a meaningful and accurate overall picture that is operationally useful and understandable to both human and automated agents. The purpose of the Digital Construction Ontology Suite is to address the semantic level of this challenge, by providing the essential concepts and properties of construction and renovation projects, thus paving the way to the ultimate integration of information from different decentralized sources over construction lifecycle.
Note: The version 0.3 has been refactored to comply with the new version of BFO specified in the ISO/IEC 21838-2 standard, finally approved in 2020-03. While most of the classes of BFO have remained same as in its previous version, there is a large number of new relationships. Version 0.3 attempts to utilize those relationships as well as possible which has resulted in a number of changes especially concerning composite entities and activity-flow relations. Also, to make Digital Construction Ontologies easier to use by applications, a uniform naming of instantiated classes and related properties was provided by defining equivalent terms for many BFO terms. |
Entities | https://w3id.org/digitalconstruction/Entities | dice: | Identifiable entities with classifications, breakdowns and groupings |
Processes | https://w3id.org/digitalconstruction/Processes | dicp: | Activities, capabilities, constraints and variables |
Agents | https://w3id.org/digitalconstruction/Agents | dica: | Actors and stakeholders, and their relations and contracts |
Information | https://w3id.org/digitalconstruction/Information | dici: | Information content entities including designs, plans, events, and issues |
Contexts | https://w3id.org/digitalconstruction/Contexts | dicc: | Multi-contexts data: planned/actual, as-designed/as-built, levels of detail |
Variables | https://w3id.org/digitalconstruction/Variables | dicv: | Variables and constraints to support the representation of incomplete plans and management of changes |
Occupant Behavior | https://w3id.org/digitalconstruction/OccupantBehavior | dicob: | Occupant behavior and comfort |
Indoor Air Quality | https://w3id.org/digitalconstruction/IndoorAirQuality | diciaq: | Indoor air quality |
Building Acoustics | https://w3id.org/digitalconstruction/BuildingAcoustics | dicba: | Building acoustics |
Energy Systems | https://w3id.org/digitalconstruction/EnergySystems | dices: | Energy systems of buildings |
Building Materials | https://w3id.org/digitalconstruction/BuildingMaterials | dicbm: | Building materials |
Lifecycle | https://w3id.org/digitalconstruction/Lifecycle | dicl: | Evolution of information over construction lifecycle and refinement through LOD levels |
The ontologies in the Digital Construction Ontology Suite are related to other existing ontologies: (1) the concepts of the ontologies above can be based on the concepts of the external ontologies (such as those in BFO or FOAF), or (2) the data represented with above ontologies may need the use also concepts and properties of the external ontologies (such as BIM models represented in ifcOWL or provenance represented with PROV-O).
Digital construction ontologies aim to capture the relevant objects and properties (relationships and attributes) that can be referred to by people or systems during the management and execution of construction or renovation projects. This includes physical and spatial entities, temporal regions, information contents, agents, activities, and groupings of objects.
The overall scope of Digital Construction Ontologies is shown in the figure below. Most concepts in the figure are from the Entities ontology. The large grey boxes show the areas that specific ontology modules extend with more specific concepts. The concepts shown in the light-blue boxes in the middle are those defined in Digital Construction Ontologies, the ones in light-grey boxes belong to BFO ISO and the green ones are from other ontologies. The direction of the arrow shows the superclass relation and a two-way arrow means equivalent classes. The texts near to concept boxes suggest possible subclasses.
The top-level organization of the Digital Construction Ontologies are provided by BFO. It divides the entities into two classes, Occurrent (things taking place in time, such as processes) and Continuant (things taking place in space, such as physical entities or spacial regions). From the perspective of construction management, Activity - a subclass of Process - captures the intentional efforts of an Agent. An Agent can be a Person or an Organization, and can have Capabilities annd assume Roles. The construction process is characterized by a set of InformationContentEntities, such as Designs, Plans, Contracts and Issues.
Due to the fragmented nature of construction, there can be multiple parties and systems that manage any particular entities at some phase of their lifecycle, and that give identifiers, classifications or other labels to those entities. The exact nature and number of such labelings is highly context dependent. To promote linking and integration between systems in construction projects, the flexible capability to represent the labelings of entities is crucially important.
In Digital Construction Ontologies, any Entity can be associated with a number of Identifiers and Categories. They can be identifiedBy have Globally Unique Identifiers (GUID), and often multiple of them, each given by a different stage or system during its lifecycle. Moreover, objects can also have multiple local identifiers, such as a room number in a building or a control point number in a building automation system or an identifier in another information system.
Objects also belongTo different categories in different classification systems, such as OmniClass, Unicode, CoClass, etc. They can also belong to categories in other information systems, such as being an identifiable entity in a particular project.
The actual nature and number of identifiers is dependent on the context of an object, and it is not possible to define separate properties for each of them in an ontology in a generic way. Therefore both identifier and categories are represented as objects. An identifier has a label (hasLabel) that is a string and it is in relation to some scope (hasScope) which is a Category. For globally unique identifier the scope is a global category such as :Guids, and for local identifiers a more specific category.
The Labeling can also be used to associate case-specific names for any entity, for instance, to be shown in the user interface of a system that stores its data in Digital Construction Ontologies compliant manner. For example, in a location breakdown structure the locations can be associated with names that make sense for the people working in a particular stage of construction.
Activities have several different kinds of ingredients - often called flows - that have been studied and identified in the field of lean construction. The flows can be classified into transformed objects, material batches, equipment, labor crews, workspaces, information objects, and environmental conditions, and each activity can have several flows in each of these categories. To be executable an activity requires that its ingredients are in a proper state before the execution (preconditions) or during it (e.g., resource reservations). Moreover, the activity transforms the state of some of the ingredients as the result of its execution (effects) - this being the purpose of executing the activity in the first place.
An essential goal is to be able to link different entities to activities since the interest in construction management is in the progress of activity execution but direct, sensor-based observations can mostly be collected from other objects than activities themselves (e.g., sensor data about positions of objects or people, occupancy or locations). A proper linking will enable the derivation of activity execution data from the observations about the linked objects.
The figure above presents the relations in Digital Construction Ontologies to represent the flows of activities, defined in the Entities and Processes ontologies. The table below gives a detailed description of the flow relations. (Note that dice:hasParticipant is equivalent to BFO's 'has participant', and dice:occursIn BFO's 'occurs in').
Ontology | Property | Domain | Range | Inverse | Subproperty of |
---|---|---|---|---|---|
Entities | dice:hasAgent | dice:Activity | dice:Agent | dice:isAgentIn | dice:hasParticipant |
dice:hasMaterial | dice:Activity | dice:MaterialBatch | dice:isMaterialIn | dice:hasParticipant | |
dice:hasEquipment | dice:Activity | dice:Equipment | dice:isEquipmentIn | dice:hasParticipant | |
dice:hasInformation | dice:Activity | dice:Information | dice:isInformationIn | dice:hasParticipant | |
dice:occursIn | dice:Activity | dice:Location | dice:hasEnvironment | - | |
Processes | dicp:hasObject | dicp:ObjectActivity | BFO's 'entity' | dicp:isObjectIn | dice:hasParticipant |
The object of an activity (using dicp:hasObject property) can be, in addition to dice:BuildingObject also anything else that can be a focus of work, such as dice:Location, dice:Group (e.g., for procurement and logistic activities), dice:Activity (e.g., for managerial activities), or dice:InformationContentEntity (e.g., for design and planning activities).
It should be noted that these properties as such allow only a partial representation of the relations of activities and flows. They tell what entities are the ingredients of an activity but do not specify what should be the state of an entity before the execution of an activity (preconditions) or what would be the state after it (effects). The representation of these states require the concepts from the Variables ontologies described below.
Different aspects of construction - such as building objects, resources, or activities - can be represented in multiple different contexts and often it is interesting to compare the differences between those contexts. Building-related examples are as-designed and as-built contexts for BIM models, or more comprehensively the contexts for different LODs (levels of detail/development). Typical activity-related contexts are planned and actual data of project execution.
Multi-context data is represented using the named graphs of RDF datasets. It is an orthogonal mechanism that allows any objects to be associated with different properties - or even different structures - in different contexts. If needed the multi-context mechanism allows the recording of all differences between planned and actual activities. In addition to the traditionally recorded planned and actual start and end times of activities, it is also possible represent actual activities that do not appear in the plans at all (so-called improvised activities).
Much of the essential information in project management or construction management can be represented in the form of constraints, and over significant periods during project execution, the plans can have incomplete information about the exact values of some properties, such as start and end times of tasks, resources assigned to tasks, locations of entities, and so on. To enable the interoperable sharing of such crucial and common information, the ontologies include a possibility to associate a variable to any property of an object and to represent constraints between variables. This representation is completely orthogonal and can be used to enrich objects and properties defined in any existing ontologies.
In the example on the right the properties of an object (shipment1) as defined in the ontology are shown in blue color. Each of those properties is associated with a variable (in red color). The variables again are associated with constraints (in green color) that limit their possible values.
Digital Construction ontologies are designed to observe the Linked Data principles, and consequently to enable decentralized publication of construction data by the diverse parties in construction projects.
The ontologies use or are aligened with well-known existing ontologies, as shown in the figure on the right (import relations are shown as solid and reference relations dashed lines). The Basic Formal Ontology (BFO) is imported as the top-level ontology, the BIM models can be provided in ifcOWL or BOT, and concepts from other ontologies such as OWL-Time, PROV-O, FOAF, QUDT, SSN/SOSA, and Saref are used as needed.
BIM4EEB - BIM-based toolkit for efficient renovation of residential buildings (European Union's H2020 research and innovation programme, grant N. 820660) |
Diction - Development of shared situational awareness in construction projects (Business Finland, Collaborative research project 2018-2020) |