IFC Guide

The IFC Schema comprises a set of well defined ways of breaking down information into classes and the structure of information that defines an objects (which is an instance of a class in use). The information structures provide a formal specification of attributes that belong to classes and define how data exchange and sharing using ISO 10303 parts 21 and 22 or other encoding method will be achieved.

However, there are many types of information that users might want to exchange that are not currently included within the IFC Model.

For this purpose the IFC Model provides the Property Definition mechanism (part of which is within the IfcKernel schema with the remainder being within the IfcPropertyResource schema). Property Definition is a generic mechanism that allows model users and developers to define, connect and use data-driven, expandable properties with objects

10.1.1 Extended Concept of Property Definition

The concepts provided by IfcPropertyDefinition and its subtypes are further described here. It allows for:

• Relating of an object type, for which a set of properties is defined. This is done though assigning an IfcTypeObject (through the IfcRelDefinesByType relationship) to a single or multiple object occurrences. For instance, there may be a class called IfcFan within the statically defined model19. However, the different types of fan that may exist (single stage axial, multi-stage axial, centrifugal, propeller etc.) are not in the statically defined model. These may be declared as types of the fan through a type relationship attached to the IfcFan class. Each type of fan that could be defined in IFC is included in an enumeration of fan types, or maybe extended by a type designation captured in the general ObjectType string attribute. The value that these attributes take defines the IfcTypeObject that is assigned.

• Sharing a standard set of values defined in an IfcPropertySet (or any other subtype of IfcPropertySetDefinition) across multiple instances of that class (through the IfcRelDefinesByProperties relationship). For instance, a standard range of properties with known values might be defined for the maintenance of centrifugal fans. These properties will be applied to every centrifugal fan by attaching the same instance of IfcPropertySet to all instances of IfcFan through the same 1:N relationship instance IfcRelDefinesByProperties.

• Defining different property values within a private copy of the IfcPropertySet for each instance of that class. For instance, all centrifugal fans deliver a volume of air against a known resistance to airflow. Although these properties are assigned to every centrifugal fan, the values given to them differ for every instance. There are two options to attach these private properties:

• If they overlap with properties within the shared property sets, i.e. they redefine a commonly shared property value, the properties should be assigned as overriding properties through the IfcRelOverridesProperties relationship. 19 The term ‘statically defined model’ is used to refer to the EXPRESS specification part of the IFC Model. Use of the term ‘dynamic’ or ‘dynamically defined model’ is restricted to those parts of the IFC Model that are not formally defined in EXPRESS or extensions to the IFC Model that are not documented in an IFC release.

• If they add to the commonly shared properties within the assigned property sets, then they should be added by another instance of IfcRelDefinesByProperties, assigning the specific single property set.

10.1.2 Extended concept of Property Set Definition

The concepts of IfcPropertySetDefinition and its subtypes are further described here. The IfcPropertySetDefinition is an abstract supertype of property sets that can be used within the IFC Model.
These include both the dynamically defined property sets declared through the IfcPropertySet class and the statically defined property sets such as the IfcManufactureInformation class, which represents a subtype of IfcPropertySetDefinion defined elsewhere in the IFC2× model. Both types of property set definitions can be distinguished as:

• Statically defined properties, they define properties for which a entity definition exist within the IFC model. The semantic meaning of each statically defined property is declared by its entity type and the meaning of the properties is defined by the name of the explicit attribute.

• Dynamically extendable properties, they define properties for which the IFC model only provides a kind of „meta model“, to be further declared by agreement. This means no entity definition of the properties exists within the IFC model. The declaration is done by assigning a significant string value to the „Name“ attribute of the entity as defined in the entity IfcPropertySet and at each IfcProperty, referenced by the property set.

10.1.2.1 Property Set Definition Attachment

Both, statically and dynamically defined property sets are attached to an object using the relationship class IfcRelDefinesByProperties. This allows for the object and the property definition to exist independently and for the IfcPropertySetDefinition to be attached to the object when required. An advantage of using the relationship class is that the object does not contain any references to property set definitions if none needed.

Use of the relationship class also allows the property set definition to be assigned to one or many objects. That is, many objects may share a single property set definition with common values if required.

For instance, if there are 7 chairs (instances of the IfcFurniture class) that are all exactly the same, they can all share a reference to the same IfcPropertySetDefinition that defines information about the type of upholstery, color etc.

Both the IfcObject and the IfcPropertySetDefinition have inverse attributes to IfcRelDefinesByProperties.
Whilst these cannot be seen in an IFC exchange file formatted according to ISO 10303 Part 21, they can be used by an application.
For instance, an object may be defined by many property definition assignments and these can be determined by the inverse attribute.

10.1.2.2 Overriding of Property Definitions

A property set may be assigned to many objects. However, it may be the case the value of some properties in a subset of the objects may vary whilst others remain constant. Rather than defining and assigning new property sets, the IFC Schema provides the capability to override those properties whose values change.
This is done by the assignment of an overriding property set that contains new values for those that have varied.

Example:
Figure 134 shows a set of objects (here chairs) that are to be assigned a property set that contains properties. Of this set of chairs, there is one chair which has a different value for one property (here color).
Therefore the standard value within the shared property set is overridden by the specific value for that individual chair. The value of all other properties in the subset remain unchanged, as do the values of all properties assigned to the other objects.

Note that there must be a total correspondence between the names of the properties in the set of overriding properties and the names of the properties whose values are to be changed in the base property set.
In addition the inherited attribute RelatingPropertyDefinition points to the property set which values are overridden.

The pointer to the actual original property set is necessary to avoid redundancies, if the overriding properties may appear (by name) at more than on property set, attached to the object.

10.1.3 Extended concept of Type Object

An IfcTypeObject provides the means for grouping together a number of property sets that commonly work together.
This is in preference to a situation where every property set is individually assigned to an object (although it is still possible to assign property sets individually). An IfcTypeObject may act as the container for a list of property sets (property set definitions) where the list is ordered (each property set is in the same relative location for each instance of the IfcTypeObject) and there is no duplication of property sets.
An inverse relationship between IfcPropertySetDefinition and IfcTypeObject provides for the possibility of relating the definition to an object type within which it is contained.

• Each IfcTypeObject has a name (inherited from IfcRoot) that identifies it. This could, for instance, be used in the context of library information as a means of acquiring several property sets at the same time and assigning them to an object via the IfcTypeObject.

The Description attribute (also inherited from IfcRoot) may be used to provide further, human readable, narrative information about the object type.

• The ApplicableOccurrence attribute may be used to constrain the IfcTypeObject with regard to the class within the IFC Model to which it can be assigned. This acts in the same manner as for type defined classes in previous releases of the IFC Model.

10.1.3.1 Type Object Attachment

The IfcTypeObject instance is attached to an object using the relationship class IfcRelDefinesByType. This allows for the object and the IfcTypeObject to exist independently and for the IfcTypeObject to be attached to the object when required.
An advantage of using the relationship class is that the object does not contain any references to property set definitions if none are needed. Use of the relationship class also allows the IfcTypeObject to be attached to one or many objects. That is, many objects may share a single IfcTypeObject with its contained property set definitions if required.

For instance, if there are 7 chairs (instances of the IfcFurniture class) that are all exactly the same, and there are multiple property sets that act together within an IfcTypeObject to describe the chair they can all share a reference to the same IfcTypeObject.

Example shows the type object containing all property sets and its attachment to the chairs.

#1=IFCTYPEOBJECT('abcdefghijklmnopqrst02', #2, 'Type_Chair', $, $, (#1001,#1002,#1003));
/* Property Sets contained by the Type Object */
#1001=IFCPROPERTYSET('abcdefghijklmnopqrst03', #2, 'Pset_ChairAsDesigned', $, (#1101));
#1002=IFCPROPERTYSET('abcdefghijklmnopqrst04', #2, 'Pset_ChairAsInstalled', $, (#1102));
#1003=IFCPROPERTYSET('abcdefghijklmnopqrst05', #2, 'Pset_ChairAsUsed', $, (#1103));
#1101=IFCPROPERTYSINGLEVALUE('Heigth',$,IFCLENGTHMEASURE(1.000000E+00),$);
#1102=IFCPROPERTYSINGLEVALUE('Heigth',$,IFCLENGTHMEASURE(1.500000E+00),$);
#1103=IFCPROPERTYSINGLEVALUE('Heigth',$,IFCLENGTHMEASURE(1.500000E+00),$);

/* assignment of type object to the chairs */
#2000=IFCRELDEFINESBYTYPE('abcdefghijklmnopqrst06', #2, $, $,
(#2100,#2101,#2102,#2103,#2104,#2105,#2106), #1);
#2100=IFCFURNITURE('abcdefghijklmnopqrst10', #2, $, $, $, $, $, $);
#2101=IFCFURNITURE('abcdefghijklmnopqrst11', #2, $, $, $, $, $, $);
#2102=IFCFURNITURE('abcdefghijklmnopqrst12', #2, $, $, $, $, $, $);
#2103=IFCFURNITURE('abcdefghijklmnopqrst13', #2, $, $, $, $, $, $);
#2104=IFCFURNITURE('abcdefghijklmnopqrst14', #2, $, $, $, $, $, $);
#2105=IFCFURNITURE('abcdefghijklmnopqrst15', #2, $, $, $, $, $, $);
#2106=IFCFURNITURE('abcdefghijklmnopqrst16', #2, $, $, $, $, $, $);

10.1.4 Extended concept of Type Product

The IfcTypeProduct class enables a property definition to have one or more shape representations through the RepresentationMaps attribute.
This attribute has the type IfcRepresentationMap that is the class in the IfcGeometryResource schema that defines a group of geometrical objects that can act together and be assigned to multiple objects in the manner of a symbol or block in a CAD system.

Example:
All instances of IfcFurniture (here chairs) does not only share the same set of properties (by a common IfcTypeObject), but also the same geometric representation. Therefore the subtype IfcTypeProduct is used, which allows the sharing of the same representation maps. A set of representation maps can be seen as a multi-view block, i.e. a block definition, that includes several blocks for different representation views.
For example a 2D representation of the chair and a 3D B-rep representation of the chair.
Each instance of the IfcFurniture would then have its own local placement (see 9.1.2.1) and (multiple) shape representations, each holding an IfcMappedItem, which references one map of the shared representation maps.

An object (i.e. subtypes of IfcProduct) may have a representation directly referenced by the attribute Representation of IfcProduct (shown as the product route in the diagram below).
The same representation may also be accessible through the attribute RepresentationMaps of IfcTypeProduct (subtype of IfcTypeObject and shown as the type object route in the diagram below). The reason for this duality is, that types can be exchanged without having already element instances using these types (or in other words, blocks or libraries can be exchanged even if not already used by inserted members in the building model).

Note: Within the diagram, subtype relations are shown by the thicker, straight lines whilst the thinner, curved lines show attribute relations.

Within a typical exchange, i.e. where geometric representation items are used to represent the shape of an element, the following links (involving particular subtypes) are used:

Example
The example expands the previous one by adding a commonly shared representation map (the block geometry of the chair) to the chair type. Each individual chair then references the mapped item to position to chair type shape.

#1=IFCTYPEPRODUCT('abcdefghijklmnopqrst02', #2, 'Type_Chair', $, $, (#1001,#1002,#1003), (#3000), $);
#2=IFCOWNERHISTORY(#6, #7, .READWRITE., .NOCHANGE., $, $, $, 978921854);

/* common shared property sets for the type */
#1001=IFCPROPERTYSET('abcdefghijklmnopqrst03', #2, 'Pset_ChairAsDesigned', $, (#1101));
#1002=IFCPROPERTYSET('abcdefghijklmnopqrst04', #2, 'Pset_ChairAsInstalled', $, (#1102));
#1003=IFCPROPERTYSET('abcdefghijklmnopqrst05', #2, 'Pset_ChairAsUsed', $, (#1103));
#1101=IFCPROPERTYSINGLEVALUE('Heigth', $, IFCLENGTHMEASURE(1.000000E+01), $);
#1102=IFCPROPERTYSINGLEVALUE('Heigth', $, IFCLENGTHMEASURE(1.500000E+01), $);
#1103=IFCPROPERTYSINGLEVALUE('Heigth', $, IFCLENGTHMEASURE(8.500000E+00), $);

/* assignment of type to all instances of the chair */
#2000=IFCRELDEFINESBYTYPE('abcdefghijklmnopqrst06', #2, $, $, (#2103,#2104,#2105,#2106,
#2100,#2101,#2102), #1);
#2100=IFCFURNITUREELEMENT('abcdefghijklmnopqrst10', #2, $, $, $, #3011, #3014, $);
#2101=IFCFURNITUREELEMENT('abcdefghijklmnopqrst11', #2, $, $, $, #4011, #4014, $);
#2102=IFCFURNITUREELEMENT('abcdefghijklmnopqrst12', #2, $, $, $, #5011, #5014, $);
#2103=IFCFURNITUREELEMENT('abcdefghijklmnopqrst13', #2, $, $, $, #6011, #6014, $);
#2104=IFCFURNITUREELEMENT('abcdefghijklmnopqrst14', #2, $, $, $, #7011, #7014, $);
#2105=IFCFURNITUREELEMENT('abcdefghijklmnopqrst15', #2, $, $, $, #8011, #8014, $);
#2106=IFCFURNITUREELEMENT('abcdefghijklmnopqrst16', #2, $, $, $, #9011, #9014, $);

/* common shared representation map for the chair - here simplistic bounding box */
#3000=IFCREPRESENTATIONMAP(#3003, #3005);
#3003=IFCAXIS2PLACEMENT3D(#3004, $, $);
#3004=IFCCARTESIANPOINT((0.000000E+00, 0.000000E+00, 0.000000E+00));
#3005=IFCSHAPEREPRESENTATION(#3008, 'Body', 'BoundingBox', (#3006));
#3006=IFCBOUNDINGBOX(#3007, 5.000000E-01, 4.000000E-01, 1.200000E+00);
#3007=IFCCARTESIANPOINT((0.000000E+00, 0.000000E+00, 0.000000E+00));
#3008=IFCGEOMETRICREPRESENTATIONCONTEXT($, $, 3, $, #3009, $);
#3009=IFCAXIS2PLACEMENT3D(#3010, $, $);
#3010=IFCCARTESIANPOINT((0.000000E+00, 0.000000E+00, 0.000000E+00));

/* shape representation for the first instance of the chair */
#3011=IFCLOCALPLACEMENT($, #3012);
#3012=IFCAXIS2PLACEMENT3D(#3013, $, $);
#3013=IFCCARTESIANPOINT((1.000000E+01, 5.000000E+00, 0.000000E+00));
#3014=IFCPRODUCTDEFINITIONSHAPE($, $, (#3015));
#3015=IFCSHAPEREPRESENTATION(#3008, 'Body', 'MappedRepresentation', (#3016));
#3016=IFCMAPPEDITEM(#3000, #3017);
#3017=IFCCARTESIANTRANSFORMATIONOPERATOR3D($, $, #3018, $, $);
#3018=IFCCARTESIANPOINT((0.000000E+00, 0.000000E+00, 0.000000E+00));

10.1.5 Extended concept of dynamic Property Sets

The IfcPropertySet class is a container that holds collections (or sets) of properties. A property set is defined externally to the statically defined IFC Model in the EXPRESS data definition language. A number of property sets are defined and distributed with the IFC Model.
Those property sets do form part of the complete IFC Model (together with the EXPRESS definition), although they are not part of the IFC2× platform.

The specification of a property set defines the manner in which property information is held within a fully populated IFC exchange file or within an IFC compliant database. It can also be used to define the specification for the transport of a message containing IfcPropertySet information.

• An IfcPropertySet contains a set of properties. There must be at least one property within a property set. The Name attribute of all properties within the set must be different.

• An IfcPropertySet has a Name (inherited from IfcRoot). This is an identifier that is used for recognition. It is a vitally important attribute in the context of defining industry or project standard property sets that may be used by multiple organizations.

• An IfcPropertySet may also have a description (inherited from IfcRoot) that is a human readable narrative describing some information about the property set.

10.1.6 Concept of dynamic Property Definitions

The fundamental aspect of the IfcPropertySet is that it contains a set of properties. It must contain at least one property and may contain as many as are necessary.
Since it contains a SET of properties, the order in which the properties appear is of no significance. Only the names of the individual properties characterize their content and meaning.

A property may be either of the following (each of these types of property is further described below):

The IfcProperty class is the common abstraction for all Properties defined within the IFC Model. It is an abstract supertype, meaning that there is never an IfcProperty object itself, only objects that are a subtype of IfcProperty.
Every instance of IfcProperty must have a Name by which it can be identified. It may have a Description, to further describe the meaning of the property. NOTE: Within a single IfcPropertySet, all contained properties (subtypes of IfcProperty) need to have unique Name attribute values, i.e. no two properties within a property set shall have the same Name string.

As use of the dynamic parts of the IFC Model expands, it is intended that a dictionary of standard IFC properties will be defined progressively. For the present, for those properties used in property sets that are published as part of the IFC Model, overlap in naming, definition and usage of units has been eliminated.

10.1.6.1 Concept of Property with Single Value

An IfcPropertySingleValue is a single property that has either a name – value pair or a name – value – unit triplet. Provision of a Unit is optional. Additionally an optional Description may be attached.

If no Unit is assigned, the globally defined unit (see 3.3.2) is used as it relates to the measure type of the NominalValue (chosen from the IfcValue select type). If a Unit is provided, the unit for the nominal value can be defined locally (and it thereby overrides the eventually given globally defined unit). This concept applies to all subtypes of IfcSimpleProperty.

The IfcPropertySingleValue is the most used concept for exchanging property sets. If only the mandatory name – value pair is inserted it directly maps to most of the extensible attribute data of CAD systems, if a Unit and Description is to be handled as well, implementation guides may introduce special conventions for property naming in order to allow the encapsulation of a description and unit within the name tag.

The current implementation guide and view definitions for the coordination view recommend to not use „[“, „]“, „;“ within a Name or Description of IfcPropertySingleValue.

10.1.6.2 Concept of Property with Enumerated Value

An IfcPropertyEnumeratedValue allows for the (potentially multiple) selection of a property from a predefined list of selections.
The actual value is stored by the attribute EnumerationValues and is selected from the list that is defined within an IfcPropertyEnumeration object. The EnumerationValues allow for either a single choice (if the list only contains a single item) or for multiple choices.
The IfcPropertyEnumeration instance may be referenced by the EnumerationReference attribute – if it is given, a where rule ensures, that the selected values are within the list of the values as specified in the IfcPropertyEnumeration.

Figure 144 : Definition of IfcPropertyEnumeratedValue … tady chybi nejaky text pred/po figure 144

The list of possible selections is defined through the use of the IfcPropertyEnumeration class. The actual values from which the selection is made are stored in the attribute EnumerationValues. Each IfcPropertyEnumeration has a name that must be unique to distinguish it from other instances of IfcPropertyEnumeration that may be used.

A unit may be assigned to an IfcPropertyEnumeration. This is the unit that each value in the enumeration shares. It is not possible to have values within the enumeration that have different units.

10.1.6.3 Concept of Property with Bounded Value

An IfcPropertyBoundedValue allows for a property whose value can be allowed to vary between an upper limit (the UpperBoundValue attribute) and a lower limit (the LowerBoundValue attribute).

Within IFC2×2 the LowerBoundValue and UpperBoundValue have been changed into optional attributes (had been mandatory before). Now also the exchange of open bounds is possible. The example shows the definition of a minimum, maximum and allowable height using the features of the IfcPropertyBoundedValue.

10.1.6.4 Concept of Property with List Value

An IfcPropertyListValue allows for the definition of a property that is given by a list of values. This is a new entity within IFC2×2. If the Unit is given, it applies to all values within the list, a where rule ensures that all entries within the list are of the same measure type.

The example shows the instance IfcPropertyListValue keeping a list of allowable heights

#1101=IFCPROPERTYLISTVALUE(‚AllowableHeigths‘, $, (IFCLENGTHMEASURE(1.0), IFCLENGTHMEASURE(1.2), IFCLENGTHMEASURE(1.5), IFCLENGTHMEASURE(1.8)), $);

10.1.6.5 Concept of Property with Table Value

An IfcPropertyTableValue allows for the definition of a range of values where each value stored is dependant on another value. This allows for either values in a two dimensional table to be stored or approximates to the storage of a set of values that may be derived from an expression for x and y where y = φ(x)

Two value ranges are defined namely the DefiningValues and the DefinedValues. The DefiningValues are those upon which the DefinedValues are dependent.
For example, if an IfcPropertyTableValue object was storing values where the expression y = x2 was applicable, the table of values would be:

The Expression from which the values are derived may also be stored for reference. Using the Expression attribute is for convenience; no operations are carried out on the expression. The Units that are used for both the DefiningValues and the DefinedValues may also be defined.

10.1.6.6 Concept of Property with Reference Value

An IfcPropertyReferenceValue enables reference to objects whose structure is defined by the static part of the IFC Schema.
This is achieved by defining a relationship to the object being referenced. This is achieved through the IfcObjectReferenceSelect that allows selection of the type of object (class) required. An IfcPropertyReferenceValue may have a usage name that defines the purpose or usage

The IfcObjectReferenceSelect defines the types of object (classes) that may be referenced as a property within an IfcPropertySet object. The purpose is to make available the capabilities of the class as though it was a property.

There are a limited number of classes that may be selected through the use of the IfcObjectReferenceSelect data type.
All of these classes occur within the Resource layer of the IFC Schema.
This restriction conforms to the provisions of the IFC Technical Architecture which requires that an object can only reference a class at the same or a lower layer within the Architecture. Since an IfcPropertyReferenceValue is itself a class that exists at the Resource layer, it can therefore only refer to other classes at the Resource layer.

10.1.6.7 Concept of Complex Property

An IfcComplexProperty provides the means for extending the range of properties that can be assigned to an object by defining a mechanism for bringing other properties into named groupings.

Since any IfcComplexProperty can include other properties (being either IfcSimpleProperty or

An IfcComplexProperty has a UsageName that describes how the property is to be used within a property set. This is particularly important where there may be more than one complex property of the same type used within a property set. This can happen where there is more than one item of the same type within an object but the usage of each item differs.

Example:
Consider two complex properties of the same name that include glazing properties. The Name attribute of the complex property could be Pcomplex_GlazingProperties.
The UsageName attribute for one instance of the complex property could be OuterGlazingPlane whilst for the other instance, the UsageName attribute could be InnerGlazingPane. This would distinguish the usage of the IfcComplexProperty for the two glazing panes.

A rule on the IfcComplexProperty class prevents the assignment of more than one copy of identical complex properties within a property set.

10.2. Material Definitions

10.2..1 Associating material definition with objects in IFC model

Objects in IFC model that can have an associated material definition. All instances of subtypes of the IfcElement (with the exception of IfcOpeningElement) can have an instantiated inverse relationship HasAssociations pointing to IfcRelAssociatesMaterial.
This provides a pointer to IfcMaterialSelect, where the actual instance is either

In the IFC model the material association is defined as (fully attributed view):

ENTITY IfcRelAssociatesMaterial; (* ENTITY IfcRoot ) GlobalId : IfcGloballyUniqueId; OwnerHistory : IfcOwnerHistory; Name : OPTIONAL IfcLabel; Description : OPTIONAL IfcText; ( ENTITY IfcRelAssociates ) RelatedObjects : SET [1:?] OF IfcRoot; ( ENTITY IfcRelAssociatesMaterial *) RelatingMaterial : IfcMaterialSelect; END_ENTITY;

TYPE IfcMaterialSelect = ( IfcMaterial, IfcMaterialList, IfcMaterialLayerSetUsage); END_TYPE;

The material association relationship allows to assign the same material definition to multiple instances of IfcElement, or IfcTypeObject, and thereby it allows to share the same material information across many objects.
Therefore the material information (such as material layer sets, material lists and materials) can be stored and exchanges separately from the actual building elements.

NOTE:
In IFC2×2 the IfcMaterialLayerSet and the IfcMaterialLayer have been added to the IfcMaterialSelect and can now be directly assigned to IfcObject and IfcTypeObject.

10.2..1.1 Associating a single material

In the first case, where there is a solid element, e.g. a concrete wall, the select item IfcMaterial would be used.
This assigns the same material to the complete body of the element. The result is an isotropic material definition for the element.

ENTITY IfcMaterial; Name : IfcLabel; INVERSE ClassifiedAs : SET [0:1] OF IfcMaterialClassificationRelationship FOR ClassifiedMaterial; END_ENTITY;

Example: Three concrete column are exchanged by referencing the same material definition.

10.2..1.2 Associating a list of materials

In the second case, where there is an element made of several materials, e.g. a wall of concrete, brickwork and mineral wall insulation, but the exact structural configuration is not given, the select item IfcMaterialList would be used:

Note:
The use of material list for walls is only allowed for arbitrary walls (i.e. instances of IfcWall, which are not instances of IfcWallStandardCase).

10.2..1.3 Associating material layers

In the third case, where there is an element made of several materials, e.g. a layered wall made of concrete, brickwork and mineral wall insulation, and the exact structural configuration is given, the select item IfcMaterialLayerSetUsage should be used.
This also allows to reflect the material layers within the presentation of the element:

ENTITY IfcMaterialLayerSetUsage; ForLayerSet : IfcMaterialLayerSet; LayerSetDirection : IfcLayerSetDirectionEnum; DirectionSense : IfcDirectionSenseEnum; OffsetFromReferenceLine : IfcLengthMeasure; END_ENTITY;

Here the relationship ForLayerSet points to the instance of IfcMaterialLayerSet that is used to describe the material information of this particular wall.
The attributes ‘LayerSetDirection’, ‘DirectionSense’ and OffsetFromReferenceLine give the orientation and location of the layer set relative to the wall geometry:

Note, that one instance of IfcMaterialLayerSet can be used by several walls, i.e. the same material combination may be assigned with different offsets to several walls.

For a layered wall, the IfcMaterialLayerSet.TotalThickness shall be equal to the wall thickness (measured in the Y dimension of the extrusion coordinate system), and the layer set Y direction shall coincide with the extrusion profile positive or negative Y-direction (depending on the DirectionSense attribute).
Thus, the attribute LayerSetDirection shall be set to AXIS2. The reference line shall be the wall axis path.

Figure 154 shows the definition of the material layer set being outside of the wall path, starting from the OffsetFromReferenceLine (positive offset) and assigning all layers into the same positive direction.

Example
In a case, where a wall (and its material layer set) with vertically extruded geometry has been assigned centric to the wall path, the IFC file could be as:

10.2..2 Material Classifications

Classifications of a material can be expressed using general IfcClassificationReference (see the discussion about the concept of classification in ## 10.4.2), associated with specific material through IfcMaterialClassificationRelationship, defined as:

Example:
In case of a particular steel material “S275JR” (formerly “Fe430B”) according to Euronorm EN10025 (1993), this could appear in the exchange file as:

10.3. Quantities and Measurement of Elements

‘Methods of measurement’ are frequently used as the basis on which elements may be measured for inclusion in cost or progress submissions.
They may include sets of rules that determine how the measurement should be established and the units of measure in which it should be expressed. The rules may be developed from some abstract concepts of measurement rather than actual values (such as length, area etc.) that might otherwise be physically associated with an object or that might be derived through knowledge of the geometric representation of an object.

Example:
Consider a straight section of pipework with a 90– bend at one end and a square tee at the other end.

The actual length of the pipe section (as cut and fitted) is measured as the distance between each physical end and should include for the actual length of the pipe that is inserted into the fitting in the case of pipework with screwed or capillary joints.
In geometric terms, it is normally measured as shown; that is the length of piping between the end of the bend to which it is connected and the end of the tee to which it is connected.

A method of measurement might however set a rule that the length should be measured as the distance between the ends of the section of pipe if they were projected to a point at which they would meet with an adjacent section of pipe.
This would mean that the measured length would be greater than the actual length but would be considered satisfactory under the rules of the method of measurement for costing.

A further rule might be that instead of determining the type of each fitting, all fittings would be treated as being the same (called a ‘counted fitting’ in this example). With such a rule, manual costing is easier to achieve.
A further alternative rule for determining the length of pipework is to make an ‘extra-over’ allowance for fittings that is added to the length of the pipework. This might take the form of a value or percentage.
In this case, costs would be determined only on the measured length and unit cost of the pipework, the fittings not being specifically costed at all. The quantities and methods of measurements are used to fulfill the UoF „Element Quantities“, which are utilized at IfcSpatialStructureElement and IfcElement. They are required to enable the exchange scenario of „quantity takeoff“ and will certainly be included in an IFC2× view definition generated to provide for quantity takeoff using IFC.
The generic definitions, as introduced within this section, provide for the flexibility needed to meet the particular requirements of local or regional methods of measurements.

10.3..1 Concept of Element Quantity

Quantities can be assigned to objects through the IfcElementQuantity class. This is defined in the IfcProductExtension schema.
It is one of the subtypes of IfcPropertySetDefinition that is explicitly defined as part of the IFC data definition in the EXPRESS language which means that all of the properties within the IfcElementQuantity property set have defined semantics20

Each instance of IfcElementQuantity can contain one or more instances of IfcPhysicalQuantity (q.v.).

This means that all defined quantity properties that are to be related to an object can be collected together into a single instance of IfcElementQuantity. It also means that a single instance of IfcElementQuantity can be related to many objects thereby minimizing the data load that has to be carried by individual objects.

Each instance of IfcElementQuantity also has a single defined MethodOfMeasurement attribute. This is a string value that names the rule set that is used for definition of the quantity properties. All quantities contained by a single instance of IfcElementQuantity must conform to the same method of measurement.
However, should it be necessary to use quantities defined by more than one method of measurement; it is possible to make more than one relationship of IfcElementQuantity to an object. NoteThis means, that for example the „running meter“ and the „side area“ of a wall, if measured according to the same method, like the German VOB, would be attached to the wall instance by a single instance of IfcElementQuantity.
If additionally the volume of the wall is derived by a different method, like the German DIN276, that it is attached by a separate instance of IfcElementQuantity.

20 This is as opposed to properties within a property set that is defined through use of the IfcPropertyResource meta model in which each property only has the semantics of a name the semantics of which must be declared or agreed particularly.

10.3..1.1 Concept of Associating Quantities to Objects

Quantities can be defined for any instance of a subtype of IfcObject. This means that, as well as individual physical products, quantities can also be defined for processes, resources, groups, controls etc.

Quantities are related to objects through the IfcRelDefinesByProperties class in the IfcKernel schema. This relationship class can apply a single RelatingPropertyDefinition to one or many instances of a subtype of IfcObject.
It should be noted that it is possible to relate a single IfcElementQuantity to different types of IfcObject; there is no limiting rule that says that one IfcElementQuantity can only be related to one type of IfcObject.

The attribute MethodOfMeasurement defines the method which has been used to create the quantities of the elements. These methods are usually national standards that define the measurement rules.

Examples are VOB for Germany or UMM3 for UK, for general quantities that are not subjected to national rules the following values for MethodOfMeasurement are to be used:

Example:
Consider two standby generators for providing electrical supply in the event of a power failure.
For the purposes of this example, both of these are considered to be of the same type (IfcElectricGeneratorType) but having a different function. In this case, the quantity of interest is the weight according the third edition of the Unidentified Method of Measurement (known as UMM3).
The value that is assigned to the units is 500kg.This is taken to include for a full fuel tank at the generator.

IFC2×2 usage: Information concerning the type of generator is specified using IfcElectricGeneratorType.
The fact that it is a standby generator is specified through the enumeration IfcElectricGeneratorTypeEnum.
Practically, this enumeration only specifies UserDefined and NotDefined types.
Therefore, for the purposes of this example, a user defined type will be selected and a user defined value of ‘STANDBY’ assigned.
This is achieved using the IfcElectricGeneratorType.ElementType attribute (inherited through IfcElementType).

/* general definitions for ownership */
#100=IFCOWNERHISTORY(#106, #107, .READWRITE., .NOCHANGE., $, $, $, 978921854);
#101=IFCOWNERHISTORY(#106, #107, .READWRITE., .NOCHANGE., $, $, $, 978921854);
#102=IFCOWNERHISTORY(#106, #107, .READWRITE., .NOCHANGE., $, $, $, 978921854);
#106=IFCPERSONANDORGANIZATION(#108, #109, $);
#107=IFCAPPLICATION(#109, '1', 'IFC2x Text Program', 'IFC2x Test');
#108=IFCPERSON($, 'Miller', 'Frank', $, $, $, $, $);
#109=IFCORGANIZATION($, 'IAI', 'International Alliance for Interoperability', $, $);

/* definition of element quantity containing a single physical quantity / / as the unit is not given it refers to the global unit assignment * #400=IFCQUANTITYWEIGHT (‚Generator Weight‘,‚Includes for fuel provision‘,$,500.0); #600=IFCELEMENTQUANTITY (‚gabcdeghijklmnopqrst97‘,#101,$,$,‚UMM3‘,(#400));

/* assigning quantities to occurrences */ #700=IFCRELDEFINESBYPROPERTIES (‚gabcdeghijklmnopqrst700‘,#102,$,$,(#950,#960),#600);

/* specification of type */ #800=IFCELECTRICGENERATORTYPE (‚gabcdeghijklmnopqrst800‘,#100,$,$,$,$,$,$, ’STANDBY’,.USERDEFINED.);

/* relationship between type and occurrence */ #900=IFCRELDEFINESBYTYPE(‚abcdefghijklmnopqrst900‘, #2, $, $, (#950,#960), #800);

/* elements to which the same quantity is assigned (or shared) / #950=IFCENERGYCONVERSIONDEVICE(‚abcdefghijklmnopqrst950‘,#100,$,$,$,#10001,#10002,$); #960=IFCENERGYCONVERSIONDEVICE(‚abcdefghijklmnopqrst960‘,#100,$,$,$,#10003,#10004,$); / #10001 – #10004 inc.give object placement and representation of occurrences */

10.3.1.2 Concept of Physical Quantity

The IfcPhysicalQuantity defines the various forms of quantity properties that can be contained within the IfcElementQuantity. Five types of quantities are defined:

Each type of IfcPhysicalQuantity has a value attribute that is defined according to the equivalent defined data type within the IfcMeasureResource schema e.g. the value of an IfcQuantityLength is given by an IfcLengthMeasure.

Each instance of IfcPhysicalQuantity must have a name that defines the context for its usage. For instance, a wall may have several area measures.
These could have context names such as footprint area, left wall face area, right wall face area etc. The areas would be given by three instances of the area quantity subtype, with different Name string values.
The Name attribute defines the actual usage or kind of measure. The interpretation of the name label has to be established within the actual exchange context.

Additionally, each quantity may have an associated informative description that can be used to explain or further qualify the Name attribute. Each instance of IfcPhysicalQuantity may also have a unit. The definition of units is introduced in section 3.3.

If the unit is given, the value for unit overrides the global setting of the project-wide units within IfcProject.UnitsInContext.
If the value for unit is omitted, than the unit defined within UnitsInContext is used.
In order to find the applicable unit, a measure type is provided for each measure value.

The five subtypes reflect the major measure types used in the various methods of measurement around the world.

10.14 Referencing External Information

The IFC Model allows to reference information, which is externally defined.
In this case only the access information is stored within the IFC exchange set (mostly the URL for HTTP access protocol), and eventually some header information (e.g. the name of the reference, a short summary, etc.). The actual content however remains at the source location.

10.4.1 Referencing External Documents

10.4.2 Referencing External Classifications

It is recognized that there are many different classification systems in use throughout the AEC/FM industry and that their use differs according to geographical location, industry discipline and other factors.
For a generic model such as IFC, it is necessary to allow for the adoption of any rational classification system whether it is based on elements, work sections or any other classifiable division.

The classification model is able to represent classifications according to the most advanced current concepts from work in ISO TC59, ICIS (International Construction Information Society) and EPIC (European Product Information Coding) as well as more traditional classifications such as those in the various SfB forms used internationally, CAWS, Master format etc., or other national classification system, like the DIN in Germany.

The classification model forms part of the IfcExternalReferenceResource schema and specifies the use of the independent resources necessary for the scope and information requirements for the exchange and sharing of classification information between application systems. Such information may be used at all stages of the life cycle of a building.

10.4.2.1 Concept of Associating Classification to Objects

Objects are classified by attaching a classification (either light weight classification reference or a fully defined facet within a classification table) by means of a relationship instance. This relationship class, IfcRelAssociatesClassification, forms part of the IfcKernel schema.
It is used to apply an IfcClassificationReference or IfcClassificationNotation to an object or an object type and property set through its relation to IfcRoot (from which all objects that can be classified are subtyped).

Each instance of IfcRelAssociatesClassification enables the association of one classification notation with one or many objects. See also section ## 10.4.2.7 for the concept of association of classifications.

NOTE:
By virtue of a where rule at the IfcRelAssociates, relationships are prohibited from having external references or definitions.

It is possible for an object to have multiple classifications. This is achieved through the use of multiple instances of IfcRelAssociatesClassification, each instance pointing to a particular classification notation and to the objects that are classified by this notation.

Using the IfcRelAssociatesClassification relationship class means that any object that is not classified does not have to carry empty attributes for classification (as was the case with previous versions of the IFC model).
This also facilitates a better subdivision of the IFC2× model into implementation views.

10.4.2.2 Concept of Classification Notation

The principal applied is that any type of object can be classified. No distinction is made between a product, a process, a control or a resource. The means by which an object may be classified is the IfcClassificationNotation class.
An IfcClassificationNotation is a notation used from published reference (which may be either publicly available from a classification society or is published locally for the purposes of an organization, project or other purpose).

Note that a classification notation may be developed using various notation facets. A facet is a part of the actual notation but which has a specific meaning.
For instance, it may be appropriate to classify an item by owning actor (represented by A=Architect) and by an entry from a classification table such as CI/SfB (represented by 210 for external wall).
This gives a classification as A2## 10.1 All classifications of an object that are contained within the IFC model are made through the IfcClassificationNotation class.
For a given object, the IfcRelAssociatesClassification class makes the connection between the IfcObject (abstract superclass, here: IfcDoor has been taken as an example for instantiation) and the IfcClassificationNotation (used for full classification). IfcObject – IfcRelAssociatesClassification → IfcClassificationNotation.

Example:
Consider an object that is to be classified with the notation „L6814“. In this case, the IfcRelAssociatesClassification has the form:

If the object is to have other notations (e.g. B2186 and Z6793), i.e. there are multiple classifications available to an object, then the IfcRelAssociatesClassification has the form:

It is a requirement that a classification notation can only bring together facets from the same classification system or source. Bringing together notation facets from different sources within the same classification notation is not allowed. However, since the IfcRelAssociatesClassification provides for an N to M relation between classification notation and classified objects, it does allow for multiple classifications to a single object. In order to assign multiple classification notations coming from different classification systems an instance of IfcClassificationNotation shall be created to contain all facets from a single source, leading to multiple instances of IfcClassificationNotation and also to multiple instances of IfcRelAssociatesClassification, which assigns each notation to the same (group of) objects.

Example:
Consider an object that is to be classified with the notations from two distinct classification systems. In this case, the IfcRelAssociatesClassification has the form:

#100=IFCDOOR ('gabcdeghijklmnopqrst02',#1000, );
#200=IFCCLASSIFICATIONNOTATIONFACET ('L6814');
#210=IFCCLASSIFICATIONNOTATIONFACET ('B2186');
#220=IFCCLASSIFICATIONNOTATIONFACET ('Z6793');
#300=IFCCLASSIFICATIONNOTATIONFACET ('106');
#400=IFCCLASSIFICATIONNOTATIONFACET ('A-31-623');
#410=IFCCLASSIFICATIONNOTATIONFACET ('B-62-562');
#500=IFCCLASSIFICATIONNOTATION ((#200,#210,#220));
#510=IFCCLASSIFICATIONNOTATION ((#300));
#520=IFCCLASSIFICATIONNOTATION ((#400,#410));
#600=IFCRELASSOCIATESCLASSIFICATION ('gabcdeghijklmnopqrst02',#1001,$,$, (#500,#510,#520),#100);
#610=IFCRELASSOCIATESCLASSIFICATION ('gabcdeghijklmnopqrst02',#1001,$,$,(#100),#510);
#620=IFCRELASSOCIATESCLASSIFICATION ('gabcdeghijklmnopqrst02',#1001,$,$,(#100),#520);
#630=IFCRELASSOCIATESCLASSIFICATION ('gabcdeghijklmnopqrst02',#1001,$,$,(#100),#530);

10.4.2.3 Concept of Classification Notation Facet

Many modern classification systems (such as Uniclass, BSAB etc.) allow for multi-faceted classification.
This is reflected in the classification model through provision of the IfcClassificationNotationFacet class where each instance represents one facet of a classification notation.
The classification notation itself is then made up of a list of notation facets. The list is declared to be a unique list to ensure both that there is order in the specification of the notation facets and to ensure that a facet can only be included once in each list.

An IfcClassificationNotationFacet object holds an individual classification value that is to be assigned to an object through IfcClassificationNotation and IfcRelAssociatesClassification objects. An IfcClassificationNotationFacet is a group of alphanumeric characters used within a classification notation.

Example:
For instance, considering a fan in an HVAC ductline. As a construction product, it has the Uniclass notation facet L7533.
However, if we consider a work section view with the fan as part of the low velocity air conditioning system, the notation facet is JU30.
Therefore, there are two facets in the classification notation which becomes (‚JU30‘, ‚L7533‘)

10.4.2.4 Concept of Classification Item

An IfcClassificationItem is a class of classification notations used.
Note that the term ‚classification item‘ is used in preference to the more usual (but deprecated) term ‚table‘ for improved flexibility. For example, the classification item „L681“ in Uniclass may be used to contain all subsequent notation facets within that class of classifications which has the title „Proofings, insulation“(e.g. L6811, L6812, L6813 etc.).

10.4.2.5 Concept of Classification Item Relationship

Classification systems are generally declared in a hierarchical structure in which a facet at an upper level in the hierarchy (parent level) is a generalization of the facets at the next lower level in the hierarchy (child level).
The hierarchy of the classification system is defined in tables (ref. CI/SfB) or sections (ref. CAWS) or some other named, coherent approach.
Typically, the position in the hierarchy is identified by a nomenclature or label e.g. X12, and the identity at the child level is derived by adding (concatenating) characters e.g. X121, X122, X123 etc.

Within the classification model, the ability to identify location in a classification hierarchy is termed the IfcClassificationItem (so as not to be identified as table, section etc. but as a generalizations of these terms).

The whole of the classification hierarchy can now be exposed through the IFC Model. This is achieved by providing the recursive relationship class IfcClassificationItemRelationship. As a further restriction; a classification hierarchy cannot contain any instance of IfcClassificationItem more than once.

An IfcClassificationItemRelationship is a relationship class that enables the hierarchical structure of a classification system to be exposed through its ability to contain related classification items and to be contained by a relating classification item.
IfcClassificationItem’s can be progressively decomposed using the IfcClassificationItemRelationship such that the relationship always captures the information about the parent level (relating) item and the child level (related) items of which there can be many. The following example shows how this could be achieved for the Uniclass system.

The inverse relationships from IfcClassificationItem to IfcClassificationItemRelationship enable information about the relationship to be recovered by the items concerned so that they are also aware of the decomposition.
The cardinality of the inverse relationship is that an IfcClassificationItem can be the classifying item in maximum one relationship and can be a classified item in maximum one relationship.
This reflects typical classification approaches that use strict hierarchical decomposition (or taxonomy) and do not have matrix relationships.

Example:
The example used in Figure 167 shows a decomposition detail from the UNICLASS system. This can be seen from:

10.4.2.6 Concept of Classification System

Each classification item belongs to an IfcClassification. This provides the means to identify the classification system being used.
IfcClassification has attributes that define its source, edition and name.

An IfcClassification is used for the arrangement of objects into a class or category according to a common purpose or their possession of common characteristics.

Example:
The objective is to minimize the number of IfcClassification objects contained within a populated IFC model. Ideally, each classification system or source used should have only one IfcClassification object.
However, because multiple classification is allowed, there may be many IfcClassification objects used, each identifying a different classification system or source. An example of the use of the IfcClassification class, defining a single classification item is:

10.4.2.7 Concept of Classification Referencing

Recognizing that it may not be appropriate to maintain the whole detail of classification within the schema, and taking the view that information may well be referenced from external sources by its address to enable access through mechanisms such as the World Wide Web, the classification model of IFC2× includes a means to reference a classification through the IfcClassificationReference class.

This is a subtype of IfcExternalReference that has a label (which can be the reference address) and identifier. Additional information may be available concerning the classification system source that is being referenced.

An IfcClassificationReference is a reference into a classification system or source (see IfcClassification).
An optional inherited „ItemReferenced“ key is also provided to allow more specific references to classification items (or tables) by type.

10.4.2.7.1 Lightweight Classification

The IfcClassificationReference can be used as a form of ‚lightweight‘ classification through the ‚ItemReference‘ attribute inherited from the abstract IfcExternalReference class.
In this case, the ‚ItemReference‘ could take (for instance) the Uniclass notation „L6814“ which, if the classification was well understood by all parties and was known to be taken from a particular classification source, would be sufficient.
This would remove the need for the overhead of the more complete classification structure of the model.

However, it is not recommended that this lightweight method be used in cases where more than one classification system is in use or where there may be uncertainty as to the origin or meaning of the classification.

10.4.2.7.2 Referencing from an External Source

Classifications of an object may be referenced from an external source rather than being contained within the IFC model.
This is done through the IfcClassificationReference class.

Example:
Consider the Uniclass notation „L6814“ which has the title „Tanking“. In this case, the optional attribute ‚ItemReference‘ uses the notation „L6814“, and the attribute „Name“ uses the title ‚Tanking‘ that would otherwise be applied to the IfcClassificationItem (if it was to be contained in the model).
The location of the classification reference may be found from a classification server that is available via the Internet, like http://www.ncl.ac.uk/…/tanking.htm#6814.

Because the relation between IfcRelAssociatesClassification and classification is actually made at the IfcClassificationNotationSelect class that allows classification to be either contained (full internal classification) or referenced (lightweight classification), it is possible to assign both contained and referenced classifications to an object by virtue of having multiple instances of IfcRelAssociatesClassification.

#1=IFCCALENDARDATE (31,8,1997);
#2=IFCCLASSIFICATION (‘RIBA’,’1’,#1,’Uniclass’);
#100=IFCDOOR ('gabcdeghijklmnopqrst01',#1001, );
#500=IFCRELASSOCIATESCLASSIFICATION('gabcdeghijklmnopqrst02',#1001,$,$,(300,#400),#100);
#510=IFCRELASSOCIATESCLASSIFICATION('gabcdeghijklmnopqrst02',#1001,$,$,(#100),#300);
#520=IFCRELASSOCIATESCLASSIFICATION('gabcdeghijklmnopqrst02',#1001,$,$,(#100),#400);
#200=IFCCLASSIFICATIONNOTATIONFACET ('L6814');
#210=IFCCLASSIFICATIONNOTATIONFACET ('B2186');
#220=IFCCLASSIFICATIONNOTATIONFACET ('Z6793');
#300=IFCCLASSIFICATIONNOTATION ((#200,#210,#220));
#400=IFCCLASSIFICATIONREFERENCE ('http://www.ncl.ac.uk/classification/uniclass/tanking.htm#6814','L6814','Tanking',#2);

10.4.2.8 Translation Between Classification Notations

Whilst several different classification notations may be applied to an object, there is no equivalence between the classification notations USED.
Therefore, the IFC Classification Model cannot be used to translate from one classification notation to another.
The reason for this is that, generally, it is possible to select from any of several different notations within a classification system for an object. The actual selection is the responsibility of the user according to circumstances.
Therefore, there is a many to many relationship between classification systems for which there is no resolution at this stage of development.

10.4.3 Referencing External Libraries

It is anticipated that many property sets defined externally to the IFC Model will be referenced from a library or database of product data held by a manufacturer/supplier, an information provider acting on their behalf or some other body holding significant information sources.

Referencing information from a library allows for the data to be retained in the library rather than in the IFC Model. In an information exchange/sharing scenario, this can be useful since it means that the amount of information needing to be transferred can be minimized.
The IFC Model provides a structure21 that enables property sets either to be referenced from the library in which they are held or delivered from the library into the IFC model as a property definition that can be associated with one or more objects.

The relationship class IfcRelAssociatesLibrary manages the linkage between the library and an object. It should be noted that the related objects in this case are instances of the IfcRoot class. This is because a selection of whether to associate the library with an IfcObject or an IfcPropertyDefinition has to be made. In this case, this cannot be done through the use of a SELECT data type since the EXPRESS language does not allow the declaration of inverse relationships from a SELECT type.

Therefore, the association has to be made to the common supertype of IfcObject and IfcPropertyDefinition which is IfcRoot.
Since IfcRoot also has other subtypes, a rule is applied to the relationship class which constrains the subtypes of IfcRoot that can have a library associated. In selecting the IfcLibraryReference to be used, the attributes of the IfcExternalReferencResource class are inherited.
These enable the location of the library to be captured. Location can be any fully qualified address such as a directory path on a CD. However, it is anticipated that it will more usually be a URL enabling referencing to occur across the World Wide Web.

An ItemReference may also be captured that enables a pointer into the library source to be captured. This provides a more complete identity for the information within the library.

21 Although this discussion relates to the referencing of property definitions, the model structure discussed can also manage the association of object information from libraries.

Kapitola 03:	PROJECT CONTAINER ELEMENT AND BASE SETTINGS	html	pdf orig
Kapitola 04:	SPATIAL STRUCTURE AND SPACE ELEMENTS	html	pdf orig
Kapitola 05:	BUILDING ELEMENTS	html	pdf orig
Kapitola 06:	BUILDING SERVICES ELEMENTS AND RELATED CONCEPTS	html	pdf orig
Kapitola 09:	SHAPE REPRESENTATION OF ELEMENTS	html	pdf orig
Kapitola 10:	PROPERTIES OF ELEMENTS	html	pdf orig

Obsah kapitoly

10 Properties of Elements

10.1 Property Definition