What is Information Delivery Specification (IDS)
The Information Delivery Specification (IDS) is a standard in development from buildingSMART for defining information requirements in a way that is easily read by humans and interpreted by computers.
This standard in development helps people in the built asset industry to better define their exchange requirements and adds clarity amongst various stakeholders. It ensures asset owners can specify accurately what they want, and allows project participants with a better insight into what they need to deliver. It adds certainty and clarity when used in combination with other standards and services.
Traditionally the information requirements are shared in ways that are not computer interpretable, such as excel sheets or PDFs and it is very difficult for the right people to access the data that is pertinent to them for a particular situation.
Users that want to use data in the built asset industry usually know what information they need for a task but don’t always know how to specify it. This can have a big impact on things like automated code compliance checking, which requires different information than automated cost estimation, for example.
With IDS a user can require the use of properties (including quantities and attributes), materials, classifications, entity types and object dependency (partOf). At the time of writing this chapter, IDS does not have the capability to define the details of geometry.
An IDS example
Let’s say that a user wants all spaces in a model to be classified with a certain code and have a couple of properties.
The could be described as “All Space data in a model shall be classified as [AT]Zimmer and have NetFloorArea and GrossFloorArea (both in set called ‘BaseQuanitites’) and a property called AT_Zimmernummer in the property set Austria_example.
This is only an example. It could be any requirement. Users can also further refine requirements to not apply to all spaces but only to spaces with certain characteristics. For example, spaces with a certain property and/or property value, or spaces that are part of a certain hierarchy, or spaces that are classified in a certain way.
This goes for all objects, not only spaces. The requirements of classification codes, materials, quantities, attributes, properties, materials and some relations can also be set to the selection (sometimes also called filtering; formally called applicability in IDS) of objects.
Back to our example. Formatting this human-readable requirement in an IDS looks like this:
This is the formal XML file for this one specific requirement. An IDS file is an XML file that follows the XML standards.
A different way to visualise this XML is like this:
Here you see the same information, but structured as a table. This is a very generic view that can be applied to all XML files.
There are also specific viewers that read the XML-based IDS and visualise the IDS in a human readable way. In such a viewer our example looks like this:
As you see, there are many different ways to visualise the information in an IDS file.
What we also see in the last example is that there are still options to add human readable documentation to the requirements.
While IDS is designed to be interpreted by computers, humans will inevitably need to add information to the BIM dataset in many cases. The creator of an IDS can therefore leave instructions that clarify any requirements for a human to also input data.
Advanced use-cases
While the example above is relatively simple, IDS actually allows more advanced definitions of requirements. It allows users to require properties to be shared with a certain kind of measure.
There are extensive ways to define restrictions on values as well. For example the value of a property might only be selected from a list of allowed values. Or when the value is a number, it might have a certain minimum, maximum, or range. Even pattern matching is an option available in IDS. IDS uses the XSD restrictions for this to improve implementation reliability.
Restrictions on specifications are another example of an advanced feature. The minOccurs and maxOccurs attributes in XML allows users to define a minimum, maximum, range or an exact number of objects that need to be in the BIM dataset.
The PartOf facet allows users to require certain structures in the BIM dataset that are typical when using Industry Foundation Classes (IFC). Requirements that an object should be part of an assembly or part of a group can be defined using this functionality.
Relation between IDS and IFC
Although IDS can be used to specify any kind of data in the built asset industry, it works best on data that is structured according to the Industry Foundation Classes (IFC) standard.
As you see in the example (in the line ‘specification’), this specification requires there to be at least one object like this in the model. It also states that this requirement is made for both IFC 2x3 and IFC 4. The applicability part of this IDS also states ‘IFCSPACE’. This is an IFC entity.
Although the specification can be used for non-IFC data, the IDS has a natural and logical fit with IFC. This can also be seen by the split between attributes and properties, and the ‘PartOf’ relationships in advanced requirements.
Relation to buildingSMART Data Dictionary (bSDD)
When a user receives an IDS from a client, they can check their data against the requirements defined in IDS. As we mentioned earlier, the IDS can contain human-readable explanations and instructions for the receiving human to understand the requirements better.
It is also possible in IDS to add a link (formally called a Uniform Resource Identifier - URI) with more information about a property or classification code. This is where the relation to the buildingSMART Data Dictionary (bSDD) comes into the picture.
In the example we created, there is a URI attached to the property of Zimmernummer. A URI starting with identifier.buildingsmart.org refers to an object that can be found in the bSDD.
Following this URI will get the user more information about a property, beyond the level of detail which can be specified within the IFC. The bSDD hosts detailed, standardised information about definitions, units, relations to other objects, etc. It does this for classification codes, properties (including attributes and quantities) and materials, for both international and national-specific standards.
The options to define restrictions on values in IDS are the same as the ones bSDD supports. This allows a seamless interaction between IDS and bSDD.
Adding the URI to a property or classification code (or system) allows users, and in some cases even computers, to gather more information about the requirement and the typical use of objects.
More information about the bSDD can be found in the special bSDD chapter of this book.
Scope and usage of IDS
An IDS file can contain multiple requirements. These requirements are independent ‘blocks’ and have no reference to other requirements in the file. This is intentionally done to create the ability to copy-paste requirements between files.
At the time of writing, multiple software vendors are implementing IDS editors and authoring tools to facilitate users with an easy way to create IDS files.
In the future buildingSMART anticipates the existence of IDS libraries where examples of separate requirements are shared for everyone to use. Users can search IDS requirements and drag them into a selection basket to create their own IDS file.
An important scope definition of IDS is that it focuses only on ‘information delivery specifications’. This means that the IDS structured requirements can define what information is needed and how it should be structured. It is important for automated workflows and scripts to receive information in the way it can be automatically processed, and this is the objective of IDS.
However, IDS cannot be used to define design requirements or so called ‘rules’. So, a requirement that all windows in a toilet space need to have an opaque glass is not possible within IDS; but a requirement that all windows need to have a property that defines what kind of glass is in the window is a perfect definition to define in IDS. A rule checker or other algorithm should then be used to check if windows in toilet spaces have an opaque glass or not.
There is a grey area on this since IDS allows restrictions of values. Future releases of IDS will further refine this scope, or extend the possibilities of IDS to define rules. Practical use-cases and consensus will define the future possibilities of IDS.
IDS in depth
All technical information about IDS can be found on GitHub, where code development, documentation, and examples are kept: https://github.com/buildingSMART/IDS.
IDS has been identified by the international community as the most advantageous method for automated compliance checking by validation of the alphanumerical information requirements. It supports information requirements authoring by providing users with a set of possibilities on what can be required of the models.
Relation to other initiatives
There are many ways to define information requirements. Excel seems to be the most popular, but has limitations.
Other initiatives are the Product Data Templates (PDTs), Level of Information Need (LOIN), Exchange (or Employer) Information Requirements, BIM Execution plans, the ‘exchanges’ part of mvdXML, SHACL in the linked data domains, and more.
All of these initiatives have advantages and limitations. Depending on the use-case other standards or initiatives might be a better choice. A comparison created by Tomczak et.al. can be found here:
For most use-cases in openBIM the IDS is the recommended solution to define information requirements. It balances compatibility with IFC and bSDD on the one hand, with usability and reliability on the other hand.
There are several software tools available to check an IFC file against the requirements of an IDS file. Typically the results are shown in a viewer. To share the results it is recommended to use the BIM Collaboration Format (BCF). BCF is a structured way to exchange information about IFC objects with project partners. More information about BCF can be found in another chapter in this book.
Authors:
Léon van Berlo, Technical Director, buildingSMART International
Robin Drogemuller, Professor of Virtual Design & Construction, Queensland University of Technology
Sara Omrani, Senior Lecturer in Virtual Design & Construction, Queensland University of Technology