Editing IFC - Industry Foundation Classes/IFC classes

All data in IFC belongs to an IFC class. IFC classes can be divided into two categories: ''rooted'' and ''non-rooted'' classes. ''Rooted'' classes inherit attributes from an IFC class called <code>IfcRoot</code>, whereas ''non-rooted'' classes do not. This <code>IfcRoot</code> class is special because it provides the following four attributes:

{| class="wikitable"
! Attribute
! Required
! Description
|-
| <code>GlobalId</code>
| Yes
| A unique identifier of the object, generated by a computer. This is usually created automatically by the BIM authoring tool.
|-
| <code>OwnerHistory</code>
|
| This special attribute can store names, dates, organisations, software vendor, and contact details of people who are responsible for this object.  This is usually created automatically by the BIM authoring tool.
|-
| <code>Name</code>
|
| This can contain a short text that names the object.
|-
| <code>Description</code>
|
| A sentence or so to describe the object.
|}

All ''rooted'' classes are semantically significant to end-users and created specifically for a project or library. Examples include <code>IfcProject</code>, <code>IfcBuilding</code>, and <code>IfcWall</code>. They are usually annotated in documentation, or named specifically in schedules. These objects are generally useful to end-users, and for this reason can be tracked with a <code>GlobalId</code> and given a <code>Name</code>.

In contrast, ''non-rooted'' classes do not have the ability to assign a <code>GlobalId</code>, <code>Name</code>, or otherwise, and are used to store non-project-specific data like XYZ coordinates, RGB colour values, vectors, and so on. One example is <code>IfcCartesianPoint</code>. They are needed from a technical perspective, and are usually automatically generated by the BIM authoring tool, and can usually be safely ignored by end-users. It is important, however, to know that they exist as power users may encounter them when trying to optimise [[OpenBIM]] data.

Classes are often described as what they inherit from. For example, ''rooted'' classes can be described as classes that inherit from <code>IfcRoot</code>, or subclasses of <code>IfcRoot</code>. If a class inherits from another class, or is a subclass of another class, it inherits  the same abilities of that class, such as the ability to have certain attributes, properties, or relationships, assigned to it. Subclasses do not actually inherit the values of the attributes themselves, but only the ability to have that attribute.

== Subclasses of <code>IfcRoot</code> ==

''Rooted'' classes may be further broken down into three types of classes.

{| class="wikitable"
! IFC Class
! Description
|-
| <code>IfcObjectDefinition</code>
| These subclasses describe "objects" or "things" that relate to the AEC industry. This includes walls, people, and tasks. You may think of them as the "nouns" in IFC.
|-
| <code>IfcPropertyDefinition</code>
| These subclasses describe properties of "objects" and "things". They themselves are not an object, but instead a property or quantity like fire rating, energy usage, or volume.
|-
| <code>IfcRelationship</code>
| These subclasses describe relationships between "objects" themselves, between properties, or between objects and properties. The relationships can be objects that contain other objects, connect to objects, have system inputs or outputs, or are assigned a property or quantity.
|}

== Subclasses of <code>IfcObjectDefinition</code> ==

Although there are many IFC subclasses, there are only a handful relevant to different BIM authors, and it is useful to provide a summary of them. Underneath these handful are many subclasses which go into more detail, but knowing these these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive.

{| class="wikitable"
! IFC Class
! Description
|-
| <code>IfcContext</code>
| This special category holds the starting point of IFC data, by describing either a project or library. There are only two subclasses: <code>IfcProject</code> and <code>IfcProjectLibrary</code>. See [[IFC projects and contexts]] for more information.
|-
| <code>IfcElement</code>
| These hold physical built elements that we come across every day, like slabs, columns, beams, furniture, pipes, cables, ducts, and so on. Example subclasses of <code>IfcElement</code> include <code>IfcColumn</code>, <code>IfcBeam</code>, and <code>IfcFurniture</code>. They may have geometry associated with them.
|-
| <code>IfcSpatialElement</code>
| These describe spatial concepts, such as sites, buildings, bridges, storeys, and spaces. These <code>IfcSpatialElement</code> classes can contain <code>IfcElement</code> elements inside them, such as a slab being inside a building storey. Example subclasses of <code>IfcSpatialElement</code> include <code>IfcSite</code>, <code>IfcBuilding</code>, and <code>IfcSpace</code>.
|-
| <code>IfcElementType</code>
| These describe construction types. A construction type may be assigned to an <code>IfcElement</code>, just like a particular <code>IfcWall</code> might have a particular construction type of 2 layers of plasterboard on a metal frame. Example subclasses of <code>IfcElementType</code> include <code>IfcWallType</code>, <code>IfcDoorType</code>, and <code>IfcWindowType</code>.
|-
| <code>IfcStructuralActivity</code>, <code>IfcStructuralItem</code>
| These are useful for structural analysis. They hold data to describe an anaytical model, including members, nodes, connections, loads, and forces, as well as the results from the calculations. Example subclasses include <code>IfcStructuralCurveMember</code>, <code>IfcStructuralPointConnection</code>, and <code>IfcStructuralPointReaction</code>.
|-
| <code>IfcActor</code>, <code>IfcControl</code>, <code>IfcProcess</code>, <code>IfcResource</code>
| These are useful for scheduling information, describing responsibility, tasks, resources, and timelines for construction sequencing or project planning. Example subclasses include <code>IfcTask</code>, <code>IfcConstructionMaterialResource</code>, and <code>IfcWorkSchedule</code>.
|}

== Subclasses of <code>IfcPropertyDefinition</code> ==

The following non-exhaustive table describes common subclasses used to describe properties, which can later be assigned to objects.

{| class="wikitable"
! IFC Class
! Description
|-
| <code>IfcPropertySet</code>
| These classes help store properties of other classes, such as <code>IfcElement</code>. For instance, it may store a fire rating associated with an <code>IfcWall</code>. Some properties names and values are standardised within IFC, but end-users can also create their own properties. See [[IFC attributes and properties]] for more information.
|-
| <code>IfcQuantitySet</code>
| This is similar to <code>IfcPropertySet</code> but focuses on calculated quantities (lengths, areas, volumes, weights, etc). Some quantity names and values are standardised within IFC, but end-users can also create their own quantities. See [[IFC attributes and properties]] for more information.
|-
| <code>IfcPropertyTemplateDefinition</code>
| If you don't want to actually to store the value of a proprety but instead want to describe a template of what properties exist, which are required, and what data is valid for the purposes of exchange requirements or company standards, then this template subclass allows you to do so.
|-
| <code>IfcPreDefinedPropertySet</code>
| For some reason, some properties to do with door and window linings are given a special status in the IFC schema and have their own category. This will likely disappear in the future and merge into <code>IfcPropertySet</code>.
|}

== Subclasses of <code>IfcRelationship</code> ==

Although there are many IFC subclasses, there are only a handful relevant to different BIM authors, and it is useful to provide a summary of them. Underneath these handful are many subclasses which go into more detail, but knowing these these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive.

{| class="wikitable"
! IFC Class
! Description
|-
| <code>IfcRelAssigns</code>
| This relationship is used when a particular object supplies a resource or fulfills a task for another object. It is commonly used for resource management and construction sequencing, determining processes, resources, and actions performed by people. Example subclasses include <code>IfcRelAssignsToResource</code>, <code>IfcRelAssignsToProcess</code>, and <code>IfcRelAssignsToProduct</code>.
|-
| <code>IfcRelAssociates</code>
| This relationship is used when a particular object has a source of information associated with it, such as an external document, classification system like Uniclass, project library, or material definition. This is commonly used for facility management. Example subclasses include <code>IfcRelAssociatesDocument</code>, <code>IfcRelAssociatesClassification</code>, and <code>IfcRelAssociatesMaterial</code>.
|-
| <code>IfcRelConnects</code>
| This relationship is used when a particular object is joined physically or virtually to another object. This is usually used in analytical models, such as structural analysis where members and nodes connect to each other, MEP systems analysis where ports join together, or environmental analysis, where spaces have boundaries and are covered by particular material layers. Example subclasses include <code>IfcRelConnectsStructuralMember</code>, <code>IfcRelConnectsPorts</code>, and <code>IfcRelSpaceBoundary</code>. 
|-
| <code>IfcRelDecomposes</code>
| This relationship is used when a particular object (physical or virtual) is built up of smaller object parts. Smaller parts may be simple aggregated into a larger whole, or projecting from a object, or embed itself within another object. Example subclasses include <code>IfcRelAggregates</code>, <code>IfcRelProjectsElement</code>, and <code>IfcRelVoidsElement</code>.
|-
| <code>IfcRelDefines</code>
| This relationship is used when a particular object can be defined by a common set of definitions, such as properties, manufacturer / construction types, or a template of definitions. This relationship is very commonly used, specifically to define properties (both buildingSMART standard properties, and custom user properties) to objects, and define construction types. Example subclasses include <code>IfcRelDefinesByProperties</code>, <code>IfcRelDefinesByType</code>, and <code>IfcRelDefinesByTemplate</code>.
|}

== A summary of non-rooted elements ==

There are far too many ''non-rooted'' elements to list in totality, however a curated selection as shown below give a indication of the types of data that are stored in an IFC file, which can be reused by ''rooted'' elements.

{| class="wikitable"
! IFC Class
! Description
|-
| <code>IfcMaterial</code>
| A material may be named, and then have further ''non-rooted'' classes assigned to it, such has simple RGB colours, textures, and material properties for environmental simulations.
|-
| <code>IfcCartesianPoint</code>
| As you might expect, IFC can store 2 or 3 dimensional Cartesian coordinates. This is one of the building blocks of many other ''non-rooted'' classes, such as the ability to locate an object in space, or build up geometric representations.
|-
| <code>IfcFacetedBrep</code>
| A huge variety of geometric forms may be described in IFC. One commonly known format is a faceted BREP, or series of polygons that describe the surface of an object.
|-
| <code>IfcPerson</code>
| Information about people and organisations can be recorded, which is especially useful as some countries have legislation that requires this to be stored.
|-
| <code>IfcPropertySingleValue</code>
| This commonly used class can define a single property in terms of a property name and its associated value. In addition, there are other classes that allow more complex properties in tabular or calculated form to be stored.
|-
| <code>IfcObjective</code>
| This little-known class can store design intentions, strategies, and objectives to be then associated with objects or portions of the BIM model.
|-
| <code>IfcRegularTimeSeries</code>
| When scheduling, events may occur at predictable time intervals, which may be stored.
|}

== List of IFC classes ==

There are multiple versions of IFC in use in the industry, and each version has hundreds of IFC classes. This makes it impractical to describe them in their entirety in a separate community wiki. However, there are some resources available for those who do want a list:

* [https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/link/inheritance-general-usage-all%20entities.htm Official IFC4.2 specification list of all classes]
* [https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/link/inheritance-general-usage-object%20types.htm Official IFC4.2 specification list of all object types]
* [[Media:Ifc-4.2.0.0.ods|IFC4.2 classes and property sets in spreadsheet format]]
* [https://blenderbim.org/search-ifc-class.html BlenderBIM Add-on free online IFC4.2 class search tool for built elements]
* [https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/inheritance_index.htm Official IFC2x3 TC1 specification list of all classes]
* [[Media:Ifc-2.3.0.1.ods|IFC2x3 TC1 classes in spreadsheet format]]
* [https://bim.tech.fr/ifc2x3 Hierarchy of IFC2x3 TC1 classes] - [https://bim.tech.fr/ifc Hierarchy of IFC4 ADD1 classes]

[[Category:Industry Foundation Classes (IFC)]]
@@ Line 1: / Line 1: @@
-{{IFC_Documentation}}
+All data in IFC belongs to an IFC class. IFC classes can be divided into two categories: ''rooted'' and ''non-rooted'' classes. ''Rooted'' classes inherit attributes from an IFC class called <code>IfcRoot</code>, whereas ''non-rooted'' classes do not. This <code>IfcRoot</code> class is special because it provides the following four attributes:
-When we talk about BIM concepts, we refer to objects such as walls, doors, and windows. Sometimes we refer to non-object elements like buildings, materials, and annotations. We also refer to other concepts such as coordinates, properties, and geometry. Each distinct noun, element, object, or concept that we refer to is called a "class" in IFC, and is what gives the name [[Industry Foundation Classes (IFC)]]. The jargon "class", instead of the more widely understandable term "element" or "concept" is borrowed from the software development industry, and remains with us today.
-All digital data in IFC belongs to an IFC class. IFC classes can be divided into two categories: ''rooted'' and ''non-rooted'' classes. ''Rooted'' classes inherit attributes from an IFC class called <code>IfcRoot</code>, whereas ''non-rooted'' classes do not. This <code>IfcRoot</code> class is special because it provides the following four attributes:
 {| class="wikitable"
@@ Line 52: / Line 49: @@
 == Subclasses of <code>IfcObjectDefinition</code> ==
-Although there are many IFC subclasses, there are only a handful relevant to different BIM authors, and it is useful to provide a summary of them. Underneath these handful are many subclasses which go into more detail, but knowing these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive.
+Although there are many IFC subclasses, there are only a handful relevant to different BIM authors, and it is useful to provide a summary of them. Underneath these handful are many subclasses which go into more detail, but knowing these these broad categorisations exist help with an understanding of IFC data. The following table is not exhaustive.
 {| class="wikitable"