Resource-level instances (not deriving from IfcRoot) do not have any identity, such that two instances having identical state are considered equal. For example, if an object has coordinates described by an IfcCartesianPoint instance, another object with the same coordinates may have a separate instance of IfcCartesianPoint or share the same instance; such difference is a matter of data storage optimization and does not imply any semantic relationship. This also implies that non-rooted instances may only exist if referenced by at least one rooted instance through either a direct attribute or inverse attribute, or following a chain of attribute references on instances.
The distinction between rooted and non-rooted (resource-level) entities achieves several goals:
Various objects may have additional identifications that may be human-readable and/or may be structured through classification association.
Various file formats may use additional identifications of instances for serialization purposes, however there is no requirement or guarantee for such identifications to remain the same between revisions or across applications. For example, the IFC-SPF file format lists each instance with a 64-bit integer that is unique within the particular file.
]]>To support a model server scenario, each object may be marked with a change action indicating the object was added, modified, deleted, or has no change since the project was retrieved from the server at a particular revision sequence. Given an object's identity (IFC-GUID) and change action, the state of the object may be merged when submitted to a model server. An object is considered modified when any of its direct attributes change, attributes on a referenced resource definition (any entity not deriving from IfcRoot) change, items are added or removed from sets, or items are added, removed, or reordered within lists.
For cases when multiple users make conflicting changes to the same objects, users may choose to keep their own changes, accept changes from others, merge both changes, or a combination thereof upon submitting to a server. Alternatively, to avoid such merge scenario and coordinate work, objects may be locked such that a particular user has exclusive access to read and/or write a particular object at the current time.
Project libraries may also be retrieved from model servers having particular revision, and potentially different server URI than the referencing Project. As a project may include multiple revisions of the same project library (a common scenario when multiple users are involved using libraries revised by others), the IfcRoot.ObjectIdentifier IFC-GUID is only valid within the scope of the referencing project, and a separate library reference identifies a project library based object within its originating model server.
Finally, objects may also carry informational attributes indicating when an object was created, who, when, and what application was used to last modify an object, and who currently owns the object, potentially having exclusive use according to its lock state.
]]>An individual item within the external source of information can be selected. It then applies the inherent meaning of the item to the object or property.
]]>Constraints based on metrics are measurable, such that the status of a metric being valid is computer-interpretable. Metric constraints are based on simple conditional logic such as greater than a particular value or included within a specified list or table. Constraints may be combine multiple metrics using boolean logic such as AND, OR, XOR, or NOT.
]]>To indicate an explicit mapping to a particular file or database, IFC classes may be mapped to tabular data formats using IfcResourceConstraintRelationship attached to IfcDocumentInformation.
Default mappings may be indicated using the IfcRelAssociatesConstraint relationship, with RelatingConstraint pointing to IfcObjective.
An IfcObjective of type EXTERNAL has ConstraintSource set to the name of the IFC entity (e.g. 'IfcSpace') with Benchmarks containing a single IfcMetric with DataValue set to an IfcTable. On IfcTable, the Name is set to the name of the external database table or worksheet, and the Columns attribute indicates the external table columns in order as IfcTableColumn. For each IfcTableColumn, the Name indicates the field name or column header, and the ReferencePath identifies the corresponding object attribute, for which standard mappings are indicated.
Within this document, attribute paths (as used for IfcReference) are encoded using syntax in the form 'IfcSpace.OwnerHistory\IfcOwnerHistory.CreationDate' with the following conventions:
Upon import from a spreadsheet, tables shall be identified by worksheet name regardless of order, and columns shall be identified by header name regardless of order. For export to a new spreadsheet, worksheets shall be provided with identifying name for each entity and sequenced in the order specified, and within each worksheet a header row shall be provided with with each column having an identifying name and sequenced in the order specified.
Attributes are mapped to spreadsheet cells, where either NULL, an empty string, or the reserved value 'n/a' indicates a null value. Specific base types are mapped as follows:
Specific mappings are defined at corresponding entities, where the following standard column names are used:
Tables may be used for various scenarios, such as available configurations of product types, equipment schedules, and mappings to tabular data formats.
]]>An object can be comprised of a single material or a set of materials with a particular layout. Several examples include:
A pair of entities are defined for various object occurrences and object types, where such object occurrence entity may only be defined using a particular object type entity. For example, the IfcTank occurrence object entity has a corresponding IfcTankType type object entity.
Many object occurrence and object type entities have an attribute named PredefinedType consisting of a specific enumeration. Such predefined type essentially provides another level of inheritance to further differentiate objects without the need for additional entities. Predefined types are not just informational; various rules apply such as applicable property sets, part composition, and distribution ports.
For scenarios of object types having part compositions, such parts may be reflected at object occurrences having separate state. For example, a wall type may define a particular arrangement of studs, a wall occurrence may reflect the same arrangement of studs, and studs within the wall occurrence may participate in specific relationships that do not exist at the type such as being connected to an electrical junction box.
]]>Constraints may be attached to property sets to enforce conformance of the building model to indicated values. The associated IfcObjective has its type set to DESIGNINTENT to indicate that any nonconforming value should be flagged accordingly but not necessarily automatically updated as is done for other types such as PARAMETRIC. The IfcObjective contains one or more IfcMetric items corresponding to each IfcProperty that is constrained, where IfcMetric.ValueSource corresponds to IfcProperty.Name. The IfcMetric.ReferencePath identifies the attribute on related objects (IfcRelDefinesByProperties.RelatedObjects) that is to be checked, where the reference path is relative to the associated object, in this case the IfcPropertySet.
Within this document, attribute paths (as used for IfcReference) are encoded using syntax in the form 'IfcSpace.OwnerHistory\IfcOwnerHistory.CreationDate' with the following conventions:
Constrained values are interpreted as follows:
Aggregation is used on building elements to indicate parts such as studs within a wall.
Aggregation is used on systems to indicate subsystems such as branch circuits.
]]>The part may also provide, in addition to the aggregate, more specificly the following:
The part should not be contained in the spatial hierarchy, i.e. the concept Spatial Containment shall not be used at the level of parts. The part is contained in the spatial structure by the spatial containment of its composite.
EXAMPLE An IfcBeam may be aggregated into an element assembly using the objectified relationship IfcRelAggregates, refering to it by its inverse attribute SELF\IfcObjectDefinition.Decomposes. Any subtype of IfcElement can be an element assembly, with IfcElementAssembly as a special focus subtype. In this case it should not be additionally contained in the spatial hierarchy, i.e. SELF\IfcElement.ContainedInStructure should be NIL.]]>
The composite then provides, if such concepts are in scope of the Model View Definition, exclusively the following:
By default the following constraints apply to an element being decomposed by Element Decomposition:
The order of spatial structure elements being included in the concept are from high to low level: IfcProject, IfcSite, IfcBuilding, IfcBuildingStorey, IfcSpace. Therefore an spatial structure element can only be part of an element at the same or higher level.
]]>The order of spatial structure elements being included in the concept are from high to low level: IfcProject, IfcSite, IfcBuilding, IfcBuildingStorey, fcSpace. Therefore an spatial structure element can only has parts of an element at the same or lower level.
]]>Nesting is used on building elements to indicate features placed in sequence such as ports.
Nesting is used on control objects to indicate specification hierarchies.
Nesting is used on process objects to indicate subordinate task details.
Nesting is used on resource objects to indicate subordinate resource allocations.
]]>Ports may have placement defined indicating the position and outward orientation of the port relative to the product or product type.
Ports may have material profile sets defined indicating the flow area and connection enclosure.
]]>EXAMPLE An IfcBeam is placed within the spatial hierarchy using the objectified relationship IfcRelContainedInSpatialStructure, refering to it by its inverse attribute SELF\IfcElement.ContainedInStructure. Subtypes of IfcSpatialStructureElement are valid spatial containers, with IfcBuildingStorey being the default container.
The spatial containment relationship, together with the Spatial decomposition relationship, being hierarchical as well, establishes the hiearchical project tree structure in a building information model.
EXAMPLE The IfcBuildingStorey that logically contains the IfcBeam decomposes the IfcBuilding using the IfcRelAggregates relationship. Therefore the IfcBeam is also indirectly contained in the building.]]>
The following changes have been made in this release:
NOTE The IfcActionRequest entity captures all reported issues (or requests to do something), for which tasks may be assigned to carry out work to address an issue.]]>
NOTE Product types may be declared within a project without having any occurrences in IFC4. Project composition excluded (no placeholder building is necessary). Project libraries added (to provide link to originating property set templates).]]>
NOTE IFC4 allows product types to have assigned process types and resource types, which may indicate standard processes (i.e. manufacturer-defined) for servicing or replacing parts.]]>
NOTE In IFC4, all time-phased information is captured using performance-based properties on IfcPerformanceHistory. This allows for data to be recorded for multiple time periods (avoiding the single property set restriction), and to provide a uniform way of accessing and rendering time-phased data such that software applications need not be aware of particular properites. A property set should be defined for recording space conditions over time.]]>
NOTE In IFC4, the process and resource model has been formalized, such that replacement of parts may be considered as a MAINTENANCE task with assigned resources for materials, labor, equipment, products, crews, subcontracts.]]>
The volume of a space excludes coverings; the vertical dimensions start from the top of the slab below and extend to the bottom of the slab above (excluding floor coverings or dropped ceilings), and the horizontal dimensions are bounded by the extents of walls and columns (excluding coverings such as drywall). The volume of a room, however, is bounded by such coverings, and may be derived by substracting such dimensions and indicated as the NetVolume quantity.
]]>The following units must be supported in all exchange scenarios:
Additional units must be supported if they are needed in the context of an exchange scenario. Each measure value of the same type in the data exchange uses the same unit. When an application imports data, the following behavior relating to units is allowed:
The following behavior is not allowed:
The following subtypes of IfcSystem are within the scope of this MVD (though corresponding schemas are not incorporated within):