40. Project Information Taxonomy

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

Project Information includes both Unstructured Project Information and Structured Project Information:

  • Unstructured Project Information refers to non-computable data, undocumented, and temporary project information (e.g. hand sketches and casual phone chats); and
  • Structured Project Information refers to information organised and formatted for particular purposes or use cases.

Project information can be represented, stored or exchanged as either Documents, Models or Data. These three Information Representation Types can be mapped against a number of new Information Management concepts – including: Information Delivery Format, Information Uses, Information Views, Information View Definitions, Information Viewers and Common Information Environments.

This is clarified in the below table, a ‘flat’ representation of the Project Information Taxonomy (slightly updated Nov 29, 2016):

Project Information Taxonomy - Table

INFORMATION REPRESENTATION TYPE How information is represented


A physical or digital medium (e.g. a paper or an email) carrying a variety of Information including text, Data (e.g. hexadecimal code) and embedded Models (e.g. a 3D PDF document) [Partially adapted from ISO 14050:2009 and ISO 9000:2005][1]


A digital three-dimensional representation of Information. A 3D Model may embed or reference both Data and Documents. The term ‘Model’ refers to both digital and physical models (e.g. a 3D printed shape) but does not refer to financial, mathematical or conceptual models…Also refer to BIModel[2]


A reinterpretable representation of Information which can be collected/parsed with or without the human actor. Data is either statically embedded within Documents and Models or drive their dynamic generation/modification [Adapted from ISO/IEC 2382-1:1993][3]

INFORMATION DELIVERY FORMAT How information is - or need to be - delivered on a project

Documented Project Information[4]

Project information collated within Documents for functional purposes. Documented Project Information are captured and exchanged either manually or through digital means, and are intended for use by the human actor (e.g. drawings, maps and reports)

Modelled Project Information

Project information collated within Models for functional purposes. Modelled Project Information are generated by the human actor or driven by machine-captured data (e.g. structural analysis and asset tracking)

Structured Project Data

Granular project information collated within Documents and Models, or driving the generation of Documents and Models; Structured Project Data are captured through sensors and scanners; derived from connected data sources; or generated through machine learning

INFORMATION USE The intended uses/applications of project information

Document Use

The intended or expected project deliverables from developing and exchanging information through Documents.

Examples: Master Plan Drawing or Minutes of Meeting.

Model Use

The intended or expected project deliverables from generating, collaborating-on and linking Models to external databases.

Example: model-based Urban Planning or Lighting Analysis.

Data Use

The intended or expected project deliverables from generating, exchanging and manipulating Data.

Example: Fabrication Scripting, using code to drive cutting, milling or sintering equipment.

INFORMATION VIEW How project information is represented to enable its use

Document View

A view representing one or more Document Uses. A Document View can be a drawing, schedule, report, an instruction memo or a set of specifications. A Document View may be analogue or digital, developed manually or derived automatically from a Model or Data source.

Example: A Room Data Sheet

Model View

A view representing one or more Model Uses. A Model View can be a static 3D view, an animation, a holograph or a 3D print. A Model View follows the specifications within its corresponding Model View Definition or reflects unique project requirements

Example: A Model View showing only Mechanical and Structural elements

Data View

A view representing one or more Data Uses. A Data View can be a code snippet, a Computer Numerical Control (CNC) file, an XML file or similar information not primarily intended for the human actor.

Example: An If This Then That (IFTTT) recipe or a visual script in Autodesk Dynamo

INFORMATION VIEW DEFINITION How Information Views are defined to enable the consistent use of Structured Project Information

Document View Definition

A specification which identifies the contents, attributes and formats of Document Views. Document View Definitions are typically generated by authorities and large clients.

Model View Definition (MVD)

A specification which identifies the properties and specifies the exchange requirements of Model Views. A 'standardised' Model view Definition (MVD) can be a subset of an established schema (e.g. the Industry Foundation Classes) and is typically intended for software developers (not end users) to implement into their BIM Software Tools.

Example: the IFC4 Design Transfer View by buildingSMART International

Data View Definition

A specification which identifies the properties and specifies the exchange requirements of Data Views. Data View Definitions are generated by Project Participants to formalise their data exchange scenarios

INFORMATION VIEWER The software allowing access to Structured Project Information by a solitary user

Document Viewer

A software application allowing users to inspect and manipulate of Structured Project Information according to pre-set Document Views.

Example: A PDF reader or a 2D CAD viewer

Model Viewer

A software application allowing users to inspect and navigate Modelled Information according to ad-hoc or standard Model View Definitions. As opposed to Model Servers, Models accessed by a Model Viewer are read-only and cannot be modified.

Example: Autodesk Navisworks or Solibri Model Checker

Data Viewer

A software application allowing users to inspect and manipulate data according to pre-set Data View Definitions. An example of a Data Viewer is an online project dashboard merging data from several sources

Example: Google Flux or Autodesk Forge Viewer

COMMON INFORMATION ENVIRONMENT The digital environment  allowing access to Structured Project Information by multiple concurrent users

Shared Document Environment

A central source for Documented Project Information. A Shared Document Environment is not necessarily a single software tool but a combination of several software solutions – including: a Document Management System, a Document Viewer, a Model Viewer, and a Project Management software. A Shared Document Environment may connect several software tools and desperate data sources through middleware and plugins

Federated Modelling Environment

A central source for Modelled Project Information used to collect, store and allow controlled access to model-based information by project/asset stakeholders. A Federated Modelling Environment differs from a Shared Document Environment by allowing the isolation of Structured Project Information by Model View

Integrated Data Environment

A central or distributed repository of Integrated Data feeding from multiple data sources and information systems across disciplines and domains. An Integrated Data Environment allows manipulation of data by multiple stakeholders according to access rights and agreed Data View Definitions


More info

This post is part of the of an 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 update-to-date description of these concepts and their relations, please refer to respective terms within the BIM Dictionary.



[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)

39. Model Uses Taxonomy

Model-Uses-TaxonomyFigure 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 -; (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:

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

30. Asset Hierarchy

Asset Hierarchy Across 3 Scales


This conceptual model (unpublished) is a taxonomic subdivision between three overlapping domains -  Building Information Modelling (BIM), Geographic Information Systems (GIS) and Product Lifecycle Management (PLM). The subdivision is based on four criteria (classes):

  • Asset Scale -  e.g. Built Environment or Building
  • Industry - e.g. Geospatial or Manufacturing
  • Applicable Acronym – e.g. BIM or PLM
  • Typical Unit of Measurement – e.g. Meters or Millimetres

Other criteria can be added to differentiate, qualify or compare the three domains

27. Conceptual Hierarchy

image from www.bimframework.infoConceptual Hierarchy Current Version, full-size image (older version v1.0)

The BIM framework is composed of several interrelated conceptual constructs: models, taxonomies, classifications and dictionaries. A common conceptual ontology connects all conceptual constructs and makes explicit the relationship between them. Below is a generic description of the depicted conceptual parts:

Frameworks show “the gestalt, the structure, the anatomy or the morphology of a field of knowledge or the links between seemingly disparate fields or sub-disciplines” (Reisman, 1994, p. 92).

Models (conceptual models) are simplified representations and abstractions of the “enormous richness of this world” (Ritter, 2010, p. 360) (Lave & March, 1993).

Taxonomies are an efficient and effective way to organize and consolidate knowledge (Reisman, 2005) (Hedden, 2010). A well-structured taxonomy allows “the meaningful clustering of experience” (Kwasnik, 1999, p. 24).

Classifications are the “meaningful clustering of experience” (Kwasnik, 1999, p. 24) and “lies at the heart of every scientific field” (Lohse, Biolsi, Walker, & Rueter, 1994, p. 36). Classification is also a heuristic tool useful during the formative stages of discovery, analysis and theorizing (Davies, 1989).

Dictionaries constitute a a web of meaning (Cristea, 2004) connecting terms to each other and to other knowledge bases.

25. Knowledge Content Taxonomy

  BIM Knowledge Content Clusters v1.2

Updated April 11, 2016: The Knowledge Content Taxonomy (KCT) - previously referred to as the BIM Knowledge Content (BKC) taxonomy - includes several classifications. The main one identifies three knowledge content clusters (guides, protocols and mandates) which are subdivided into eighteen knowledge content labels (e.g. report, manual, and contract). As described in the Noteworthy BIM Publications image, the KCT and its classifications are derived from the explicit ontological structures of the BIM Framework (Succar, 2009 - Paper A2) (Succar, 2013 - Thesis). KCT labels and clusters classify NBPs according to their actual knowledge content rather than according to each publication’s title or its specific – and sometime conflicting - use of terminology. A succinct definition of the three KCT clusters is provided below:

  • Guides: documents which are descriptive and optional. Guides clarify goals, report on       surveys/accomplishments or simplify complex topics. Guides do not provide detailed steps to follow to attain a goal or complete an activity;
  • Protocols: documents which are prescriptive and optional. Protocols provide detailed steps or conditions to reach a goal or deliver a measureable outcome. While documents within this cluster are prescriptive, they are optional to follow unless dictated within a Mandate (see next cluster); and
  • Mandates: documents which are prescriptive and dictated by an authority. Mandates identify what should be delivered and – in some cases – how, when and by whom it should be delivered.

When used to assess NBPs, the three KCT clusters would inform country-scale BIM maturity assessment. For example, a country, with all its NBPs pertaining to a single cluster (e.g. guides – descriptive and optional), would arguably face different implementation challenges to those faced by a country with its NBPs distributed across guides, protocols and mandates.

Updated Feb 14, 2018 (removed an example): below is the BIM Knowledge Content taxonomy (v1.35): 18 content labels in three content clusters as republished in Paper B1:







Best Practice

Operational methods arising from experience; promoted as advantageous; and replicable by other individuals, organizations and teams. This label applies to publications which list unambiguous and detailed recommendations, and which if applied as recommended, generate similar advantageous outcomes



Case Study

Summary and analysis (descriptive or explanatory) of projects and organizational efforts. This label applies to both research and industry publications which share lessons learned by others, and cover BIM deliverables, workflows, requirements, challenges and opportunities



Framework or Model

Theoretical structures explaining or simplifying complex aspects of a domain by identifying meaningful concepts and their relationships




Compilation of several BIM content types with the aim of providing guidance to individuals, teams or organizations. Guides typically provide insight into a complex topic (e.g. BIM Implementation Guide or Facility Handover Guide). Guides typically focus on knowledge-intensive topics, while Manuals (a complementary label) focus on skill-intensive ones. Due to the generic nature of this label, it should not be applied in isolation but in conjunction with other labels



Learning Module or Material

All types of analogue and digital media (e.g. printed manual or online videos) which deliver conceptual or practical insight intended/suitable for education, training or professional development within industry or academia




Compilation or summary of results arising from an assessment, calculation or review process (e.g. BIM capability report or profitability statement)



Strategy or Vision

Articulation of vision, mission and long-term goals. This label applies to publications which identify a long-term strategy (and possibly middle-term goals/milestones) but without identifying the resources required and detailed steps needed to fulfill the strategy



Taxonomy or Classification

Classification covering roles, types, levels, elements and other structured concepts. This label applies to publications which introduce classifications of five or more items within a structured list; and which have a clear use in assessment, learning or implementation (e.g. construction elements, BIM roles, data exchange types or levels of detail)



Metric or Benchmark

Tools and criteria suitable for establishing levels of performance of systems, projects, individuals, teams, organizations and other organizational units[1]. This label applies to publications which include tools or explicit metrics/indicators for establishing usability, profitability, productivity, competency, capability or similar




A structured document which is intended to clarify the steps needed to perform a measureable activity or deliver a measureable outcome (e.g. BIM Training Manual). Manuals typically focus on skill-intensive topics, while Guides (a complementary label) typically focus on skill-intensive ones. Due to the generic nature of this label, it should not be applied in isolation but in conjunction with other labels




A document describing activities to be performed, resources to be used and milestones to be reached within a defined timeframe. This label applies to publications describing – in adequate detail - how a specific strategy can be fulfilled or a pre-defined goal can be reached (e.g. a BIM Implementation Plan detailing how to fulfill a BIM Capability Strategy)



Procedure or workflow

Structured information covering successive steps needed to fulfill an operational, rather than strategic, requirement. A documented Procedure includes the small steps needed to deliver, if executed by a competent individual, a pre-defined and desired outcome. A Workflow identifies major successive activities to be performed and decision gates to pass-through towards reaching a delivery milestone or fulfilling a project/organizational objective



Protocol or Convention

Agreed or customary method of product/service development or delivery which are not by themselves contractually binding (e.g. keeping minutes of meetings, how to name files and frequency of exchanging models)



Specification or Prescription

A set of criteria used to define or judge the quality of products (e.g. object dimensions or data richness) and services (e.g. timeliness). Specifications may or may not be a Standard (a separate label)



Standard or Code

Detailed set of product/service descriptions (prescriptive or performance-based) acting as a reference to be measured against. This label typically denotes a set of specifications (a separate label) which are authoritative and test-proven (e.g. barrier-free or accessibility standards)



Contract or Agreement

Legally-binding document and its subparts – including contractual additions, amendments and disclaimers. This label applies to contracts and clauses, not to publications describing or promoting them (e.g. the label applies to AIA Documents E203, G201 and G202 but not to the AIA IPD guide)



Program or Schedule

A document associating one or more classification to time and/or location. For example, a BIM competency improvement program is a document linking BIM competencies, BIM roles (and possibly other classifications) to a timeline or target dates



Requirement, Rule or Policy

Expectation or qualification mandated by clients, regulatory authorities or similar parties. This label applies to publications with explicit identification of requirements to be met (e.g. organizational capability or previous experience) or products/services to be delivered (e.g. a tender/bid document)

[1] There are 12 organizational units, each with their own unique metrics (refer to Building Information Modelling Maturity Matrix (Succar, 2010).


24. Noteworthy BIM Publications

  Noteworthy BIM Publications Map v1

Noteworthy BIM publications (NBP)s are publically-available documents developed by various industry and academic entities; aimed at a wide audience; and intended to promote BIM understanding, regulate BIM implementation or mandate BIM requirements. These publications encapsulate extensive BIM-focused knowledge; collate significant domain expertise; and represent a substantial effort within the BIM domain.

NBPs are identified based on explicit ontological structures derived from the interaction of BIM Fields and BIM Lenses:

  • NBPs are documents (i.e. not websites, blogs or similar);
  • NBPs reflect BIM knowledge (i.e. publications focused on BIM skill are excluded);
  • NBPs are the deliverables of BIM players (i.e. publications delivered by players from other industries are excluded);
  • NBPs cover relevant BIM topics (i.e. publications covering pre-BIM topics are excluded);
  • NBPs are macroscopic (i.e. documents aimed at small groups of practitioners or students are excluded); and
  • NBPs are selected and organized by country of origin

Using these framework-based delimitations, NBPs represent numerous types of published documents spanning industry initiatives, peer-reviewed journals, self-published books and other noteworthy publications.

19. Competency Units of Analysis

Competency Units of Analysis v1.2

This conceptual model identifies several units for the purposes of competency analysis:

  1. Individual competency is the unit measure of an individual’s ability to conduct an activity and deliver an outcome. Individual competency applies to a single person irrespective of role, position or employment status;
  2. Group competency is the arithmetic sum of several individual competencies but – as a measure - does not reflect the efficiencies gained or lost from such an aggregation;
  3. Organizational capability is the unit measure of an organization’s ability and its sub-organizational units (branches, departments, business streams, etc.); and
  4. Team capability is the unit measure of team members’ combined abilities. As opposed to group competency, team capability reflects the routines and dynamics of aggregation (e.g. team compatibility, communication and collaboration). There are at least three sub-units of team capability:
  • Work Team (WT) capability applies to a purposeful group of individuals working together to deliver a project/outcome within an organization or an organizational unit;
  • Project Team (PT) capability applies to a purposeful group of individuals working together to deliver a project/outcome across two or more organizations; and
  • Organizational Team (OT) capability applies to two or more organizations working together (through partnering, alliancing, etc.) to pursue a common mission or deliver a common project/outcome.

17. Competency Hierarchy

  BIMe Competency Hierarchy v1.3

The BIM Competency Hierarchy includes three BIM competency tiers which are divided into several BIM competency sets which are, in turn, subdivided into BIM competency topics. These tiers, sets, topics - and their granular subdivision into competency items - represent all the measureable abilities, outcomes and activities of individuals who deliver model-based products and services.

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.

11. Organizational Hierarchy


Organisational Hierarchy v2.0

Full-Size Image  (1.6MB)

The Organizational Hierarchy is a conceptual model based on the Organizational Scales' taxonomy which identifies 12 organizational scales ranging from Markets (OrgScale 1, the largest) to Individuals (OrgScale 12, the smallest). The 12 OrgScales belong to three OrgScale Clusters: Macro (1-7), Meso (8) and Micro (9-12).

The 12 OrgScales are:

  1. Global Market
  2. Defined Market (e.g. European Union or individual countries)
  3. SubMarket (e.g. regional, state or local markets)
  4. Industry (e.g. Construction Industry)
  5. Sector (e.g. Design or Construction Sectors)
  6. Discipline (e.g. structural or mechanical disciplines)
  7. Specialty (e.g. steel detailing or kitchen design specialties)
  8. Organizational Team (e.g. two or more organizations working on the same project)
  9. Organization (e.g. an engineering or construction company)
  10. Organizational Unit (a department, branch or business stream)
  11. Organizational Group (a group of individuals or a 'work team')
  12. Organizational Member (an individual)

The hierarchy is used as a Scoping Lens to isolate a specific scale of BIM Players thus enabling a more-targeted approach to BIM implementation and assessment.