Paper A2

36. BIM Ontology

  BIM-OntologyFigure 1.  The BIM ontology v3.1 (Neuron Model v0.4, Updated July 28, 2016)

The BIM ontology is an informal, semi-structured, conceptual domain ontology used for knowledge acquisition and communication between people. It is intended to represent knowledge interactions (push/pull) between BIM players, their deliverables and requirements (Figure 2) as described within Papers A1 and A2 (Succar, Sher, & Aranda-Mena, 2007) (Succar, 2009) and facilitate the validation of conceptual models (Shanks, Tansley, & Weber, 2003).

The BIM ontology includes BIM-specific concepts, their relations and attributes which facilitate analysis of domain knowledge (Noy & McGuinness, 2001), enable the construction of a domain framework (Studer, Benjamins, & Fensel, 1998), and support knowledge acquisition and communication (Milton, 2007a, 2007b) (Cottam, 1999) (Studer et al., 1998). Figure 2 below illustrates how ontological objects underlie the BIM Framework. The concept map (Figure 2 - right) is a visual representation of the ontological relationship between the three concepts (BIM Fields, BIM Stages and BIM Lenses); while the visual knowledge model (Figure 2 - left) abstracts these relations into the Tri-axial Model, a simplified graphical representation to facilitate communication. As discussed in Papers A1 and A2, this combination of visual modelling, driven by explicit ontological relations, renders the BIM Framework and its many conceptual constructs more accessible for analysis, modification and extension.

Also, as depicted in the Conceptual Hierarchy post, ontological relations enable a ‘conceptual mesh’ linking different types of conceptual constructs: frameworks, models, taxonomies, classifications and specialized dictionary terms. 

BIM-Ontology---2-Images
Figure 2. Visual Knowledge Model (left) + Concept Map (right)

 

Generating the BIM ontology

The BIM ontology has been generated by amending and reusing existing ontologies; a process recommended by Noy and McGuiness (2001). The reuse of an existing ontology followed Gruber’s criteria for shared ontologies: clarity, coherence, extensibility, minimal encoding bias and minimum ontological commitment (Gruber, 1995). Based on these criteria, the BIM ontology was first derived from the General Technological Ontology (Milton, 2007a) (Milton, 2007b) and the General Process Ontology (Cottam, 1999). While earlier iterations of the BIM ontology followed source definitions, newer iterations are more closely matched with the conceptual and practical requirements of the BIM domain.

Knowledge Objects

The BIM ontology comprises of four high-level knowledge objects: concepts, attributes, relations and knowledge Sets (Table 1):

 

Knowledge Objects

Description

Examples

I

Concepts (Table 2)

A mental construct

Component; Document; Role

II

Attributes (Table 3)

Values and qualifiers associated with Concepts

Cost; Count; Description

III

Relations (Table 4)

Connections between Concepts; the effect of one Concept on another

Approves; Detects; Supplies

IV

Knowledge Sets (Table 5)

A purposeful compilation of Concepts, their Attributes and Relations

Knowledge Foundations; Knowledge Blocks; Knowledge Views

Table 1. BIM Ontology Knowledge Objects (v3.0, last updated August 16, 2015)

 I. Concepts

Ability

Activity

Certificate

Component

Conception

Conceptual Construct

Constraint

Data Source

Data Use

Deliverable

Designation

Document

Document Use

Effect

Equipment

Event

Example

Facility

Format

Function

Hardware

Incentive

Information Use

Knowledge Domain

Lesson

Machine

Measurement

Medium

Message

Method

Milestone

Model

Model Use

Place

Player

Product

Proof

Recommendation

Representation

Requirement

Responsibility

Result

Role

Rule

Scenario

Software Application

Space

Standard

System

System Unit

Target  Test Tool  Trigger    

Table 2. Concepts (51 Concepts in v3.10, last updated July 28, 2016)

II. Attributes

Name

Description

Name

Description

Availability

An integer or string indicating the basic existence or availability of a concept

Location

The coordinates of an object within a physical space

Cost

A monetary value expressed in whole numbers, fractions or decimals

Market

A defined economical boundary

Count

An expression of elemental numbers using integers

Order

An arrangement whether chronological or spatial – not preferential or developmental (refer to Grade)

Description

An explanation expressed using words, phrases and sentences

Proposition

A mutually exclusive distinction between clear choices

Grade

A variables denoting preference or developmental achievement expressed in integers, percentages or text

State

A description of condition whether temporary or permanent

Link

A hypertext connection

Time

An expression of chronology expressed in minutes, second, days, etc…

Language

The language used to define a concept or a relation

Type

A differentiation of genus

Table 3. Attributes (14 Attributes in v3.0, last updated August 16, 2015)

III. Relations

Below is a list of all standard relationship labels (158 as of Aug, 2015) connecting different Concepts:

  

Abort

Adopt

Aggregate

Affect

Allow

Allow for

Analyse

Append

Approve

Arrange

Assemble

Assess

Analyse

Audit

Authorise

Build

Buy

Capture

Cause

Certify

Check

Choose

Classify

Complete

Collaborate with

Collate

Collect

Commission

Communicate with

Compare

Conduct

Confirm

Construct

Consult

Contact

Contain

Continue

Control

Coordinate

Decrease

Delimit

Deliver

Demolish

Demonstrate

Deselect

Design

Detect

Determine

Describe

Develop

Discover

Divide

Discuss with

Document

Draw

Educate

Empower

Encourage

Enforce

Engage with

Establish

Estimate

Exchange

Explode

Extract

Evaluate

Fabricate

Facilitate

Federate

Follow

Forecast

Function as

Gather

Generate

Guide

Has part

Has resource

Identify

Ignore

Implement

Improve

Incentivise

Increase

Inform

Initiate

Innovate

Integrate

Interchange

Interview

Invent

Involve

Join

Know

Lead

Link to

Locate

Maintain

Make aware

Make

Maintain

Manage

Maximise

Measure

Merge

Minimise

Model

Monitor

Notify

Observe

Operate

Own

Participate in

Perform

Plan

Populate

Prepare

Prescribe

Prioritise

Procure

Produce

Prove

Provide

Provide for

Pull

Push

Qualify

Quantify

Question

Receive

Recommend

Regulate

Reject

Replace

Require

Review

Revise

Run

Sample

Select

Share

Simulate

Size

Start

Stop

Supply

Survey

Test

Track

Train

Transfer

Transform

Transmit

Understand

Update

Use

Validate

Verify

Visualise

Warn

Write

 

Table 4. Relations (158 Relations in v3.0, last updated August 16, 2015)

IV. Knowledge Sets

Knowledge Sets are higher order Knowledge Objects composed of the other three lower order concepts, relations and attributes.

 

Name

Description

Example

1

Knowledge Foundations

A structured view of concepts and their relations. Knowledge Foundations include dictionaries, classifications, taxonomies, models, frameworks and theories

The BIM Ontology, The BIM Framework, Granularity Levels, Organizational Scales…

2

Knowledge Blocks

A self-contained knowledge item used to build larger knowledge structures  

A competency item, dictionary item, model use…

3

Knowledge Tools

An interactive view of concepts and their relations intended to assess, assist and educate its users. A tool has modifiable variables leading to varied outputs based on inputs

A calculator, an online tool, a cad software…

4

Knowledge Workflows

A repeatable set of activities conducted as part of a larger process to deliver a measurable outcome

An assessment methodology, a knowledge capture technique, a construction method, a verification routine….

5

Knowledge Views

A delimited self-contained view of multiple concepts and their relations - irrespective of knowledge content format (text, images or graphs) or knowledge content medium (hardcopy or softcopy)

A training manual, journal article, CAD drawing, poster, web page, video, concept map, repertory grid, process map, concept map, flowchart, Gantt chart…

Table 5. Knowledge Sets (4 sets in v3.1, last updated July 28, 2016)

 

 

Publication Log - Summary 

V.

Date

Description

1.0

18 Oct ‘07

Initial version submitted as part as a research proposal at the University of Newcastle, NSW

1.2

6 Dec ‘08

Published as Table 6 within Paper A2

2.0

13 Dec ‘13

Published as Appendix A of the PhD Thesis

3.0

16 Aug  ’15

First published on BIMframework.com

3.01

29 Apr  '16

2 new Concepts added, 1 Concept modified

 3.02

28 Jun '16

5 new Concepts added

3.03

2 Jul '16

1 Concept modified

3.10

28 Jul' 16

1 Concept added, 1 Knowledge Set renamed

3.11

21 Aug' 16

2 Concepts added

3.12

23 Jan' 2017

Removed the ‘active’ tone from all Relations. Added 1 Concept + 2 Relations. Modified 1 Concept

 

References

Cottam, H. (1999). Ontologies to Assist Process Oriented Knowledge Acquisition (Draft). Retrieved from http://www.inovexadvancedsolutions.ltd.uk/spede/default.htm

Gruber, T. R. (1995). Toward principles for the design of ontologies used for knowledge sharing? International journal of human-computer studies, 43(5-6), 907-928.  Retrieved from http://www.sciencedirect.com/science/article/B6WGR-45NJJDF-K/2/b47f5cb67315c76b60ac39f44e0a2cec

Milton, N. R. (2007a). Knowledge Acquisition in Practice: A Step-by-step Guide: Springer, London.

Milton, N. R. (2007b). Specification for the General Technological Ontology (GTO). http://www.pcpack.co.uk/gto/notes/files/GTO%20Spec%20v4.doc Retrieved from http://www.pcpack.co.uk/gto/notes/files/GTO%20Spec%20v4.doc

Noy, N. F., & McGuinness, D. L. (2001). Ontology Development 101: A Guide to Creating Your First Ontology. http://www.lsi.upc.edu/~bejar/aia/aia-web/ontology101.pdf Retrieved from http://www.lsi.upc.edu/~bejar/aia/aia-web/ontology101.pdf

Shanks, G., Tansley, E., & Weber, R. (2003). Using ontology to validate conceptual models. Communications of the ACM, 46(10), 85-89. doi:10.1145/944217.944244

Studer, R., Benjamins, V. R., & Fensel, D. (1998). Knowledge engineering: Principles and methods. Data & Knowledge Engineering, 25(1-2), 161-197.  Retrieved from http://www.sciencedirect.com/science/article/B6TYX-3SYXJ6S-G/2/67ea511f5600d90a74999a9fef47ac98

Succar, B. (2009). Building information modelling framework: A research and delivery foundation for industry stakeholders. Automation in Construction, 18(3), 357-375.  Retrieved from http://dx.doi.org/10.1016/j.autcon.2008.10.003

Succar, B., Sher, W., & Aranda-Mena, G. (2007). A Proposed Framework to Investigate Building Information Modelling Through Knowledge Elicitation and Visual Models. Paper presented at the Australasian Universities Building Education (AUBEA2007), Melbourne, Australia. http://aubea.org.au/ocs/viewpaper.php?id=15&cf=1

  


33. Difference between Lenses and Filters

  BIM Lenses and Filters

Lenses and Filters are investigative tools of enquiry and domain analysis allowing the discovery of concepts and relations. The difference between (BIM) Lenses and Filters can be summarised as such: Lenses are additive and are deployed from the ‘investigator’s side’ of BIM Field observation while Filters are subtractive and are deployed from the ‘data side’. Lenses highlight observables that meet research criteria and identify their relations; example, an infrared lens highlights heat sources in a scene. Filters remove observables that do not meet the research criteria; example, data filters hides non-conforming data within a spreadsheet.


12. BIM Capability Sets


  

BIM Capability Sets v4.1

Updated April 18, 2014... BIM Capability Sets is a taxonomy representing BIM Player’s abilities to satisfy a BIM Requirement or generate a BIM Deliverable. A BIM Capability Set is a hierarchical collection of BIM abilities identified using the BIM Framework ( (refer to Structure of BIM Capability Sets) for the purposes of BIM implementation and assessment. 

Please note that the term BIM Capability Sets is used for staged capability improvement at Organizational Scales 1-10 (thus excludes OScales 12 Individual and 11 Group). It should not be confused with the BIM Competency Hierarchy (with Competency Tiers, Competency Sets and Competency Topics), the taxonomy used for contiuous performance improvement at OScales 9-12.


8. Project Lifecycle Phases

BIM - Project LifeCycle Phases

Fig.1 Project Lifecycle Phases, and sub-phases 

 

  Project_Lifeycle_Phases_3_BIM_Stages

 

Fig.2 Effect of BIM on Project Lifecycle Phases

Construction projects pass through three major Project Lifecycle Phases (PLP)s: Design [D], Construction [C] and Operations [O]. These phases are also subdivided into sub-phases which are in turn further subdivided into activities, sub-activities and tasks. This conceptual model (Fig. 2) depicts the effects of BIM on project lifecycle phases over the three BIM Stages.


7. Field Overlaps

 

  BIM-Fields-Overlaps

The three BIM Fields overlap as they share players and deliverables. This overlap between fields occurs when:

(1) A deliverable requires players from two or more fields. For example, the development and  implementation of Industry Foundation Classes (IFC) across the construction industry require the joint efforts of Policy players (researchers and policy makers) and Technology players (software developers).

(2) Players pertaining to one field generate deliverables classified in another. For example, the Australian Institute of Architects is an ‘industry body’ whose members are Process players (architects) generating Policy deliverables (guidelines and best practices) rather than Process deliverables (building designs and construction details).

Legend: the letters within the model correspond to the following overlaps:

(a) Sample Policy-Process overlap: Industry body (BIM player) and Continuous Professional Development (CPD) training (BIM deliverable);

(b) Sample Policy-Technology overlap: Interoperability standards (BIM deliverable);

(c) Sample Process-Technology overlap: Communities of Practice  (BIM player); and

(d) Sample Policy-Process-Technology overlap: BIM Implementation (BIM deliverable), BIM specialists – individuals and groups (BIM players). 


6. Field Interactions

BIM-Interactions-Fields-and-sub-Fields

 

BIM Interactions are push-pull knowledge transactions occurring within or between BIM Fields and sub-Fields. Push mechanisms transfer knowledge to another field or sub-field while pull mechanisms transfer knowledge to satisfy a request by another field or sub-field. Sample transactions include data transfers, team dynamics and contractual relationships between fields and sub-fields.

 

 

   

Policy Field

Process Field

Technology Field

Sample interactions between fields and sub-fields

Push into other fields

- Skilled graduates, standards, guidance into Process

- Concepts, mathematical solutions into Technology

-Case studies  into Policy

-Feedback to Technology

Innovative solutions and new equipment  into Policy and Process

Pull from other fields

- Subject matter experts from Process

-Interoperability from Technology

-Development of solutions from Technology

- Standards, guidelines and graduates from Policy

-Standardisation efforts from Policy

-Requirements and experiences from Process

Push-Pull within the same field

Interchanges between research, education and accreditation boards

Architect’s Instructions (AI-push) and Request Further Information (RFI-pull)

Hardware capabilities (push) and software requirements (pull)

 


4. BIM Lenses

BIM_Lenses

BIM Lenses represent the third dimension of the Tri-Axial Model and generate its depth of enquiry. BIM Lenses are distinctive layers of analysis applied to Fields and Stages to generate Knowledge Views. They abstract the BIM domain and control its complexity by removing unnecessary detail. Lenses allow domain researchers to selectively focus on any aspect of the DCO industry and generate knowledge views that either (a) highlight observables which meet the research criteria or (b) filter out those that do not.

Below is a short video briefly explaining the above on the dedicated BIM Framework YouTube channel:

 


3. BIM Stages

BIM-Stages-Linear-Model

The BIM Framework introduces the stages separating Pre-BIM (the status before BIM) from viDCO (virtually integrated Design, Construction and Operation) - the ultimate vision from implementing BIM. These revolutionary stages, and the evolutionary steps separating them, are intended to both clarify and measure BIM adoption.

Note 1: this model depicts BIM Capability Stages at Maturity Level C...Also, starting in Paper A4, the term viDCO replaces the term IPD as used earlier in Papers A2 and A3

Note 2: The ‘BIM Stages’ model was first introduced by the author through BIM ThinkSpace (Episode 8 – Feb 18, 2008) and then published in Paper A2 as ‘BIM Maturity Stages’. As of Paper A3, the BIM capability/maturity concept embedded in the original model was split into two metrics/models: BIM Capability Stages and BIM Maturity Levels.

Update (July, 2015) - below is a short video explaining the above on the Framework's YouTube channel: