<p>The concept templates of <em>Object Definition</em> provides the means to define an object occurrence by its object type and attached property and quantity sets.</p>
<p>Object occurrences can be defined by a particular object type, using the <em>Object Typing</em> concept. A pair of entities are defined for most semantic objects - an object occurrence entity and a corresponding object type entity.</p>

<blockquote class="example">EXAMPLE&nbsp; The <em>IfcTank</em> is the object occurrence entity that has a corresponding <em>IfcTankType</em> being the object type entity. </blockquote>

<p>On instance level, an object occurrence instance may have:</p>

<ul>

<li>similar state as its object type instance by applying all characteristics defined at the type;</li> <li>overridden state for particular characteristics;</li>

<li>no defined object type instance.</li>

</ul>

<p>Characteristics defined at the object type level may include:</p>

<ul> <li>common naming and predefined type;</li>

<li>common properties within a type driven property set;</li>

<li>common geometry representations, applied as mapped representation to each occurrence;</li>

<li>common material assignments (with exception of material set usages);</li> < <li>common definition of a decomposition structure.</li>

</ul>

<p> Many object occurrence and object type entities have an attribute named <i>PredefinedType</i> 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. If the object is typed by an <i>IfcTypeObject</i>, then the <i>PredefinedType</i> at the <i>IfcObject</i> occurrence shall only be used if the <i>PredefinedType</i> at <i>IfcTypeObject</i> is set to <i>NOTDEFINED</i>.

<blockquote class="example"> EXAMPLE&nbsp; For scenarios of object types having part compositions, such parts may be reflected at object occurrences having separate state. For example, a <i>wall type</i> may define a particular arrangement of studs, a <i>wall occurrence</i> 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.</blockquote>

<blockquote class="note"> NOTE&nbsp; If the object type has aggregated elements, such objects are reflected at the object occurrence using the <em>IfcRelDefinesByObject</em> relationship.</blockquote>
<p>The concept template <em>Property Sets</em> describes how sets of properties (usually defined by a name, value, unit triple) are associated to objects or object types.</p>
<p>The concept template <em>Property Sets for Objects</em> describes how an object occurrence can be related to a single or multiple property sets. A property set contains a single or multiple properties. The data types of an individual property are single value, enumerated value, bounded value, table value, reference value, list value, and combination of property occurrences. </p>

<p>Property sets can also be related to an object type, see concept <em>Property Sets for Types</em>. They then define the common properties for all occurrences of the same type. If the same property (by name) is provided by the same property set (by name), then the properties directly assigned to the object occurrence override the properties assigned to the object type.</p>
<p> Any specialization of object can be related to multiple quantity set occurrences. A quantity set contains multiple quantity occurrences. The data type of quantity occurrence values are count, length, area, volume, weight, time, or a combination of quantities. Each quantity is defined by its name, value, and optionally a description and a formula.</p>

<p>The quantity set is expressed by instances of <em>IfcElementQuantity</em>, where the <em>Name</em> attribute determines the common designator of the quantity set. This specification contains a number of predefined quantity sets, a template definition is provided for each of them. The name of the template has to be used as the value of the <em>Name</em> attribute. The <em>MethodOfMeasurement</em> attribute specifies the method, by which the values of the individual quantities are calculated. For the quantity set templates included in this specification, the value of <em>MethodOfMeasurement</em> shall be "BaseQuantities".</p>
<p>

All entities having semantic significance derive from <i>IfcRoot</i>, where instances are identifiable within a data set using a

compressed globally unique identifier (IFC-GUID). This identifier must never change during the lifetime of an

object, which allows data to be merged, versioned, or referenced from other locations.

</p>

<p>

Resource-level instances (not deriving from <i>IfcRoot</i>) 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

<i>IfcCartesianPoint</i> instance, another object with the same coordinates may have a separate instance of

<i>IfcCartesianPoint</i> 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.

</p>

<p>

The distinction between rooted and non-rooted (resource-level) entities achieves several goals:

</p>

<ul class="ref">

<li>File size may be reduced by interning (sharing) non-rooted data instances;

</li>

<li>Database retrieval may be more efficient by storing non-rooted data local to rooted data

instances;

</li>

<li>Storage size may be reduced by avoiding IFC-GUID storage for items not requiring direct

retrieval;

</li>

<li>Comparisons of differences may be done at a higher level where the context of such change is

apparent;

</li>

<li>Implementations may treat non-rooted data instances as immutable for efficiency or simplified

usage.

</li>

</ul>

<p>An object may be labeled for human identification where the <i>Name</i> may indicate a well-known identifier. While there is no restriction on usage of such identifier, it is recommended the <i>Name</i> is unique within it's containing scope. Further guidance on usage is provided at specific entities; for example, for spaces, the <i>Name</i> may reflect a room number. An object may have a description provided via the <i>Description</i> attribute that provides further context in identifying or locating the object.</p>

<p>Specific subtypes introduce additional attributes for <em>User Identity</em>.</p> <ul> <li>Spatial objects may be further identified via the <i>LongName</i> attribute. This value should generally correspond to building signage describing floor levels or rooms. While the <i>Name</i> attribute generally provides a coded or abbreviated identifier, the <i>LongName</i> provides a functional name for the location such as "Reception Area". See concept template <em>Spatial Element Occurrence Attributes</em></li> <li>Physical elements may be further identified via the <i>Tag</i> attribute. This is a human readable identifier such as an element or item number While there is no restriction on usage of such tags, it is recommended the <i>Tag</i> is unique within it's containing scope. See concept template <em>Element Occurrence Attributes</em></li> </ul>
<p> Many object occurrences have an attribute named <i>PredefinedType</i> being a specific enumeration. Such predefined type essentially provides another level of "classification by inheritance" to further differentiate objects without the need for additional sub types. Predefined types are not just informational; various rules apply such as applicable property sets, part composition, and distribution ports.Such predefined types are added by selecting the correct enumerator for the attribute <em>PredefinedType</em>. If a custom value is needed, the attribute <i>ObjectType</i> has to be used to define such custom type, whereas the <i>PredefinedType</i> is set to <i>USERDEFINED</i>.</p>

<p>The main attributes to be provided for a <em>Object Occurrence Predefined Type</em> are:</p> <ul>

<li><em>PredefinedType</em>: holds the entity specific enumeration of predefined types to further classify the entity</li>

<li><em>ObjectType</em>: allows for a custom value, if no applicable enumerator can be found</li>

</ul>

If the object is typed by an <i>IfcTypeObject</i>, then the <i>PredefinedType</i> at the <i>IfcObject</i> occurrence shall only be used if the <i>PredefinedType</i> at <i>IfcTypeObject</i> is set to <i>NOTDEFINED</i>.

<p>Specific entities have additional attributes defined for describing common characteristics at occurrences.</p>
<p>Spatial objects may be further identified via the <i>LongName</i> attribute. This value should generally correspond to building signage describing floor levels or rooms. While the <i>Name</i> attribute generally provides a coded or abbreviated identifier, the <i>LongName</i> provides a functional name for the location such as "Reception Area". </p>
<p>A building may be located according to a postal address, and may indicate a baseline elevation and land elevation.</p>
<p>The concept of an <em>Object Association</em> provides the means to associate sources of information (most notably a classification, library, document, approval, constraint, or material) to objects definitions. The information associated may reside internally or externally in regard of the project data. </p>
<p>The concept <em>Classification Association</em> describes how objects and object types can be further described by associating references to external sources of information. The source of information can be: </p>

<ul>

<li>a classification system;</li>

<li>a dictionary server;</li>

<li>any external catalogue that classifies the object further;</li>

<li>any service that combine the above features.</li>

</ul>

<p>An individual item within the external source of information can be selected. It then applies the inherent meaning of the item to the <em>IfcObject</em> or <em>IfcTypeObject</em>.</p> <blockquote class="note"> NOTE&nbsp; The classification system or dictionary server that is used within the project itself can also be indicated at the level of <em>IfcProject</em> or <em>IfcProjectLibrary</em> either as an external source, or copied with all relevant classification items into the project data. Use the concept <em>Project Classification Information</em> to utilize this functionality. </blockquote> <p>The main attributes to be provided for a <em>Classification Association</em> are:</p> <ul>

<li><em>Identification</em>: holds the key provided for a specific references to classification items (or tables)</li>

<li><em>Name</em>: allows for a human interpretable designation of a classification notation</li>

</ul>
<p>Objects may be composed into parts to indicate levels of detail, such as a building having multiple storeys, a framed wall having studs, or a task having subtasks. Composition may form a hierarchy of multiple levels, where an object must have a single parent, or if a top-level object then declared within the single project or a project library.</p>

<p>An aggregation indicates an internal unordered part composition relationship between the whole structure, referred to as the "composite", and the subordinate components, referred to as the "parts". The concept of aggregation is used in various ways. Examples are:</p>

<ul>

<li>Aggregation is used on building elements to indicate parts such as studs within a wall;</li>

<li>Aggregation is used on spatial elements to indicate a spatial structure such as a story within a building;</li>

<li>Aggregation is used on systems to indicate subsystems such as branch circuits.</li>

</ul>

<p>Aggregation is a bi-directional relationship, the relationship from the composite to its parts is called Decomposition, and the relationship from the part to its composite is called Composition.</p>
<p>Provision of a spatial structure of the project by aggregating spatial elements. The spatial structure is a hierarchical tree of spatial elements ultimately assigned to the project. Composition refers to the relationship to a higher level element (e.g. this storey is part of a building).</p>

<blockquote class="note">NOTE&nbsp; The link between the highest level spatial element and the project is provided by this concept through <em>IfcRelContainedInSpatialStructure</em> and not through declaration using <em>IfcRelDeclares</em>. This is a known anomaly introduced to maintain compatibility with earlier versions of this standard.</blockquote>

<p>The order of spatial structure elements being included in the concept for builing projects are from high to low level: <em>IfcProject</em>, <em>IfcSite</em>, <em>IfcBuilding</em>, <em>IfcBuildingStorey</em>, and <em>IfcSpace</em> with <em>IfcSite</em>, <em>IfcBuildingStorey</em> and <em>IfcSpace</em> being optional levels. Therefore an spatial structure element can only be part of an element at the same or higher level.</p>

<p>In addition a more general hierarchical tree of spatial elements can be created by using <em>IfcSpatialZone</em>, from high to low: <em>IfcProject</em>, <em>IfcSite</em>, and <em>IfcSpatialZone</em> with <em>IfcSite</em> being an optional level.</em></p>

<blockquote class="note">NOTE&nbsp; The more general hiearchical tree has been introduced as an intermediate solution and stub for further extensions to support infrastructure works.</blockquote>
<p>Provision of a spatial structure of the project by aggregating spatial elements. The spatial structure is a hierarchical tree of spatial elements ultimately assigned to the project. Decomposition refers to the relationship to a lower level element (e.g. this storey has spaces).</p>

<blockquote class="note">NOTE&nbsp; The link between the project and the highest level spatial element is provided by this concept through <em>IfcRelContainedInSpatialStructure</em> and not through declaration using <em>IfcRelDeclares</em>. This is a known anomaly introduced to maintain compatibility with earlier versions of this standard.</blockquote>

<p>The order of spatial structure elements being included in the concept for builing projects are from low to high level: <em>IfcSpace</em>, <em>IfcBuildingStorey</em>, <em>IfcBuilding</em>, <em>IfcSite</em> and <em>IfcProject</em> with <em>IfcSite</em>, <em>IfcBuildingStorey</em> and <em>IfcSpace</em> being optional levels. Therefore an spatial structure element can only be part of an element at the same or higher level.</p>

<p>In addition a more general hierarchical tree of spatial elements can be created by using <em>IfcSpatialZone</em>, from low to high: <em>IfcSpatialZone</em>, <em>IfcSite</em>, and <em>IfcProject</em>, with <em>IfcSite</em> being an optional level.</em></p>

<blockquote class="note">NOTE&nbsp; The more general hiearchical tree has been introduced as an intermediate solution and stub for further extensions to support infrastructure works.</blockquote>
<p class="std"> Objects may participate in various connectivity relationships with other objects. </p>
<p>Spatial structures, such as site, building, storey, or spaces, may contain physical elements, including building elements, distribution elements, and furnishing elements. The containment relationship between the physical elements and the spatial structures is hierarchical, i.e. a physical element shall only be contained within a single spatial structure.</p>

<blockquote class="example">EXAMPLE&nbsp; An <em>IfcBeam</em> is placed within the spatial hierarchy using the objectified relationship <em>IfcRelContainedInSpatialStructure</em>, referring to it by its inverse attribute <em>SELF\IfcElement.ContainedInStructure</em>. Subtypes of <em>IfcSpatialStructureElement</em> are valid spatial containers, with <em>IfcBuildingStorey</em> being the default container. </blockquote>

<p>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.</p>

<blockquote class="example">EXAMPLE&nbsp; The <em>IfcBuildingStorey</em> that logically contains the <em>IfcBeam</em> decomposes the <em>IfcBuilding</em> using the <em>IfcRelAggregates</em> relationship. Therefore the <em>IfcBeam</em> is also indirectly contained in the building. </blockquote>
<p>The <em>Spatial Container</em> concept defines a spatial element as being the spatial container for physical elements, or other elements being directly related to the spatial container, such as annotations or grids. </p> <blockquote class="example">EXAMPLE&nbsp; A building story is a logical spatial container of building elements, distribution elements, or furnishing elements.</blockquote> <p>The <em>Spatial Container</em> concept is realized by using the <em>IfcRelContainedInSpatialStructure</em> objectified relationship between subtypes of <em>IfcSpatialElement</em> and the elements contained. The inverse relationship <em>ContainsElements</em> at the subtypes of <em>IfcSpatialElement</em> refers to the contained physical elements.</p>
<p>A product is an occurrence of a physical or virtual object with finite spatial extent that may have a shape representation as one of its characteristics. The concepts within the group of <em>Product Shape</em> define how a shape is created to represent different geometric and topological representations.</p>
<p> Product occurrences are placed in a right handed Cartesian coordinate system. The <em>Product Placement</em> is used to establish an object coordinate system that maby be placed relative to a parent object coordinate system, and ultimately to the project coordinate system.</p>
<p> Product occurrences can be placed in 3D space relative to where they are contained. Placement is defined by a relative position (X, Y, Z coordinates), a horizontal reference direction, and a vertical axis direction. At the outermost level, relative directions are defined according to representation context; for example, +X may point east, +Y may point north, and +Z may point up.</p>

<p> Placement follows aggregation and containment relationships as follows: </p>

<ul>

<li>at the outermost level, a site is globally positioned according to latitude, longitude, and elevation;</li>

<li>for spatial structures, positioning is relative to aggregation. For example, a site may aggregate multiple buildings, each building may aggregate multiple building storeys, and each building storey may aggregate multiple spaces;</li>

<li>for building elements, positioning is relative to the containing spatial structure. For example, a building storey may contain slabs, walls, columns, and beams; </li>

<li>for aggregated parts, positioning is relative to aggregation. For example, a staircase may aggregate one or more stair flights;</li> <li>for feature elements, positioning is relative to the affected building element. For example, an opening element is positioned relative to the wall it voids, which in turn is positioned relative to a building storey;</li>

<li >for fillings, positioning is relative to the filled opening. For example, a door is positioned relative to an opening which in turn is positioned relative to a wall; </li>

<li>for distribution ports, positioning is relative to the containing distribution element. For example, an air terminal may have a port connection for a duct segment or fitting;</li>

<li>for distribution elements, positioning is relative to the containing spatial structure, however may be constrained by port connections. For example, a electrical junction box may fill an opening within a wall, and the junction box may contain ports for contained outlets or switches; the placement of such connected elements is constrained relative to connected port of the junction box. As another example, an air terminal may fill a ceiling covering which is placed relative to a space; the placement of a connecting duct fitting may be constrained relative to the air terminal. </li>

</ul>

<p>If a containing spatial structure contains a grid, then placement may also be based relative to grid coordinates. In certain use cases, an absolute placement may be used by omitting the <em>IfcObjectPlacement</em>. In this case, the shape representation is defined within the world coordinate system. </p>
<p>

The shape of products may be represented in multiple ways for different purposes. Each representation has a well-known string identifier and a particular representation context. There may be multiple representation contexts to describe a shape at various levels of detail. Most building elements have a 'Body' representation which defines or approximates the physical shape and volume. In addition to physical building elements, non-physical elements may have representations such as spaces and openings.

</p>

<p> Elements may have a simplified 'Box' representation describing the dimensions of the smallest box bounding the object. Such representation may be used for more efficient spatial indexing or hit-testing.

</p>

<p>The representation identifier and type and the only allowed single representation item of the 'Box' representation are:</p>

<ul>

<li><em>IfcShapeRepresentation</em><em>.RepresentationIdentifier</em> = 'Box'</li>

<li><em>IfcShapeRepresentation</em><em>.RepresentationType</em> : 'BoundingBox'</li>

<li><em>IfcShapeRepresentation</em><em>.Items</em> = <em>IfcBoundingBox</em></li>

</ul>

<blockquote class="note">NOTE&nbsp; The specification does not determine the method by which the bounding box has to be created. If such a method need to be prescribed the definition has to be established by model view definitions or implementer agreements.</blockquote>
<p>Partial concept templates are described herein to indicate usage of common data types, which are then incorporated into other templates.</p>
<p>Properties may contain user-defined data, where data types are open-ended.</p>