Personal tools
You are here: Home / Implementation / frequently asked questions / faq specific ifc spec

faq specific ifc spec

Specific question about the IFC Specification

 

  1. I keep hearing the word 'schema'. What is a schema and how does it relate to IFC?
  2. What is a property set?
  3. How can I see all entities, sub types, types, etc. in the IFC specification?
  4. In IFC there are many optional attributes, why? What does it mean, if I receive "empty" optional attributes?
  5. Which attributes are written to an IFC file and how to obtain the other attributes (inverse and derived attributes)?
  6. What does a dollar character ($) and a star character (*) mean in an IFC file?

 


 

Q:   I keep hearing the word 'schema'. What is a schema and how does it relate to IFC?

A:    A schema is a data model in a formal machine-readable notation.  The IFC specification consists of such a schema and associated informal human-readable semantic definitions.  The schema describes a set of data types and their possible relationships. There are subtly differing termini:  While the IFC specification defines a “data model” or “product data model”, a collection of objects — instances — which conform to this data model is called “product model” or, more to the point of IFC, “building model”.  Data can be formally checked for conformance to the schema.  This ensures that data representations are syntactically correct. To a limited degree, the schema also enforces semantic integrity on a low level.

The IFC schema, like some other data models which are written in EXPRESS, comes in two flavours:  The “long form” and the “short form”.  Software implementers use the long form schema which is comprised of all data types in a single schema.  The short form schema is used for documentation purposes and in schema development.  It consists of a number of sub-schemas for different topics, e.g. “shared building elements schema”, “architecture domain schema”, and so on. The term IFC schema, if not specified otherwise, always relate to long form schema.


Q:    What is a property set?

A:   Most objects can have properties attached to them that have little or no relationship to other objects. The IFC model differentiates between attributes that are directly attached to the object as attribute of the entity, and properties, group in a property set and assigned to the object by an relationship. The latter is the more flexible way to extent applicable properties.
Furthermore these properties are evolving over time, and may be specific to particular regions, countries, or projects. The IFC schema supports storing and transmitting these properties in named sets. The IFC schema recommends property sets as part of the IFC Specification already, but regional adoptions and applications may define more. MSG has published an XML schema, called Property Set Definition schema PSD to defined the properties and property sets.


Q:     How can I see all entities, sub types, types, etc. in the IFC specification?

A:    Use the IFC Specification published as a HTML document set here. Flat lists of all defined types, enumerations, select types, and entity types are available in the HTML documentation via “alphabetical listing” in the “Browsing documentation…” frame. A tree view of all subtypes of entity types is available under “hierarchy listing” in the “Browsing documentation…” frame.  This requires JavaScript to be enabled in the browser.


Q:     In IFC there are many optional attributes, why? What does it mean, if I receive "empty" optional attributes?

A:    An empty attribute (i.e. an attribute having indefinite value) generally means that no value is known or that no particular value is applicable in the respective information exchange. Since the IFC specification is developed to cover many exchange use cases at different stages of the building life cycle, there is hardly any attribute for which providing a value is mandatory at each life-cycle stage and exchange purpose. Therefore almost all attributes are optional in the IFC specification.

A view definition that narrows the scope of IFC implementation for a given exchange use case may determine, that attributes, that are optional in the IFC specification, have to have values asserted. A few attribute definitions in the IFC specifications specify default values which shall be assumed if an exchange file contains the indefinite value.


Q:     Which attributes are written to an IFC file and how to obtain the other attributes (inverse and derived attributes)?

A:    So-called explicit attributes (the usual plain attributes) occur directly in IFC exchange files.  If an explicit attribute is defined as OPTIONAL in express and an object (an entity instance) does not provide a value for such an attribute, then the attribute still occurs in the file as a $ (dollar sign).
So-called INVERSE attributes (reverse cross references between entities) do never occur in IFC files.  So-called DERIVED attributes (attributes which are to be calculated from explicit attributes) either do not occur in a file or occur as a * (asterisk) — see next question. To obtain inverse or derived attributes, you either can rely on a capable ISO10303 toolbox or have to implement them on your own as far as you need them. This is documented in more detail in ISO 10303-21.


Q:    What does a dollar character ($) and a star character (*) mean in an IFC file?

A:    The $ character encodes the indefinite value, i.e. it appears if an optional attribute has not been filled in.  (Note, the indefinite value is sometimes also used in the EXPRESS schema of the IFC data model.  There it is encoded as “?”, not as “$”.) The * character encodes so-called omitted parameters.  These are attributes which are defined as a regular explicit attribute in a supertype but redefined as a derived attribute in a subtype (and the record in the IFC file is an instance of the subtype). More information about the encoding of IFC files can be found in ISO 10303-21.