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:
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.
Updated Dec 6, 2020 | The Information Cycle Model (previously Information Management Cycle model) employs the three Project Lifecycle Phases – Design, Construction, and Operation (Succar, 2009) [1]– to identify Information Actors and their high-level Information Actions connecting several Information Milestones within the Lifecycle Information Transformation and Exchange (LITE) framework (Succar and Poirier, 2020) [2].
Information Cycle Model | v0.7 at OScale 8, GLevel 2 | Full Size
This high-level conceptual model – covering OScale 8 [3], shown at GLevel 2 [4] - describes the Information Cycles that Structured Information pass through. Each Cycle has a nominal start (e.g. information covering the design of a new Physical Asset) and a nominal end (e.g. information decimated through the demolition of an asset). If the same Physical Asset is iteratively renovated or reused, the information persists over many Cycles.
The Cycle connects four Information Milestones derived from the LITE framework and forming a rotating triangle (3 vertices). The first vertex [i] represents both Expected Physical Assets and Targeted Digital Deliverables (Information Milestones 3 and 4). The second vertex [ii] represents Actual Digital Deliverables (Milestone 6), and the third vertex [iii] represents the Actual Physical Assets (Milestone 7). These three vertices are connected by Information Actions conducted by Information Actors.
As discussed in the LITE framework, Information Actions may either be Forward Execution Actions, connecting one Information Milestone to the next one in the Information Cycle, or Reverse Measurement Actions, needed to verify the accuracy, validity, and quality of an Information Milestone against a previous one. In the model, three primary forward actions are shown - Prepare, Manage, and Use:
This conceptual model and the overall LITE framework does not differentiate between human and machine Actors, nor between discipline and information Actors (i.e. between a design professional and the design information manager) as the separation between these Actors– due to automation and Artificial Intelligence (AI) – is progressively blurring. That is, Actors can be humans, machines (computers/robots), and their hybrids (augmented humans or humanoids/cyborgs) who are (i) acting on existing information to generate new information, (ii) transforming inputs into outputs, and (iii) delivering products and/or services. A Single Actor may be acting alone throughout the whole project/asset lifecycle (e.g. a human Actor designing, constructing, and living in their own forest cabin, or an AI-enabled machine designing, delivering, and utilising a complex mineral-extraction facility on Mars). Multiple Actors may also be acting in sync/sequence at different phases of an asset’s lifecycle to design, deliver, and utilise an asset.
The model identifies three nominal Actors operating throughout the Information Cycle:
Actors may overlap and replace one another. Depending on Asset Scale [8] and the diffusion of technologies, processes, and policies within a market (Succar & Kassem, 2015) [9], two or even a single Information Actor may be able to conduct all execution and measurement actions across an Information Cycle.
This post includes an updated visual knowledge model (v0.7) and updated explanatory text to align with the now published LITE framework (Succar and Poirier, 2020). The original version 0.3 – Information Management Cycle model - was published through this blog on July 25, 2017 and can still be accessed as an image file from here (v0.3 was reviewed by Dr. Sheryl Staub-French, Dr. Julie Jupp, Dr. Marzia Bolpagni, and Mr. Victor Roig Segura). An updated version 0.5 was later published in Jan 21, 2018 and included important modifications – image file can be accessed from here. For a more detailed review, the updated post including the v0.5 model is available for download as a pdf file from here (148KB).
[1] Succar, B. (2009). Building information modelling framework: A research and delivery foundation for industry stakeholders. Automation in Construction, 18(3), 357-375. DOI: https://doi.org/10.1016/j.autcon.2008.10.003
[2] Succar, B., & Poirier, E. (2020). Lifecycle information transformation and exchange for delivering and managing digital and physical assets. Automation in Construction, 112, 103090. http://bit.ly/PaperA11
[3] There are 12 Organisational Scales – refer to Post 11 https://www.bimframework.info/2013/12/organizational-hierarchy.html
[4] Granularity Levels clarify the extent of informational detail within a conceptual model, matrix, tool, or document. There are five Granularity Levels (GLevels) progressing from lowest to highest: https://BIMdictionary.com/en/granularity-level/1
[5] Scherer, R. J., & Katranuschkov, P. (2018). BIMification: How to create and use BIM for retrofitting. Advanced Engineering Informatics, 38, 54-66. DOI: https://doi.org/10.1016/j.aei.2018.05.007
[6] Hosseini, M. R., Roelvink, R., Papadonikolaki, E., Edwards, D., & Pärn, E. (2018). Integrating BIM into facility management: typology matrix of information handover requirements (Vol. 36)
[7] 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
[8] Asset Hierarchy and Asset Scale are covered in Post 30 - https://bimframework.info/2019/08/asset-hierarchy.html
[9] Succar, B., & Kassem, M. (2015). Macro-BIM adoption: Conceptual structures. Automation in Construction, 57, 64-79. DOI: https://doi.org/10.1016/j.autcon.2015.04.018
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:
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:
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 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. A Document View can be a drawing, schedule, report, an instruction memo, or a set of specifications. A Document View may be drafted (computer-assisted) by a human-actor 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 room layout, furniture, fittings, equipment, and surface finishes) |
Model View A view enabling one or more Model Uses. A Model View can be a static/ dynamic 3D view, an animation, or a holograph. A Model View follows the specifications within its corresponding Model View Definition or reflects custom project/asset requirements Examples: Model View showing only Architectural elements, or another showing both Mechanical and Structural elements within a Model Viewer (see further below) |
Data View A view enabling one or more Data Uses. A Data View can be a code snippet, a Computer Numerical Control (CNC) file, an XML/JSON file, or similar Examples: a data chart, a node-link diagram, an If This Then That (IFTTT) recipe, an FME translator, or a visual script in Grasshopper or Dynamo |
Information View Definition: How Information Views are defined for consistent use of information |
||
Document View Definition A specification (or template) which identifies the contents, attributes, and formats of Document Views (see above). Document View Definitions are typically generated by authorities, technology advocates, and associations promoting standardisation Examples: Product Data Template (a document identifying the information pertaining to a specified product - e.g. model, manufacturer, performance attributes, and maintenance requirements) |
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. Industry Foundation Classes), typically intended for software developers (not end users) to implement into their Software Tools (ISO, 2016) 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 typically generated by information actors to formalise data exchange scenarios and harmonise data analysis methods Examples: a data representation template, data translation script, or data analysis formula |
Information Viewer: The 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 or a 2D CAD viewer |
Model Viewer A software application allowing users to inspect and navigate Models according to ad-hoc or standardised Model View Definitions Example: BIM Vision, BIMx, Dalux, or Solibri Model Viewer |
Data Viewer A software application allowing users to inspect and manipulate data according to pre-set Data View Definitions Examples: Tableau or Business Intelligence tools |
Information Environment: The distributed digital ecosystem allowing the collation and utilisation of information by multiple stakeholders. An Information Environment may include a combination of software solutions connected to disparate data sources through middleware and plugins |
||
Shared Document Environment An ecosystem for managing documents, composed of several software modules – including a Document Viewer, and allowing the filtering of information by Document View Example: A digital ecosystem built around a Document / Project Management System |
Federated Modelling Environment An ecosystem for managing Models, composed of several software modules - including a Model Viewer, and allowing the filtering of information 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, composed of several software modules – including a Data Viewer, allowing the filtering of information by Data View Example: A digital ecosystem built around Data Warehousing and Data Integration solutions |
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.
[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:
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:
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:
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:
[2] The number of structures supporting a BIM Framework part is proportional to its conceptual strength.
Figure 1. The BIM ontology v3.1 (Neuron Model v0.4, Updated July 28, 2016)
IMPORTANT: newer versions of the BIM Ontology are published as a BIMe Initiative resource. As of July 28, 2017, the image above and the information below may be out of date.
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.
Figure 2. Visual Knowledge Model (left) + Concept Map (right)
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.
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)
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)
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)
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)
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)
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 |
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