Updated August 9, 2019 (Original post October 23, 2014): To enable the definition of physical deliverables (Physical Assets) in a flexible manner, the concept of Asset Unit is needed (to be covered in a separate post). An Asset Unit combines: (i) a variable Asset Scale (e.g. a component, an assembly, a building, or a whole city) derived from the Asset Hierarchy (see below), with (ii) an Asset List defined by the Demand Entity (Employer, Client, Appointing Party) within an Information Cycle (a list of assets to be designed delivered, and/or utilised), and (iii) Asset Attributes derived from the Conceptual (BIM) Ontology (e.g. Asset Function, Asset Location, and Asset Cost).

Asset Hierarchy – v2.0, 2018 (full size image) - Link to older version (v1, 2011) 

The Asset Hierarchy organises Physical Deliverables/Assets by relative scale by combining taxonomies developed by OSCRE[1] and Transport for North South Wales[2]. The diagram does not differentiate between assets – Buildings as a sample scale - by their size, monetary value, location, or designated function[3] - e.g. Cultural, Transportation, or Recreation[4] but by their granularity relative to each other. The diagram includes a numbering system (scale 10-70) to establish an Asset’s relative position on the scale. The diagram also highlights how:

• The Assets Scale bridges the semantic and informational divide between three complementary industries and their respective information domains. At the upper-end of the scale, the Geospatial Industry and its Geographic Information System (GIS) domain overlaps with the Construction Industry and its BIM domain; while at the lower-end of the scale, it overlaps with the Manufacturing Industry and its Product Lifecycle Management (PLM) domain[5].
• An Asset can be a member of three Asset Clusters:
  • An Asset Portfolio (scale 300) is a clustering of assets for the purposes of strategic investment, operation, and management. Asset Portfolios may also be referred to as ‘asset groupings’ or ‘asset systems’[6];
  • A Modular Assembly (scale 500) is a functional clustering of assets for the purposes of Design for Manufacturing and Assembly (DfMA) and similar offsite methods. Examples of Modular Assemblies and Sub-Assemblies include prefabricated houses, pre-assembled mechanical risers, and pre-constructed wall sections[7]. Treated as a single Asset Unit, a Modular Assembly can be (a) first developed and tested in digital space; (b) prototyped, manufactured, constructed, and/or pre-assembled offsite; (c) packaged and readied for transportation; (d) transported for storage on site or delivered Just-In-Time (JIT); and (e) unpacked, erected, and/or assembled; and
  • A Temporary Package (scale 700) is a clustering of assets for the purposes of transportation and storage logistics. Examples of Temporary Packages include standardised shipping containers and logistical package[8]. Temporary Packages also include bundled materials (e.g. a sandbag, load, or palette).
• Systems are treated as dynamic sub-scales that – depending on the Physical Asset being measured – may be more/less granular than other assets. Systems span the entire hierarchy (from scale 15 to 65) and can flexibly connect information deliverables and requirements across the BIM, GIS, and PLM domains.

Using a variable Asset Scale allows the dynamic assignment of less granular assets at the start of an information cycle. More information about how Asset Scales and Asset Units are used will be explained in future posts.

[1] Fuhrman, A. (2007). The Hybrid Taxonomy Real Estate Focus, The Open Standards Consortium for Real Estate (OSCRE).

[2] TfNSW. (2015). Systems Engineering, Transport for NSW, New South Wales Government (T MU AM 06006 GU). Retrieved from https://www.transport.nsw.gov.au/system/files/media/asa_standards/2017/t-mu-am-06006-st-v2.0.pdf Last accessed Aug 9, 2019

[3] Assets can be classified under many concepts which should not be combined in a single taxonomy. Information Actors will need to identify the number of classifications needed to manage their asset information. For example, an Information Actor may use three primary classifications to identify a Physical Asset: Asset Scale (e,g. Lighting System), Asset Function (Lighting), and Asset Location (e.g. In Room 391 or along Highway A5, Exit Ramp 17).

[4] OmniClass. (2013). OmniClass | Construction Classification System, Retrieved from http://www.omniclass.org/; and NBS. (2015). UniClass 2015 (1.7 ed.). Retrieved from https://buildig.com/uniclass-2015/ Last accessed Aug 9, 2019.

[5] Overlaps between the BIM and GIS/PLM domains are well-covered in: Song, Y., Wang, X., Tan, Y., Wu, P., Sutrisna, M., Cheng, J. C., & Hampson, K. (2017). Trends and Opportunities of BIM-GIS Integration in the Architecture, Engineering and Construction Industry: A Review from a Spatio-Temporal Statistical Perspective. ISPRS International Journal of Geo-Information, 6(12), 397; and in Jupp, J. R., & Singh, V. (2014). Similar concepts, distinct solutions, common problems: learning from PLM and BIM deployment. Paper presented at the IFIP International Conference on Product Lifecycle Management.

[6] ISO. (2014). ISO 55000:2014 Asset management - Overview, principles and terminology. Retrieved from https://www.iso.org/standard/55088.html Last accessed Aug 9, 2019

[7] BWTL. (2018). Platforms Bridging the gap between construction + manufacturing, Brydon Wood Technology Limited (BWTL) for the Centre for Digital Built Britain (CDBB), University of Cambridge. Retrieved from https://www.cdbb.cam.ac.uk/system/files/documents/2018Platforms_Bridgingthegapbetweenconstructionandmanufacturing.pdf Last accessed Aug 9, 2019

[8] Saghir, M. (2004). The concept of packaging logistics. Paper presented at the Proceedings of the Fifteenth Annual POMS Conference, Cancun, April.

BIMe Initiative Product Development Diagram (Updated Jan 21, 2018 | full size image)

This diagram illustrates the process of delivering a BIMe Initiative Product (a Published Guide or a Software Application): a Top-Level Project must be first launched. Each Top-Level Project typically includes both existing components (e.g. a taxonomy or a classification) and new components. Existing components are (a) selected from the Knowledge Object Library, a public resource available through BIMexcellence.org. New components (e.g. a framework or a software module) are (b) generated by BIMe Members through Micro Projects. Once completed and validated, all components are (c) packaged into a new BIMe Product. Once tested and verified, the new product is (d) released through the Product Library (a webpage on BIMexcellence.org) and all newly generated components are (e) added to the Knowledge Object Library for future reuse. As opposed to the Knowledge Object Library and the Product Library, which are both publicly available resources, the generation of new components and end products are conducted within the Project Space (wiki pages, chat rooms and physical meetings) which are accessible to BIMe Members and invited international collaborators.

To understand Conceptual Components (also referred to as Conceptual Constructs), please review the Conceptual Hierarchy and - as an example - how components populate the Research Continuum. Also, for more information about BIMe Initiative products, projects, and how they are managed, please refer to 103in BIMe Initiative Projects.

BIMe Initiative Knowledge Structure (full size image)

This model represents the Knowledge Structure which the BIMe Initiative (BIMexcellence.org) is reliant upon to deliver interconnected software applications, guides, conceptual structures and learning materials. The Knowledge Structure is composed of five complementary Knowledge Sets:

• KS1 Knowledge Foundations represents all the research supporting the BIMe Initiative;
• KS2 Knowledge Blocks represents the modular language developed/used by the BIMe Initiative to define inputs, processes and outputs;
• KS3 Knowledge Tools represents all the digital and analogue tools/templates used to conduct knowledge acquisition, engineering and sharing;
• KS4 Knowledge Workflows represents all repeatable procedures for knowledge acquisition and service delivery; and
• KS5 Knowledge Views identifies the varied ways the BIMe Initiative activities and deliverables can be represented and communicated.

The Knowledge Sets and their subsets form the bases for all BIMe Initiative Projects (refer to 103in); organise the activities of the BIMe Initiative Network (refer to 104in); and allow the development of an expansive Knowledge Object Library.

This conceptual model (Figure 1) identifies nine BIM player groups (industry stakeholders) distributed across three BIM Fields (technology, process and policy) as defined within the BIM Framework. The nine player groups are: policy makers, educational institutions, construction organisations, individual practitioners, technology developers, technology service providers, industry associations, communities of practice, and technology advocates.

Figure 1. Macro Diffusion Responsibilities v1.0 (full size, current version)

The nine player groups belong to either BIM Field or their overlaps. Pending further research, the tenth player group at the intersection of the three fields is intentionally excluded from this model. Table 1 below provides a succinct description of each player group followed by how this subdivision can be used in evaluating BIM diffusion within and across different markets.

Table 1. Macro Diffusion Responsibilities matrix (player groups with sample players – market scale)

Each of the nine player groups identified in Figure 1 includes a number of player types. For example, player group 3 (construction organisations) is composed of varied player types including: asset owners, architects, engineers and project managers. Also, player group 4 (individual practitioners) is composed of professionals, associated professionals and tradespeople. These distinctions between player groups, player types and unique players (e.g. a specific person, group, association, company or university) allow the targeted assessment and comparison of stakeholders’ involvement.

Below is a short video explaining the above, as available on the Framework's YouTube channel:

Please note that the above model and table are part of five macro adoption models collated within "Succar, B., & Kassem, M. (2015). Macro-BIM adoption: Conceptual structures. Automation in Construction, 57, 64-79". Download full paper from here: http://bit.ly/BIMPaperA8

Updated Feb 20, 2020, to align with Paper A11 - original June 20, 2016 (download), modified Nov 29 and Jun 20, 2019.

The Information Taxonomy (previously Project Information Taxonomy) extends the Modular Requirements Clarification Language first introduced in Paper A10. The taxonomy currently includes concepts/terms to be used in defining information requirements within mission-critical documentation (e.g. within an Employer’s Information Requirements (EIR), a BIM Management Plan (BMP) or similar).

The term ‘information’ – here used to describe Digital Assets - can be subdivided into three Information Representation Types or ‘digital artefacts’- documents, models, and data:

• Document: A medium (e.g. an email, web page, or a PDF document) carrying a variety of information including text, metadata, or embedded 3D models. A document refers to “information and its supporting medium” [i.e. when the information is placed within a medium, it becomes a document] ….“the medium can be paper, magnetic, electronic or optical computer disc, photograph or master sample, or a combination thereof” (ISO, 2009, Item 4.5), adapted from ISO (2015, Item 3.7.2). In this study, the term Document will refer to a digital medium or an analogue medium to be digitised in preparation for management and utilisation. When referring to non-digital documents, the term will be qualified (as in paper document). Examples of Documents include a Master Plan Drawing, a Performance Certificate, and an Audit Report;
• Model: A “representation of a system that allows for investigation of the properties of the system” (ISO, 2016). As a term, it may refer to digital models (e.g. shell/boundary or solid geometry graphical models); physical models (e.g. a sandcastle, LEGO model, or 3D printed shapes); or financial, mathematical, and conceptual models. In this study, unless qualified, the term Model will refer to a three-dimensional digital medium carrying a variety of information and – potentially - embedding or referencing both Documents and Data sets. A Model can represent a discipline/specialty (e.g. architectural model), a state (e.g. record model), or a base technology (e.g. object-based model); and
• Data: A digital sequence of symbols – typically letters and numbers - that can be collected and parsed/ interpreted by an actor. Data may be statically embedded within Documents and Models or drive their dynamic generation/ modification - adapted from ISO/IEC (2015). Data can be captured through sensors, actuators, and scanners (Gubbi, Buyya, Marusic, & Palaniswami, 2013); derived from connected data sources; or generated through machine learning. The term Data may be coupled with other terms preceding it (e.g. structured, unstructured, or meta-Data) or following it (e.g. Data cloud, object, routine, script, set, or table) to indicate either functional groupings, relationship structures, internal cohesion, semantic inferences, coded computer instructions, or ‘as a variety of charts and diagrams’ (Sowa & Zachman, 1992). In this study, and unless qualified, the term Data will refer to digital computable data. Data sourced from analogue devices (e.g. liquid thermometers and legacy imaging equipment) need to be digitised before it can be utilised and managed.

This representational subdivision is utilitarian and is intended for practical purposes: allow more accurate identification of targeted digital deliverables and – as illustrated in the Information Taxonomy below – provide flexibility in specifying information delivery uses, views, view definitions, viewers, and environments

Information Taxonomy - Table v2.0

More info

This post is part of the BIMe Initiative Integrated Information Platform project and contributes to the ongoing effort to clarify the language used (or to be used) in defining project requirements within Noteworthy BIM Publications. Some of the concepts introduced above are still being refined, connected and reconnected to multiple models, taxonomies and classifications. For an up-to-date description of these concepts and their relations, please refer to respective terms within the BIM Dictionary.

Endnotes

[1] A document refers to “information and its supporting medium” [i.e. when the information is placed on a medium, it becomes a document] … “The medium can be paper, magnetic, electronic or optical computer disc, photograph or master sample, or a combination thereof” – [SOURCE: ISO 14050:2009, 4.5 - adapted from ISO 9000:2005, 3.7.2]

[2] Another definition is a “representation of a system that allows for investigation of the properties of the system” [SOURCE: ISO 29481-1:2016(en) Building information models — Information delivery manual — Part 1: Methodology and format]

[3] “a reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or communication, or processing” [SOURCE: ISO/IEC 2382-1:1993, Information technology — Vocabulary — Part 1: Fundamental terms.01.01.02]

[4] Note: Documented Project Information should not be confused with Documented Information which is defined in ISO 9001:2015 as meaningful data that is required to be controlled and maintained by the organization and the medium on which it is contained (Source: ABP Consultant)

Figure 1. Model Uses Taxonomy (Full Size)

The Model Uses Taxonomy organises Model Uses into a tiered structure that allows: (a) collation of Model Uses from across different industries; (b) close alignment with the Competency Taxonomy (Succar et al., 2013 - http://bit.ly/BIMpaperA6); (c) custom use-cases for unique projects; and (d) future expansion towards whole of life cycle classifications.

The Model Uses Taxonomy includes 3 Categories and 9 Series:

Category I: General Model Uses represent all Modelling Information as applicable across various knowledge domains, industries, and information systems. General Model Uses are organised a single Series, General Modelling (1000-1990) and include the word ‘modelling’ in their name to differentiate them from other categories (e.g. Audio-visual Systems Modelling or Urban Modelling);

Category II: Domain Model Uses represent industry-specific Modelling Information. The Construction Domain Model Uses are organised in seven Series:

• Series 2: Capturing and Representing (2000-2990) - e.g. Photogrammetry or Record Keeping
• Series 3: Planning and Designing (3000-3990) - e.g. Construction Planning or Lean Process Analysis
• Series 4: Simulating and Quantifying (4000-4990) - e.g. Safety Analysis or Quantity Take-off
• Series 5: Constructing and Fabricating (5000-5990) - e.g. Casework Prefabrication or Sheet Metal Forming
• Series 6: Operating and Maintaining (6000-6990) - e.g. Asset Maintenance or Relocation Management
• Series 7: Monitoring and Controlling (7000-7990) -e.g. Building Automation or Performance Monitoring
• Series 8: Linking and Extending (8000-8990) - e.g.  BIM/PLM Overlapping or BIM/FM Integration

CATEGORY III: Custom Model Uses are a combination of General and Domain Model Uses to respond the non-typical requirements of a specific project. Custom Model Uses are organized under a single Series, Custom Modelling (9000-9990) - e.g. Modelling security systems for a correctional facility.

 Please Note:

1. The Model Uses Taxonomy was published as part of  BIM ThinkSpace Episode 24 (Sep 9, 2015).
2. Please also refer to earlier post: Model Uses Conceptual Structures (Sep 9, 2015)
3. There are currently 125 Model Uses across all categories and series (as of March 24, 2016). For a full list, please refer to BIMexcellence.org/model-uses.

The BIM Framework Conceptual Reactor v1.0 (full size, current version)

The BIM Framework Conceptual Reactor explains how existing conceptual constructs – terms, classifications, taxonomies, models and frameworks – are used to identify, explain and test new constructs.

The conceptual reactor thus allows the BIM framework to be continuously extended according to evolved research aims and objectives - represented as input 1 (or 'in1'). By integrating existing conceptual structures (in2) with new knowledge gained through literature reviews, and data collection (in3), the reactor can then generate new conceptual structures (output or ‘out’) after passing through an iterative, three-stage theory-building process. This process has been identified by J. Meredith (1993) (J. R. Meredith, Raturi, Amoako-Gyampah, & Kaplan, 1989) and includes three repetitive stages - description, explanation and testing:

• First, the Description Stage develops a description of reality; identifies phenomena; explores events; and documents findings and behaviours;
• Second, the Explanation Stage builds upon descriptions to infer a concept, a conceptual relationship or a construct; and then, develops a framework or a theory to explain and/or predict behaviours or events. In essence, the explaining stage develops a testable theoretical proposition which clarifies what has previously been described; and
• Third, the Testing Stage inspects explanations and propositions for validity; tests concepts or their relationships for accuracy; and tests predictions against new observables.

Model Uses are the “expected or intended project deliverables expected from generating, collaborating-on and linking 3D models to external databases” (BIM Dictionary, 2015). Each Model Use represents a set of defined requirements, specialised activities and specific project outcomes, grouped together under a single heading. 

Model Uses [1] rely on the conceptual structures of the BIM Framework, namely: the Tri-Axial Framework, Competency Framework, and BIM Ontology - Figure 1:

   Figure 1. Conceptual Structure underlying Model Uses (Full Size v0.3 or Older Version )

As highlighted in Figure 1, Model Uses are supported by three conceptual structures [2] - Updated May 2, 2016:

• Within the Tri-Axial Framework, Model Uses are deliverables [Tri-axial Framework>Fields>Field Components>Deliverables (Model-based Deliverables, identified through the Information Management Lens)] (refer to Papers A2 and A5);
• According to the BIM Ontology, a Model Use is a knowledge block [BIM Ontology>Knowledge Objects>Knowledge Sets>Knowledge Blocks> Information Uses > Model Uses] (refer to Thesis, Appendix A); and
• Within the Competency Framework, Model Uses are competency topics [Competency Framework> Competency Hierarchy>Competency Tiers (Domain)>Competency Set (Operation)>Competency Topics (9 Topics)] (Refer to Paper A6).

IV. Knowledge Sets

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

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

Publication Log - Summary 

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

The Point of Adoption (PoA) model is a distillation of three implementation phases: readiness, capability, and maturity. As a term, PoA identifies the juncture(s) where organizational readiness transforms into organizational capability/maturity. It also identifies the juncture(s) where technological invention and a procedural innovation transforms into organizational - as well as market wide - diffusion:

Point of Adoption model v1.1 (full size, current version)

As explored in Figure 1 above, transformative BIM adoption starts at the Point of Adoption (PoA) when an organization, after a period of planning and preparation (readiness), successfully adopts object-based modelling tools and workflows. The PoA[1] thus marks the initial capability jump from no BIM abilities (pre-BIM status) to minimum BIM capability (Stage 1). As the adopter interacts with other adopters, a second capability jump (Stage 2) marks the organization’s ability to successfully engage in model-based collaboration. Also, as the organisation starts to engage with multiple stakeholders across the supply chain, a third capability jump (Stage 3) is necessary to benefit from integrated, network-based tools, processes and protocols (refer back to BIM Stages).

Each of these capability jumps is preceded with considerable investment in human and physical resources, and each stage signals new organizational abilities and deliverables not available before the jump. However, the deliverables of different organizations at the same stage may vary in quality, repeatability and predictability (refer to BIM Maturity Index). This variance in performance excellence occurs as organizations climb their respective BIM maturity curve, experience their internal BIM diffusion, and gradually improve their performance over time[2].

The multiple maturity curves depicted in Figure 1 reflect the heterogeneous nature of BIM adoption even within the same organization (e.g. sample Organization X) has a compiled rating of 1c, 2b and 3a). This is due to the phased nature of BIM with each revolutionary stage requiring its own readiness ramp, capability jump, maturity climb, and point of adoption. This is also due to varied abilities across organizational sub-units and project teams: while organizational unit A1 (within Organization A) may have elevated model-based collaboration capabilities, unit A2 may have basic modelling capabilities, and unit A3 may still be preparing to implement BIM software tools. This variance in ability necessitates a compiled rating for organization A as it simultaneously prepares for an innovative solution, implements a system/process, and continually improves its performance.

Update (May, 2016): below is a short video explaining the above on the Framework's YouTube channel: