
This numbered Frameworks Page covers a single Visual Knowledge Model (VKM). Refer to Tags at the bottom for content classification and source publication if any. The page may be updated to connect with newer Frameworks Pages. The number is for pages, not for content.
Published on June 20, 2016 | Last Updated on September 20, 2025
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
Information Use: The intended uses/applications of information | ||
---|---|---|
Document Use
The intended or expected types of deliverables from developing and exchanging information through documents. Examples: Document-based reporting, certifying, or warranting. |
Model Use
The intended or expected types of deliverables from generating, collaborating on, and linking models to external databases. Examples: Model-based representing, simulating, or quantifying. |
Data Use
The intended or expected types of deliverables from generating, exchanging, and manipulating data. Example: Data mining or scripting (e.g., using code to drive cutting, milling, or sintering equipment). |
Information View: How information is represented to enable its use | ||
Document View
A view enabling one or more Document Uses, such as drawings, schedules, reports, instruction memos, or specifications. It may be drafted (computer-assisted) by a human or derived automatically from a model or data source. Example: Product Data Sheet or Room Data Sheet (a drawing detailing an operator’s requirements for each room type, including layout, furniture, fittings, equipment, and surface finishes). |
Model View
A view enabling one or more Model Uses, such as static/dynamic 3D views, animations, or holographs, following specifications in its corresponding Model View Definition or custom project/asset requirements. Examples: Model View showing only architectural elements or both mechanical and structural elements in a Model Viewer. |
Data View
A view enabling one or more Data Uses, such as code snippets, CNC files, or XML/JSON files. Examples: Data charts, node-link diagrams, IFTTT recipes, FME translators, or visual scripts (e.g., Grasshopper, Dynamo). |
Information View Definition: How Information Views are defined for consistent use | ||
Document View Definition
A specification or template identifying the contents, attributes, and formats of Document Views, typically generated by authorities, technology advocates, or standardization bodies. Example: Product Data Template (a document identifying information for a specified product, e.g., model, manufacturer, performance attributes, and maintenance requirements). |
Model View Definition (MVD)
A specification identifying properties and exchange requirements of Model Views, often a subset of schemas like Industry Foundation Classes (IFC), intended for software developers to implement in software tools (ISO, 2016). Example: IFC4 Design Transfer View by buildingSMART International. |
Data View Definition
A specification formalizing properties and exchange requirements of Data Views to harmonize data exchange and analysis methods. Examples: Data representation templates, translation scripts, or analysis formulas. |
Information Viewer: Software allowing access to information by human actors | ||
Document Viewer
A software application allowing users to inspect and manipulate information according to pre-set Document Views. Examples: PDF reader, 2D CAD viewer. |
Model Viewer
A software application allowing users to inspect and navigate models according to ad-hoc or standardized Model View Definitions. Examples: BIM Vision, BIMx, Dalux, Solibri Model Viewer. |
Data Viewer
A software application allowing users to inspect and manipulate data according to pre-set Data View Definitions. Examples: Tableau, Business Intelligence tools. |
Information Environment: The distributed digital ecosystem for collating and utilizing information | ||
Shared Document Environment
An ecosystem for managing documents, including a Document Viewer, allowing filtering by Document View. Example: A digital ecosystem built around a Document/Project Management System. |
Federated Modelling Environment
An ecosystem for managing models, including a Model Viewer, allowing filtering by Model View. Example: A digital ecosystem built around a Model Server or BIM-enabled Software as a Service (SaaS). |
Integrated Data Environment
An ecosystem for managing data sets and structures, including a Data Viewer, allowing filtering by Data View. Example: A digital ecosystem built around Data Warehousing and Data Integration solutions. |
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)
Cite as: BIMe Initiative (2025), '40. Information Taxonomy', https://bimexcellence.org/frameworks/project-information-taxonomy/. First published 20 June 2016. Viewed 27 September 2025