|
IFC 2x EXTENSION MODELLING GUIDEInformation Model Quality and Integration Guidelines for Models developed in conjunction with IFC 2x |
Part of the material for this documents had been developed as part of the work of the Integrated Building Plan, Integrated Building Services (IBP/IBS) Plan Checking System carried out for the Building Construction Authority of the Republic of Singapore.
This document provides guidance to projects on approaches to be adopted in developing IFC extension models. It is issued in conjunction with IFC 2x and contains guidance relevant to model development for Releases 3.0 and above.
|
Project Reference |
IFC Extension Modelling Guide |
|
Document Reference |
Extension Modelling Guide |
|
Version |
1.01 |
|
Date |
28th July 2001 |
|
Status |
Public |
|
Primary Editor |
Jeffrey Wix |
|
IAI Committee Responsible |
Model Support Group |
|
Distribution |
Public |
Version 1.00 - 30/06/2001 - Public release of Extension Modeling
Guide.
Version 1.01 - 28/07/2001 - Typographical error correction. New
footnote [4] added.
|
programme |
A schedule of actions |
|
|
program |
A sequence of executable instructions to a computer |
|
|
project |
An agreed programme of work for incorporation in the IFC specification |
|
|
model |
The complete information specification provided by an IFC release including the model, all data driven property sets declared external to the IFC Model and all associated documentation |
|
|
information model |
A formal statement of classes, attributes, and property sets declared in a formal definition language; normally the EXPRESS language defined in ISO 10303 part 11:1994 or the XML Schema Definition language (XSD) defined by the World Wide Web Consortium (W3C) |
The terms information model, product model, product data model and object model are also used to describe formal models. |
|
model driven property set |
A property set that is described as part of the model |
|
|
data driven property set |
A property set that is described externally to the information model but that is an element within the IFC Model. |
|
|
IM |
An abbreviation used that means 'information model' |
|
|
class |
A class identifies an entity type for which each instance has common properties. |
The term 'entity' is frequently used to represent the term class and vice versa. Either is considered to be acceptable in IFC development. |
This document provides guidance to projects on approaches to be adopted in developing IFC extension models. It is issued in conjunction with IFC 2x and contains guidance relevant to model development for Releases 3.0 and above. Its scope includes projects for the development of Industry Foundation Classes for the AEC/FM industry including the following topics:
The following topics are not within the scope of this document:
It is assumed that the reader is familiar with terminology in normal use within the AEC/FM industry.
1 Introduction
2 Approaches to Extension Model Development
2.1 Concepts exist in the IFC Model
2.2 Concepts extend the IFC Model
2.3 New concepts
3
Connecting the Extension Model to the Existing Model
3.1 Subtyping
3.2
Relationship
4 Creating a Preliminary Model
Subset
4.1 Stage 1: Identify Leaf
Nodes
4.2 Stage2: Identify Class
Hierarchy
4.3 Stage 3: Identify Attribute
Chains
4.3.1 Extended Attribute Chains
4.4 Stage 4:Prune Subtype and Select Lists
4.5 Stage 5: Close the Attribute Chains
5 Developing New Classes from Existing Classes
6 Putting New Classes into Extension Schemata
7 Modifications to Existing Classes
7.1 Adding Rules
7.2
Adding Inverse Attributes
7.3 Modifications
Not Allowed Within the IFC 2x Platform
8
Reusing Attributes and Properties
9 Usage
Definitions
10 Property Sets
10.1 What is a Property Set?
10.2 When Should a Property Set Be Used?
11. IFC Model Development Conventions
11.1 Notation and Language
11.2 Naming
11.3 Supertype/Subtype
11.4 Data Types
11.5 Relationships
11.6 References Between Layers
12 Checklist
Figure 1: Project development flowchart
Figure 2: Concepts for extending the IFC Model
Figure 3 Concepts existing in the IFC Model
Figure 4 Concepts extend the IFC Model
Figure 5 New concepts on top of the IFC Model
Figure 6: Subtypes across schema boundaries
Figure 7: Unresolved many to many relationship
Figure 8: Relationship class resolving many to many
relationship
Figure 9: Relationship class with
existing class as a related attribute
Figure
10: Tracing inheritance structure to IfcRoot
Figure 11: Identifying attribute chains
Figure 12: Pruning subtype lists
Figure 13: IfcRoot as the common supertype
Figure 14: IFC 2x Technical Architecture showing
schema modularity
Figure 15: Make the usage
definition precise
Figure 16: Where the IFC
Model terminates at 'leaf nodes'
The objective of this document is to provide guidance to projects on the development of IFC extension models that are integrated with the IFC 2x Model as far as possible. It is particularly concerned with the development of the model in the EXPRESS language. Refer to the IFC 2x Property Set Development Guide for information concerning the development of property sets in XML.
The intention is to assist developers within IFC projects by describing approaches that can be used to extend the model together with methods and rules that should be used in the work. By following the guidance, the resulting model delivered from the project will use the ideas and constructs that already exist within the IFC 2x Model fully and will be largely pre-integrated. This has the major benefit of making final integration of the project model into IFC by the IAI Model Support Group (MSG) much easier and less costly.
This document is not about the scope definition, project submission and requirements capture that are necessary actions prior to model development. It is assumed that these have occurred according to the current requirements of IAI and guidance given elsewhere[2]
From fig. 1 it can be seen that actions of MSG are:
This usually occurs at the same time that ITM approves the project (although it may occur later). Typically, integration will consist of two actions. The first will deal with the actual integration of the model whilst the second will check for quality assurance of the integrated moodel. It is anticipated that each action will be carried out separately although both are dealt with under the heading of 'integrator' in this Guide.
The project may request particular persons to be appointed for technical reasons.
This will usually occur at the time that model review is taking place.
This involves overviewing the model and testing the extent to which it has been pre-integrated and therefore assessing the workload for final integration. Providing that pre-integration has occurred and that the integration workload is as expected, the model will be accepted.
Final integration may involve amendments to the project model and/or documentation submitted where the MSG integrator can find a better, more flexible or more implementable model solution than that submitted.
On completion of the final integration process, the extension model is submitted to ITM for approval to release.
Figure 1: Project development flowchart
This section considers the various approaches that may be adopted for extension of the IFC Model. Extension is based on analysis of the gap that exists between concepts that need to be incorporated for the extension model development and concepts that already form part of the IFC Model. There are three scenarios that may be observed from gap analysis:
Figure 2: Concepts for extending the IFC Model
Concepts in the IFC Model means that the classes required by the extension model development already exist in the IFC Model and that the attributes of these classes fully capture the information requirements determined by the extension.
Additional information requirements determined by the extension are captured by:
Figure 3: Concepts existing in the IFC Model
Concepts extending the IFC Model means that classes required by the extension model development already exist within the IFC Model but that they need extension to fully capture additional information requirements.
Extended information requirements determined by the extension are captured by:
Figure 4: Concepts extend the IFC Model
New concepts means that the extension model development specifies information requirements that are not captured by classes at the interoperability layer or domain layer within the IFC Model. Therefore, new classes need to be specified that get support from the fundamental ideas within the resource layer (e.g. geometry, classification, etc.) and the core layer. The classes, relationships and attributes for new concepts need to be fully defined, including the connection to the other parts of the IFC Model.
New concepts determined by the extension are captured by:
Figure 5: New concepts on top of the IFC Model
There are two principal strategies for connecting classes within an extension model to classes already existing within the IFC 2x model. These are subtyping and relationship.
Subtyping means that a new class is created within the extension model as a subtype of a class within the existing model.
For example, IfcValve is a class that exists within the IFC Model that captures ideas about valves in general. In an extension model, there may be a need to extend the ideas about valves and to provide a separation between the concept of an isolating valve and a check valve. This is achieved by making a CheckValve and an IsolatingValve into subtypes of IfcValve. Using the IFC architecture rules, each subtype is exclusive (ONE OF). That means that a check valve cannot fulfil the role an isolating valve and an isolating valve fulfil the role a check valve[3].
Subtyping can be used across schema boundaries. That is, the supertype can exist within one schema and the subtypes within another schema. The subtypes reference the supertype within its schema.
Figure 6: Subtypes across schema boundaries
Another term used for subtyping is inheritance. This means that a subtype inherits all of the attributes (and constraints) of its supertype. It can then add further attributes as necessary.
For example, if the IfcValve class has attributes A,B, and C whilst the IsolatingValve has added attributes D,E and the CheckValve has added attributes F,G then:
WARNING
Subtype hierarchies can rapidly become quite deep. Even though the IFC Model has been designed to limit the depth of subtype hierarchies, its size means that subtype hierarchies can go to a maximum of 6 classes deep. Extension models could extend this depth.
When developing an extension model, the depth of the subtype hierarchy and the number of attributes that are inherited need to be carefully monitored.
Questions should be asked:
Relationship describes an association between classes. A relationship may be ‘objectified’ meaning that a class is inserted within the relationship for a particular reason. A class that results from an ‘objectified relationship’ is termed a ‘relationship class’ within IFC
One reason for adding a relationship class is to resolve a many to many relationship between two classes. Many to many relationships cannot be easily handled.
Figure 7: Unresolved many to many relationship
By adding a relationship class, the relationship is resolved. For instance, a space is bounded by many walls but equally, a wall may be considered to bound many spaces. This is a many to many relationship that means that the area of a particular wall bounding a space cannot be resolved. By adding a relationship class (RelWallToSpace in the example), this is resolved such that each RelWallToSpace object bounds only one space and is related to only one wall [4].
Figure 8: Relationship class resolving many to many relationship
Relationship classes are used extensively in the IFC Model. They provide a convenient means of:
Relationship classes provide a complementary strategy to subtyping for extending the IFC Model. In many cases, this is more flexible, convenient and effective. In the IFC Model, using a relationship class usually means that:
Figure 9: Relationship class with existing class as a related attribute
When a strategy of using a relationship class is adopted, care needs to be exercised in determining whether:
The IFC Model already contains relationship classes that fulfil many requirements. In most cases, it will be found that these can be used directly. These classes already have their relationships defined (usually at the kernel or core extension level of the IFC technical architecture). Therefore, there is no need to further elaborate the relationship within the extension model. To do so could mean redefining the factual relationship between classes and create implementation difficulties.
Where a new relationship class is required, it should be created as a subtype of IfcRelationship or one of its primary subtypes. To satisfy its use as a means of connecting an extension model, at least one of its attributes (relating or related) should point to a class that already exists within the IFC Model.
An extension model comprises two parts:
Before setting out to discover ideas that are not covered by the existing model, it is a good idea to establish exactly which ideas are covered. To do this, a ‘subset’[5] of the existing model should be defined. This can be done in five stages as follows
The leaf nodes are the terminal classes within the IFC Model i.e. there are no further classes beyond a leaf node class. Ultimately, they are the working classes within the IFC Model.
To establish a subset of the IFC Model, the leaf nodes that are required should be selected and listed. The example given below is the Move Management subset of the IFC 2x Model. It would serve as a preliminary implementation view for an extended move management model.
Having identified the leaf nodes, the class hierarchy should be followed back to the root class IfcRoot. The IFC 2x documentation is a valuable aid in doing this as each entity has its complete inheritance graph right back to IfcRoot. Therefore, creation of the class hierarchy should be quite a straightforward task.
Figure 10: Tracing inheritance structure to IfcRoot
The class hierarchy identifies the inheritance structure of the model subset. However, this does not create a complete subset.
A class has attributes that may be mandatory or optional to assert (i.e. use). An attribute may be:
Each of these attributes used by a class within the hierarchy must be included in the model subset. This includes both those attributes that are mandatory (must be asserted) and those that are optional but which may be used in the context of the subset.
An optional attribute that is not considered necessary for the subset does not have to be included. However, because the definition languages used for specifying exchange structure make provision for every attribute of a class, any attribute that is not used must be identified as such by an agreement relative to the model subset (by specification or by local implementers agreement).
It is by following the attribute chains across the model that classes from the resource layer are included within the subset (since they cannot appear within the class hierarchy).
An attribute of a class that is itself a class adds a further layer of complexity in the development of the model subset. This is because it will also have attributes that must or may be asserted. Therefore the extended attribute chain must be followed across the model until a termination point is reached.
Figure 11: Identifying attribute chains
As the class chains are followed across the model, it will often be found that classes that have many subtypes will be necessary to the model subset but that not every one of the subtypes will be necessary. In this case, the model subset can prune the subtype tree and dispense with the redundant subtypes. It will still be a true subset of the IFC Model.
The same situation may be found with select data types whereby not every branch of the select tree will be necessary. Again, pruning can be used so that only those branches of the select tree necessary are included in the subset.
The diagram below shows how IfcElement supertype uses only the subtypes IfcBuildingElement, IfcFurnishingElement, IfcElectricalElement, IfcEquipmentElement whilst IfcBuildingElement although having a very long list of possible subtypes only requires the inclusion of the IfcBuildingElementProxy subtype within this subset.
Figure 12: Pruning subtype lists
Not every optional attribute of a class will be needed for a model subset. In fact, following every optional attribute chain across the model would simply make the subset look almost the same as the whole model in many cases. This is not the objective of a model subset and it is not what is required within an extension model development.
Within the documentation for the final extension model, each optional attribute should be noted as to whether it is required or not required. For attributes that are not required, implementations of the extension model essentially create an agreement that identifies how the attribute will appear in an exchange. In a STEP Physical File this will be by using the unfilled attribute character $.
Note that in EXPRESS and XML, comments can be incorporated into a file. It is recommended that comments are used in conjunction with attributes not required by the extension model. For example, in EXPRESS this might take the form:
(* attribute not supported in extension model *)
Having completed the development of the extension model subset in EXPRESS, the existing property sets that are required by the extension model should also be identified. Property sets form an integral part of the IFC Model and this applies equally to an extension model.
Within the IFC Model, every class[6] MUST have a supertype that ultimately traces back to IfcRoot. This is because IfcRoot provides a number of basic services to all classes such as the provision of the unique identifier for any instance of a class.
Figure 13: IfcRoot as the common supertype
The exception to this is for classes that exist at the Resource layer of the IFC Technical Architecture. The reason for this is that instances of these classes only exist as attributes of instances of classes at the other layers of the IFC Technical Architecture (Core, Interoperability, Domain). Because of this ‘existence dependency’ identification of a Resource class is achieved by virtue of the identification of the class upon whose existence it depends.
The ultimate intention of the extension model development is to contain the new classes within one or more (usually one) new schema. This is the module that contains all of the ideas that are (currently) unique to the business case.
Figure 14: IFC 2x Technical Architecture showing schema modularity
The technical architecture for the IFC 2x Model identifies schema as existing in three states (see fig. 14 above):
Schema that are within the Platform cannot be changed in such a way as to make any existing exchange files invalid. This is less restrictive for schema that are candidates for inclusion within the platform. For schema that are not within the platform and are not yet candidates for inclusion, extensive change may be possible.
Rules may be incorporated within an EXPRESS schema definition but are not visible in a physical file exchange. Therefore, it is possible to add rules to existing classes to improve the quality of data exchange without impacting on exchange files previously generated.
An inverse attribute may be added to a class without impacting previously generated exchange files since an inverse attribute is not visible in a physical file exchange. However, this should be done with caution since an inverse can only be made on an existing attribute if it is not to have an impact.
The following modifications to attributes must NOT be made to any published IFC schema by a prooject; otherwise previously generated exchange files will not be valid:
Proposals for changes to any class that is not within the IFC 2x Platform may be made to MSG.
In many cases where an attribute is to be added to a class or a property to a property set, it will be found that the same or a similar attribute or property has already been specified for use elsewhere within the IFC Model. Previous usage will be well defined and documented.
Unless there is a very good reason otherwise, extension model developments should try to use the same attribute names and definitions as already exist within the IFC Model to express the same or a similar idea. This minimises conflict and confusion for organizations that will implement the extension model.
In many cases, whilst information may be provided in terms of attributes, it may not be possible within the formal definition of a class to be precise about how that information should be interpreted by software implementations. In these cases, it is necessary to provide documentation that makes it clear as to exactly what interpretation is intended. This should be done by providing usage definitions for the class. Usage definitions may be particularly important for geometry interpretation, but can also be important in giving clear guidance to software developers for interpretation of non-geometric information.
For instance, within the IFC Model there is a defined data type IfcLengthMeasure that is defined as ‘A length measure is the value of a distance’. In general, length is interpreted as a distance measured along the X-axis for a coordinate system that has been oriented t be local to the object. Similarly, breadth or width may be interpreted as a distance measured along the Y-axis and height as a distance measured along the Z-axis. To be precise about what these terms then mean in the context of a particular object therefore requires that there is a common understanding of how the local coordinate system for the object is interpreted.
Figure 15: Make the usage definition precise
The example above shows that by placing and orienting the local coordinate system differently, the meaning of the terms ‘length’ and ‘width’ can vary. Practically, this could mean (say) a beam being oriented 90 degrees from the position that was intended.
The number of different types of object that can possibly occur within the AEC/FM world is huge. It is virtually impossible to develop a model that can contain a complete description of every one of these object types for every purpose for which it may be required. However, it is possible to develop a model that provides a framework of the key ideas within AEC/FM and then provide the possibility for the model to be extended by project, local, national or regional agreements. The capability for extension is provided by the IFC Property Set.
Figure 16: Where the IFC Model terminates at 'leaf nodes'
The IFC Model develops ideas down to ‘leaf nodes’. A leaf node is a generalized semantic concept. It is a concept such as door, window, beam, column etc. The principal attributes that define the generalized concept are defined at the level of the class within the IFC Model.
Below the leaf nodes, further development of the model is achieved by defining IFC Property Sets. Whilst a Property Set may be specified within the model, it is more normal for it to be developed outside of the model.
An IFC Property Set is a container that holds collections (or sets) of properties. A property set is (normally) defined externally to the IFC Model[7].
The IfcPropertySet class defines a framework within which properties may be declared. Within this framework, any property that conforms to one of the allowed property types can be included. There is no limit to the number of properties that can be defined within a property set.
The types of properties that can be contained within a property set include:
Essentially, an IFC Property Set is a collection of properties that ultimately resolve to simple data types (REAL, INTEGER, STRING etc.).
The following are circumstances when it may be appropriate to consider using a data driven property set rather than defining a class with attributes within the IFC Model.
This section sets out the conventions, rules and guidelines that have been adopted for the IFC 2x Model development These cover all parts of the model including the use of EXPRESS-G graphical notation, the EXPRESS data definition language, schema, classes and property sets. Extension model development should follow these conventions.
The preferred graphical notation for process modeling is the IDEF0 notation in accordance with Federal Information Processing Standard (FIPS) 183. Whilst this is the preferred notation, other notations may be used where they satisfy the requirements and/or understanding of groups developing IFC extension models.
The graphical notation used within the IFC Model is EXPRESS-G in accordance with ISO 10303 part 11. The representation of the IFC Model in EXPRESS-G is informative
The data definition language used within the IFC Model and extensions is EXPRESS in accordance with ISO 10303 part 11. The representation of the IFC Model in the EXPRESS language is the formal (normative) representation.
The language used in the development and documentation of the IFC Object Model is English. The spelling of all words follows the conventions of American English usage. That is, use 'z' in words such as organization, use 'or' in words such as color and labor etc.
All names of schema, classes, property sets, relationships, enumeration's, select types, defined data types, attributes, functions and rules are written in upper and lower case characters as a single name without spaces. The first character of each word in normal usage is written as an upper case character. All other characters forming part of the same word in normal usage are written in lower case characters.
There is no restriction on the length of names used in the IFC Model.
All names of schema, classes, enumeration's, select types, defined data types and functions are prefixed by the term 'Ifc' to identify their usage within the IFC Model. Note that the prefix 'Ifc' shall NOT be added to names of attributes and relationships or to names of property sets (see Pset Prefix rule below).
Schema are identified as to the layer within the IFC Technical Architecture at which they exist as part of the schema name as follows: · A schema at the resource layer has the term 'Resource' appended e.g. IfcGeometryResource schema · A schema at the core layer has the term 'Extension' appended (except for the IfcKernel schema) e.g. IfcProcessExtension schema · Schema names at the interoperability layer are defined by concatenation of the following elements: 1. The prefix 'Ifc' 2. The term 'Shared' 3. A name describing the information content of the schema 4. The suffix 'Elements' e.g. IfcSharedBldgServicesElements schema · A schema at the domain layer has the term 'Domain' appended IfcFacilitiesMgmtDomain schema
The name of all enumeration data types is suffixed with 'Enum'. Exception Where an enumeration is taken directly from the STEP (ISO 10303) series of standards, the suffix 'Enum' is not added.
An enumeration that is used to specify the existence of type driven property sets has the suffix "TypeEnum".
The name of all SELECT data types is suffixed with the term 'Select' Exception Where a SELECT type is taken directly from the STEP (ISO 10303) series of standards, the suffix 'Select' is not added to the name given by the standard.
The name of a class (unless a relationship class) is a noun or combination of nouns, denoting the "content" or "type" of the class. e.g. IfcGroup
For all schemas at the core, interoperability and domain layers of the IFC technical architecture, relationship classes are named as below. The name of a relationship classes contains the term 'Rel' following the 'Ifc' prefix and before the "content" name of the class. The "content" name of the relationship class is a verb that denotes its "function". e.g. IfcRelGroups
For all schemas at the resource layer of the IFC technical architecture, relationship classes are named as below. The name of a relationship classes contains the a name that reasonably describes the content of the relationship following the 'Ifc' prefix. The suffix term 'Relationship' is appended after the "content" name of the class. e.g. IfcActorRelationship
The name of a property set is defined as for a class except that it is prefixed by the term 'Pset_'.
A subtype is a specialization of exactly one supertype.
A supertype is constrained so that it can be instantiated exclusively by one of its subtypes. That is, the ONEOF supertype constraint shall be used.
Attributes defined at a supertype level are not redefined at the subtype level
Aggregation relationships (LIST, SET, BAG) that may be specified as empty are defined as an optional relationship with a cardinality of one to many.
All attributes that resolve to a simple data type (INTEGER, REAL, STRING, LOGICAL) shall be specified as defined data types.
Relationships between classes that are subtypes of IfcObject (at any level) shall be defined through the use of a relationship class by preference.
Relationships between classes that span schema boundaries are managed through relationship classes.
Many-to-many relationships are resolved to one to many or one to one relationships through the introduction of a relationship class.
A class may reference or use a class at the same or lower layer within the IFC Technical Architecture but may not reference or use a class from a higher layer. Currently the order of layers in the IFC Technical Architecture is (starting from the lowest):
The following checklist enables development of an extension model to be checked against the rules that are generally applied to the development of IFC Model schema.
|
Check that …… |
Y / N |
|
All names of schema, classes, property sets, relationships, enumeration’s, select types, defined data types, attributes, functions and rules are written in upper and lower case characters as a single name without spaces? |
|
|
The first character of each word in a name is written as an upper case character. All other characters forming part of the same word in normal usage are written in lower case characters? |
|
|
Names of schema, classes, enumerations, select types, defined data types and functions are prefixed by the term ‘Ifc’ to identify their usage within the IFC Model? |
|
|
Schema are identified as to the layer within the IFC Technical Architecture at which they exist as part of the schema name? |
|
|
The name of all enumeration data types is suffixed with ‘Enum’? |
|
|
Enumeration data types used to specify the existence of type driven property sets have the suffix "TypeEnum"? |
|
|
The name of all SELECT data types is suffixed with the term ‘Select’? |
|
|
The names of classes (other than relationship classes) is a noun or combination of nouns, denoting the "content" or "type" of the class? |
|
|
The name of relationship classes contains the term ‘Rel’ following the ‘Ifc’ prefix and before the “content” name of the class? |
|
|
The “content” name of the relationship class is a verb that denotes its "function"? |
|
|
The name of property sets is prefixed by the term ‘Pset_’? |
|
|
Each subtype is a specializations of exactly one supertype? (single inheritance) |
|
|
Each supertype is constrained so that it can be instantiated exclusively by one of its subtypes? |
|
|
Aggregation relationships (LIST, SET, BAG) that may be specified as empty are defined as optional relationships with a cardinality of one to many? |
|
|
Relationships between classes that span schema boundaries are managed through relationship classes? |
|
|
There are no many to many relationships used within the extension model? |
|
|
Classes reference or use classes at the same or lower layer within the IFC Technical Architecture? |
|
|
Classes DO NOT reference or use classes at a higher layer within the IFC Technical Architecture? |
|
|
Attributes of a class appear in the same order as in any previous version of the model? |
[1] Readers guides to major information modeling methods used by the IAI are published separately.
[2] Refer to the IFC Specification Development Guide for further guidance on requirements capture for IFC Model development.
[3] If a valve was required to fulfil the both the isolating and check (non-return) role, an IsolatingAndCheckValve subtype might be added.
[4] In the IFC 2x model, the actual class performing the role shown in this example is IfcRelSpaceBoundary.
[5] A model subset is a part of the whole IFC Model that is complete in its own right and can perform a particular data exchange or information sharing function. The term ‘View’ is used within the IFC context to identify such a subset where it is used for certification purposes. Other terms may be used for such a model including Conformance Class or Unit of Functionality (STEP), Application Model.
[6] Except resource class
[7] For further information, refer to the IFC 2x Property Set Development Guide