Ein Modell lässt sich nicht attribuieren

In einer IFC-Datei hat eine Wand genau neun Attribute. Neun — man kann sie abzählen, sie stehen in der Norm, und es kommt kein zehntes dazu. Trotzdem steht in Lastenheften, Kursunterlagen und Einführungstexten immer wieder derselbe Satz: Die Objekte im Modell werden attribuiert.

Der Satz meint etwas, das es so nicht gibt: Attribute, die man hinzufügt. Gemeint ist meistens etwas anderes, und dieses andere hat einen eigenen Namen. Die Verwechslung ist kein Sprachfehler — sie ist der Grund, warum später jemand in einer Datei nach einem Wert sucht, der in ihr steht, und ihn nicht findet.

Das ist meine Beobachtung aus dem Unterricht, nicht eine Auszählung der Fachliteratur. Ich nenne deshalb aus der Literatur keinen Titel und keinen Autor; ein öffentliches Beispiel folgt weiter unten. Wer den Satz nie gehört hat, kann hier aufhören zu lesen — alle anderen kennen ihn.

Warum das mehr ist als ein Wort

Ein Bauwerksmodell ist kein Bild, sondern eine geordnete Datensammlung — genau davon handelt Warum eine Zeichnung kein Modell ist. Geordnet heißt: Jede Angabe hat einen Platz, und der Platz ist verabredet.

Genau an dieser Stelle richtet das Wort attribuieren Schaden an. Es klingt, als gäbe es einen Platz — ein Bauteil, an das man Angaben heftet wie Zettel an eine Pinnwand. Dann muss man nur noch sagen, welche Angaben man will, und die Sache ist vereinbart.

Es gibt aber nicht einen Platz, sondern mehrere, und sie verhalten sich völlig verschieden. Wer das nicht weiß, kann in einer Anforderung nicht angeben, welchen er meint. Und eine Anforderung, die den Platz nicht nennt, lässt sich nicht prüfen: Eine Prüfregel, ein Filter und eine Mengenermittlung greifen immer auf eine bestimmte Stelle zu. Liegt der Wert woanders, ist er vorhanden und trotzdem unsichtbar.

Die Datei ist dann nicht falsch. Sie ist unbrauchbar. Das ist der teurere Fall, weil ihn niemand als Fehler meldet.

So läuft es ab, und dabei macht niemand etwas falsch. Im Lastenheft steht, die Bauteile seien zu attribuieren. Der Planer versteht: Angaben ans Bauteil — und trägt den U-Wert dort ein, wo sein Werkzeug ihm ein Feld dafür anbietet. Die Datei geht hinaus. Sie ist vollständig, jede Wand trägt ihren Wert, und niemand hat gegen die Anforderung verstoßen.

Wochen später zieht jemand die Kennwerte für die Kostenermittlung und bekommt eine leere Spalte. Er sucht an der Stelle, an der so ein Wert üblicherweise steht — und dort steht nichts, weil nie verabredet wurde, welche Stelle gemeint war. Am Ende tippt jemand die Werte von Hand ab. Das Modell hat an dieser Stelle nichts gespart; es hat Arbeit hinzugefügt.

Und der Vorwurf trifft niemanden. Die Anforderung war nicht verletzt worden — sie war nur nicht prüfbar formuliert.

Was ein Attribut ist — und warum man sie zählen kann

Ein Attribut ist ein Feld, das im IFC-Schema festgelegt ist. Das Schema ist der Bauplan des Formats; es beschreibt für jede Art von Ding, welche Felder es hat. Diese Felder sind Teil der Definition, nicht eine Zutat.

Sehen Sie selbst nach. Die amtliche Dokumentation führt für die Wand eine Tabelle, und sie ist durchnummeriert: IfcWall in der IFC-Dokumentation.

Neun. Danach ist Schluss. Ein zehntes lässt sich nicht anlegen — nicht vom Planer, nicht vom Büro, nicht vom Auftraggeber. Wer eines will, muss das Schema ändern, und das Schema ist eine internationale Norm: ISO 16739-1:2024, in Deutschland übernommen als DIN EN ISO 16739-1:2024-09. Diese Ausgabe entspricht IFC 4.3 — der Fassung, deren Dokumentation oben verlinkt ist.

Fest ist dabei die Zahl der Felder, nicht ihr Inhalt. Befüllt werden die Attribute sehr wohl: Eine Wand bekommt einen Namen, eine Beschreibung, eine Positionsnummer, eine Art. Was sich nicht machen lässt, ist ein zehntes Feld.

Genau genommen sind es die neun direkten Attribute. Die Dokumentation führt darunter noch sogenannte inverse Attribute — Rückverweise, über die zum Beispiel die Eigenschaftssets an der Wand hängen. Sie sind kein Feld, das man ausfüllt, sondern die Kehrseite einer Beziehung.

Deshalb stehen dort auch keine Kennwerte. Kein U-Wert, keine Brandschutzklasse, keine Kostengruppe, kein Schichtaufbau. Ein Attribut sagt, dass und als was ein Ding im Modell existiert. Es sagt nicht, welche Eigenschaften es hat.

Das ist keine Sparsamkeit, sondern der Zweck: Die neun Felder muss jedes Programm der Welt lesen können. Was jedes Programm können muss, kann nicht beliebig wachsen.

Und was dann gemeint ist: Eigenschaften

Eine Eigenschaft ist eine Angabe, die nicht zur Definition gehört und deshalb angehängt wird — in einem Behälter, der Eigenschaftsset heißt. Ein Eigenschaftsset ist eine benannte Gruppe zusammengehöriger Angaben, und ein Bauteil kann beliebig viele Eigenschaftssets tragen.

Von den Eigenschaftssets gibt es zwei Sorten, und diese Unterscheidung ist die praktisch wichtigste des ganzen Themas.

Die standardisierten. Sie sind im Schema vorgesehen, heißen überall gleich und beginnen mit Pset_. Für die Wand führt die Dokumentation in IFC 4.3 26 solcher Sets, dazu zwei Sets für Mengen mit dem Präfix Qto_. Das bekannteste ist Pset_WallCommon mit elf Einträgen — darunter IsExternal (außen oder innen), LoadBearing (tragend oder nicht), FireRating (Feuerwiderstand) und ThermalTransmittance (der U-Wert).

Die eigenen. Jedes Projekt darf so viele anlegen, wie es braucht, mit frei gewählten Namen. Eine einzige Regel gilt: Der Name darf nicht mit Pset_ beginnen. Sonst wäre von außen nicht mehr zu erkennen, was Standard ist und was Hausgebrauch. Im Referenzprojekt dieses Blogs tragen eigene Sets deshalb ein Kürzel des Projekts vor dem Thema.

Und hier liegt der Preis der Freiheit. Ein Wert in Pset_WallCommon steht an einer Stelle, die jedes Programm kennt, das IFC liest. Derselbe Wert in einem selbst benannten Set ist genauso vorhanden — aber wer ihn auswerten will, muss wissen, dass es dieses Set gibt und wie es heißt. Steht das in keiner Vereinbarung, findet er es nicht.

Und es gibt einen dritten Behälter, den man leicht übersieht: die Mengen. Länge, Fläche, Volumen und Gewicht liegen nicht in einem Eigenschaftsset, sondern in einem eigenen Behältertyp, dem Mengenset; die standardisierten erkennt man am Präfix Qto_. Das ist keine Formsache. Wer Mengen als Eigenschaften anfordert, verlangt sie an einer Stelle, an der sie nicht entstehen; wer sie als Eigenschaften liefert, liefert Zahlen, die ein Auswertungswerkzeug nicht als Mengen erkennt. Drei Behälter — Attribut, Eigenschaftsset, Mengenset —, und jeder trägt etwas anderes. Die Verwechslung kostet in allen drei Richtungen dasselbe.

Was gilt — und welches Wort weiterhilft

Gebildet ist das Wort nicht falsch. Attribuieren kommt vom lateinischen attribuere, zuschreiben. Im allgemeinen Sprachgebrauch sind Attribut, Eigenschaft und Merkmal fast dasselbe, und manche Werkzeuge nennen ihre Eingabefelder ebenfalls Attribute. Wer so spricht, spricht nicht schlecht Deutsch.

Wie verbreitet das ist, zeigt ein amtliches Dokument. Die Modellierungsrichtlinie zur Prüfung von BIM-Modellen nach der Landesbauordnung NRW (Fassung vom 24.06.2026) verlangt unter anderem die Angaben, ob ein Bauteil außen liegt und ob es tragend ist — in einem eigenen Eigenschaftsset. Auf Seite 11 heißt es, diese Angaben lägen teilweise schon in den „standardisierten Attributfeldern". Gemeint sind IsExternal und LoadBearing in Pset_WallCommon — Eigenschaften, keine Attribute.

Das ist kein Vorwurf an die Verfasser. Es zeigt, dass die Begriffe selbst dort durcheinandergehen, wo Modelle amtlich geprüft werden sollen. Und es zeigt nebenbei den Preis der Freiheit von oben: Dieselbe Angabe steht dann zweimal im Modell, einmal im Standardset und einmal im eigenen. Für Angaben, die der Standard nicht kennt, ist ein eigenes Set richtig — für diese beiden nicht.

Was gilt, entscheidet trotzdem nicht der Sprachgebrauch. Sobald eine Angabe in eine IFC-Datei soll, gilt allein die Bedeutung, die das genormte Schema festlegt — DIN EN ISO 16739-1. Gepflogenheiten — im Büro, im Werkzeug, in einer Richtlinie — haben sich dem unterzuordnen, nicht umgekehrt. Sonst meint jedes Dokument mit demselben Wort etwas anderes.

Weiter hilft ein drittes Wort: Merkmal. Ein Merkmal ist die fachliche Angabe, bevor sie einen Platz hat — Feuerwiderstand, Positionsnummer, außenliegend. In der deutschen Normsprache für Datenkataloge ist es der neutrale Oberbegriff. Erst bei der Übergabe ins Modell trennt es sich: Die Positionsnummer landet im Attribut Tag, der Feuerwiderstand als Eigenschaft FireRating in Pset_WallCommon. Meist wird ein Merkmal zur Eigenschaft, selten zum Attribut, manchmal zu einem der anderen Träger, die weiter unten in der Tabelle stehen.

Wer fachlich von Merkmalen spricht, braucht das Wort attribuieren nicht. Er legt sich erst dort fest, wo es darauf ankommt: beim Träger.

Der eine Gedanke

Attribute kann man befüllen, aber nicht vermehren. Was „attribuieren" meint, ist fast immer das Vermehren — und das heißt Eigenschaft.

Wer den Unterschied einmal gesehen hat, liest jede Anforderung anders. „Die Wände sind zu attribuieren" sagt nichts: Die Attribute sind längst da, befüllt werden sie ohnehin — sie waren nie die Frage. Was der Satz eigentlich verlangen will, steht nicht darin — welche Eigenschaft, in welchem Set, mit welchem Wert.

Und der Unterschied ist auch der Grund, warum zwei Dateien, die beide „vollständig attribuiert" heißen, sich nicht vergleichen lassen. Sie können dieselben Angaben enthalten und an verschiedenen Stellen führen.

Was Sie damit anfangen können

1 · Die Prüffrage, die jede Anforderung überlebt.

Woran hängt diese Angabe?

Stellen Sie diese Frage an jede Zeile eines Lastenhefts, einer Liefermatrix, einer Merkmalliste. Es gibt sechs mögliche Antworten, und sie schließen einander aus.

Der Name ist ein Attribut, keine Eigenschaft — das ist der Fall, an dem es am häufigsten kippt. Eine Eigenschaft beschreibt ein Bauteil; sie benennt es nicht.

2 · Schreiben Sie den Satz um, der nicht prüfbar ist.

Nehmen Sie eine Anforderung aus einem echten Dokument und ersetzen Sie jedes attribuieren durch eine Angabe, die man nachsehen kann.

Die rechte Spalte ist länger — und genau das ist ihr Ertrag. Sie nennt Träger, Behälter, Namen und Wert. Ein Prüfwerkzeug kann sie abarbeiten; die linke Spalte kann niemand abarbeiten, auch kein Mensch.

3 · Zählen Sie einmal selbst nach.

Öffnen Sie die Seite zu IfcWall in der amtlichen IFC-Dokumentation. Im Abschnitt Attributes stehen die neun, durchnummeriert. Scrollen Sie weiter zu Property sets — dort stehen die standardisierten Eigenschaftssets untereinander, jedes mit seinen Einträgen.

Diese zwei Abschnitte auf einer Seite sind die ganze Unterscheidung, und sie sind frei zugänglich. Wer sie einmal nebeneinander gesehen hat, braucht das Wort attribuieren nicht mehr.

Und wenn Sie wissen wollen, wohin das führt. Für genau diese Unterscheidung gibt es eine eigene, genormte Anforderungssprache: IDS, Information Delivery Specification. Ihre Bausteine heißen Entität, Attribut, Eigenschaft, Klassifikation, Material und Zugehörigkeit — es sind fast dieselben Träger wie in der Tabelle oben, in maschinenlesbarer Form.

Eine Anforderung, die den Träger nennt, lässt sich damit automatisch prüfen. Eine, die ihn nicht nennt, lässt sich nicht einmal aufschreiben. Das ist der Stoff eines eigenen Beitrags. Es ist aber auch der Grund, warum diese Unterscheidung keine Begriffsklauberei ist: Sie ist die Bedingung dafür, dass eine Forderung überhaupt überprüfbar wird.

Der Satz zum Mitnehmen

Das Schema legt fest, was ein Bauteil ist. Die Eigenschaften sagen, was es für dieses Projekt bedeutet. Das Erste ist abzählbar und gilt überall. Das Zweite ist offen — und alles Offene muss verabredet werden, sonst verabredet es jeder für sich.

Eine Anforderung, die den Träger nicht nennt, ist keine Anforderung. Sie ist eine Absichtserklärung, die man später nicht prüfen kann.

Im nächsten Fachartikel wird es unangenehm konkret: Dieselbe Angabe, in mehreren Programmen erzeugt — und nachgesehen, wo sie jeweils landet. Mit Fassungsnummer und Messdatum, denn ohne die altert so ein Befund still.