Classification in IFC: systems, references, URIs and bSDD
Summary
Classification is what lets an element be matched by software to a line in a cost plan, a section of a specification or an entry in your asset register. Without it, someone does that matching by hand at handover and again every time the register is updated. A model can look complete in a viewer and still carry no usable classification at all.
The report looks at classification from four sides: how much of the model is classified, with which system, whether the codes are complete, and whether each code is linked to an online definition (a URI), ideally in the buildingSMART Data Dictionary (bSDD). You meet these checks on the Information and Consistency pages, and in the bSDD and Classified capabilities.
How IFC stores classification
IFC, the open file format for building and infrastructure models, uses three pieces:
| IFC entity | What it holds |
|---|---|
IfcClassification | The system itself: its name, source, edition and, optionally, a location on the web. |
IfcClassificationReference | One code from that system: the code, its name and, optionally, a Location that holds a URI pointing to its definition. |
IfcRelAssociatesClassification | The link that attaches a code to an element, or to the element's type so that every occurrence inherits it. |
The IFC class of an element (IfcWall, IfcBeam) is not a classification. Some exporters still write it as one, with a URI in the buildingSMART IFC namespace. The report keeps those references out of all classification figures and checks them separately: if the referenced IFC class does not match the element's own class, it is reported as a schema class mismatch.
Where you meet it in the report
| Page | Card | What it shows |
|---|---|---|
| Information | Coverage per class | Per IFC class, the share classified and the share with a URI. The filter Not fully classified lists the classes with gaps. |
| Information | Classification systems | Each system declared in the file and how many elements use it, with a bSDD note where it applies. |
| Information | Classification references & URIs | Every code: its name, system, how many objects use it (or unassigned) and its URI. You can filter on With URI, bSDD and Without URI. |
| Consistency | Where classification is stored | On element only, via type only, both, or unclassified, plus a table of incomplete or conflicting references. |
| Consistency | Classification systems | Each system marked as tool default or classification system, with its number of codes, elements and URI status. |
| Consistency | External references | Links to documents and libraries, and whether they can be reached. |
The checks and how they are scored
Each check gives a score from 0 to 100 and has a weight within its dimension. Information checks count double in the overall quality score, Consistency checks three quarters. The full list is in What we check.
| Check | What it measures and how it scores | Weight |
|---|---|---|
| Classification coverage (Information) | Share of objects with at least one classification reference, on the element or through its type. Elements (openings excluded) are counted together with the project and its spatial elements, such as sites, storeys and spaces. The score is the share itself. | 1.5 |
| Classification linked to URIs (Information) | Share of code assignments whose code carries a URI. Only scored when objects are classified. | 0.5 |
| Classification integrity (Consistency) | References without a code, and elements whose IFC schema reference names another class, are counted as missing. Points come off in proportion to the share of elements affected, at most 60 points. A further 10 points come off when any reference has no name or no system, or is declared but never used. | 0.75 |
| Classified with a real system (Consistency) | Share of elements classified by the most used system that is not an authoring-tool default. The score is that share. | 0.75 |
| Duplicate classification systems (Consistency) | The same system declared more than once instead of once and shared. Minus 5 points for each extra declaration, down to a minimum of 20. | 0.75 |
| Multiple classifications (Consistency) | Elements with more than one code from the same system. This can be deliberate, so it is shown for information only and not scored. | Info |
| Document & library references (Consistency) | See below. | 0.75 |
Classification also matters on the Structure page. A proxy, the generic IFC object used when no specific class was chosen, is far less anonymous when it carries a code. The check Share of unclassified proxies (weight 1.5) counts the proxies without one. See Proxies: when they are acceptable.
Tool defaults and real systems
Many authoring tools write their own category list into the file as a classification system. Those categories mostly repeat the IFC class and add no meaning outside the tool. The report treats a system as a tool default when its name or source contains Archicad, Revit, Autodesk, Graphisoft, Tekla, Allplan, Vectorworks, Bentley, BIM object or the word default. Everything else counts as a real system. The report does not judge which national or international system you use; that choice belongs in your information requirements.
The Consistency page also warns about systems declared without any references: the system is named in the file, but no element carries one of its codes. The report notes this is common when parameters were left unassigned in the authoring tool, or when the codes were written into property sets instead.
URIs and the bSDD
A code such as 23.15.10.10 only means something to a reader who knows the system behind it. A URI, a web address stored in the reference's Location, lets software look the definition up. The report counts a code as having a URI when that field is filled, and marks it bSDD when the address starts with identifier.buildingsmart.org, the address of the buildingSMART Data Dictionary. URIs in the buildingSMART IFC namespace are left out, because they describe IFC classes, not your classification.
The bSDD capability uses the same rule. Its condition reads URI from buildingSMART Data Dictionary (non-IFC): at least one address must start with identifier.buildingsmart.org and must not be in the IFC namespace. The report looks for such addresses on classification systems, on codes (used or not), on properties and on material classifications.
The report reads classification URIs but does not test whether they open. A URI with a typing error still counts.
Document and library references
IFC can also point outside the file: IfcDocumentReference to drawings, manuals or certificates, and IfcLibraryReference to product or object libraries. The check Document & library references tests each distinct web address, with a time limit of three seconds. File paths and other values are listed, but not tested. With broken links the score drops by 25 points per broken link and stays between 10 and 60; when every link answers, it scores 100. A file without such references is not scored. The External references card adds a caution: not every BIM tool imports document references, so check that the receiving tool keeps them before you rely on them.
Capabilities that depend on classification
| Capability | Condition involving classification |
|---|---|
| Classified | Silver at 90% coverage or more, gold at 99.5% or more. Needs at least 50 elements. |
| Classified + URI | The same tiers, applied to the lower of classification coverage and the share of codes with a URI. |
| bSDD | URI from buildingSMART Data Dictionary (non-IFC). |
| Real IFC | Unclassified proxies ≤ 2% of elements. A classified proxy also weighs less in the effective proxy share. |
| AI ready, Operations / FM, Product passport | Classified ≥ 80%, among other conditions. |
Classification coverage is one of the three coverages averaged in the Completeness factor of the Forensic BIM score™, and classification URIs count towards its Semantics factor. All capability rules are listed on Capabilities.
What to ask your supplier for
- Name the classification system and edition in your information requirements, and check it appears under Classification systems as a classification system, not a tool default.
- Attach codes as IFC classification references, preferably on types so that every occurrence inherits them.
- Give each code a code value, a name and a URI, in the bSDD where your system is published there.
- Declare each system once and let all references point to it.
Frequently asked questions
Our file passes the buildingSMART validation. Why is classification coverage low?
The validation service checks that the file follows the IFC rules. Classification is optional in IFC, so a file with none at all can pass. See Passing the buildingSMART validation is not the same as good data.
Our codes are in a property set. Why don't they count?
Software that reads IFC looks for classification references. A code in a property is a text value under a name chosen by the author, and only a person who knows that convention can find it. Ask for the codes to be exported as classification references as well.
Is it wrong for an element to carry two codes from one system?
Not necessarily. Two codes from one system can add meaning or point to an error; it depends on what was intended. That is why Multiple classifications is shown for information only. Check with the author or coordinator.