User manual

Introduction

This IDS4ALL converter, developed by Simon Fischer, Harald Urban, Konstantin Höbart and Christian Schranz from the Digital Building Process research group at the TU Wien(https://www.tuwien.at/cee/ibb/zdb), transfers information requirements from an Excel file into an IDS file. In practice, information requirements are often defined in tabular form in Excel. This tool is designed to help you easily transfer them to IDS while taking advantage of the full functionality of IDS. The aim is to use an Excel file structure that is similar to the existing structures for information requirements in order to facilitate the adaptation to IDS.

The converter converts information requirements defined according to the ‘IDS4ALL template’ into an IDS file.

The template contains five work sheets:

IDS4ALL: Defines general information (metadata) about the IDS. This sheet is mandatory and its structure is predefined and must be adhered to.
Template: Contains all possible columns without any specifications as template to start with.
Example specifications: Contains examples for all functionalities of the IDS4ALL converter described in the user manual. Can also be used as template sheet.
User manual: Explanation of the IDS4ALL converter in English
User manual: Explanation of the IDS4ALL converter in German

In the following, the structure of the ‘Example specifications’ sheet is described in detail.

Structure of the ‘Example specifications’ sheet

The ‘Example specifications’ sheet introduces individual columns for possible entries in an IDS facet. In a classic or traditional information requirement table there is a column for the IFC entity, defining the applicability, and columns for the property set, property name, property data type and property value to define the requirements. In the same way, columns are introduced for the other IDS facets for both the Applicability and the Requirements. The names of the columns are predefined and must be adhered to. Columns for IDS Applicability start with ‘A.’. Columns for the IDS Requirements start with ‘R.’ Additional general columns (Phase, Role, Usecase, SpecificationCardinality) do not have a prefix. The order of the columns in the Excel table is not predefined. Likewise, not all columns must be present. Columns of IDS facets that are not required can be removed or omitted, which helps to keep the Excel file simple. This makes the IDS4ALL converter applicable to both simple classical information requirements and more elaborate ones using the full potential of IDS. However, if a facet is used, it must be ensured that all required columns of the facet are also used. For example, the ‘PropertySet’ and ‘Property’ entries are required for the Property Facet. If the Property Facet is used, at least these two columns must be filled in.

The definition of specifications works row wise. Different rows with the same Applicability are merged into one specification. If the different rows concern different requirements, they are merged with an ‘And’ logic into one specification. However, different rows often also concern the same requirements, for example, lists of possible property values are often listen in separate rows. Therefore, for the columns R.AttributeValue and R.PropertyValue different rows can also be used to list different possible values. If all other entries in the rows are equal, the values in the different rows are merged into one list of possible values with an ‘Or’ logic (see ‘Example specifications’, rows 12-21 and 22-31). The second way to define lists of ‘Or’ values is to use the | delimiter (see description of special characters/symbols). The order of the rows is not predefined. Also, empty rows are permitted. These are ignored by the converter (see ‘Example specifications’, rows 55 and 61). In general, the row structure is not hierarchical. Each row must be able to stand on its on. This means each row must contain all information and nothing from previous rows is inherited. However, structuring the data by header rows for a new entity or a new property set as in the ‘Example specifications’ is possible. A header row in the Applicability (see ‘Example specifications’, row 5) creates an additional general specification, in which all information of the more specific specifications is merged. It does not replace the more specific specifications, it is an additional one. A header row in the Requirements (see ‘Example specifications’, row 6) does not create a new specification. Instead, it is merged with the more detailed specifications below. However, if you separate your data into different IDS files by using the general columns, make sure that the general columns are also filled in for these header rows (should match one of the general data of the more specific specifications below, which one is irrelevant). Otherwise, the rows are not merged and incomplete facets are generated.

Below is a list of the predefined column names divided into Applicability, Requirements and general information, including an explanation:

Applicability column names	Requirements column names	General column names	Description	Permitted special symbols
A.Entity	R.Entity		Entity Facet: Definition of the IFC entity and the PredefinedType in the form ‘Entity.PredefinedType’. Caution: Standardized PredefinedTypes must be specified in upper case as defined in the IFC standard (see ‘Example specifications’, row 33). User-defined types can be written in lower case (see ‘Example specifications’, row 34).	all
	R.Description.Entity		Entity Facet: Description of the IFC entity. Can be used in combination with the Entity Facet in the Requirements to store general information about an entity in the instructions of the Entity Facet. Used, for example, to provide a unique description of all entities that appear in the information requirements. For this purpose, a specification can contain the entity facet in the applicability and in the requirements, with the description added in the requirements. (see ‘Example specifications’, rows 3 and 4). Adding a description is only possible in the requirements, because the IDS schema does not allow instructions in the facet when it is used in the applicability.	\&
A.PropertySet	R.PropertySet		Property Facet: Definition of the PropertySets	all
A.Property	R.Property		Property Facet: Definition of the Property name. This value is saved in IDS under the baseName in the Property Facet.	all
A.PropertyDatatype	R.PropertyDatatype		Property Facet: Definition of the data type of the property (e.g. IfcLabel, IfcBoolean).	\&
A.PropertyValue	R.PropertyValue		Property Facet: Definition of the property value	all
	R.PropertyURI		Property Facet: Definition of the URI of the property	\&
	R.Description.Property		Property Facet: Description of the property. Can be used in combination with the Property Facet in the Requirements to store general information about a property in the instructions of the Property Facet (see ‘Example specifications’, row 9). Adding a description is only possible in the requirements, because the IDS schema does not allow instructions in the facet when it is used in the applicability.	\&
A.Material	R.Material		Material Facet: Definition of the material name	all
	R.MaterialURI		Material Facet: Definition of the URI of the material	\&
A.Attributes	R.Attributes		Attribute Facet: Definition of the attribute name	all
A.AttributeValue	R.AttributeValue		Attribute Facet: Definition of the attribute value	all
A.Classification	R.Classification		Classification Facet: Definition of the classification name	all
A.ClassificationSystem	R.ClassificationSystem		Classification Facet: Definition of the classification system	all
	R.ClassificationURI		Classification Facet: Definition of the URI of the classification	\&
A.PartOfRelation	R.PartOfRelation		PartOf Facet: Definition of the used relation	all
A.PartOfEntity	R.PartOfEntity		PartOf Facet: Definition of the IFC entity that is to be linked to the current element via the specified relation	all
	R.Cardinality		Definition of the cardinality of a facet. The cardinality of a facet in the requirements determines whether the defined requirement must be fulfilled (required), may be fulfilled (optional), or must not be fulfilled (prohibited). This column refers to all facets in the requirements. If several different facets are used in a row and a cardinality is defined, this applies to all facets in that row. If the facets should have different cardinalities, they can be split across several rows, as several rows in a specification are merged (provided that the applicability matches). This column is optional. If it is not used, each facet is given the default value ‘required’.	\&
		Phase	Indication of the project phases in which the specification is required. This information is saved in IDS in the instructions of the specification and is also used for separating into individual IDS files (depending on the entry in the IDS4ALL worksheet).	\& and \| (have same meaning in this column)
		Role	Specification of the role(s) (e.g. architecture, structural design) that is (are) responsible for the specification. This information is saved in IDS in the instructions of the specification and is also used to separate individual IDS files (depending on the entry in the IDS4ALL worksheet).	\& and \| (have same meaning in this column)
		Usecase	Indication of the use cases in which the specification is required. This information is saved in IDS in the instructions of the specification and is also used to separate individual IDS files (depending on the entry in the IDS4ALL worksheet).	\& and \| (have same meaning in this column)
		SpecificationCardinality	Definition of the cardinality of a specification. The cardinality of a specification defines whether the applicable elements must be present in the model. Three different values are valid in this row (required, optional, prohibited). These values are saved in the applicability of a specification and transformed into the “occurs” attributes of the attribute part of an IDS. – required: minOccurs = 1 maxOccurs = unbounded – optional: minOccurs = 0 maxOccurs = unbounded – prohibited: minOccurs = 0 maxOccurs = 0 By default, the cardinality of the specifications is optional if the column is not used.	none
		SpecificationIfcVersion	Definition of the IFC version for a specification. If this column is used, it overrides the IFC version from the IDS4ALL spreadsheet. In rows where no specific IFC version is defined, the default versions from the IDS4ALL spreadsheet remain. Allowed values: – IFC2X3 – IFC4 – IFC4X3_ADD2	\& and \| (have same meaning in this column)

Special characters / symbols

Special characters/symbols are required to define more than just simple values in individual cells. The special characters always indicate a complex restriction or special processing of the values in the cell. Therefore, they are not allowed as normal text. The special characters are not permitted in each column. The list above shows which special characters are permitted in which column.

Special character / symbol	Definition	Description
\|	Or	This symbol separates values of an ‘Or’ list within one cell. It is used to define a list of possible values in one cell. The ‘Or’ symbol has different functionalities in the Requirements and the Applicability. In the Requirements, these values are saved in IDS as a complex ‘enumeration’ restriction (see ‘Example specifications’, rows 47 and 48). In Applicability, such a list is used to describe multiple elements to which a requirement applies. This is very well suited for defining the applicability for generally valid values that also apply to specifications with a more specific applicability (see ‘Example specifications’, lines 10, 11, 46). In order to add the more specific values to the general values, such a line is divided into several specifications, one for each of the different ‘Or’ values. This results in specifications with specific applicability, which can be combined with the later specific specifications. Let’s look at the definition of FireRating in the ‘Example specifications’. We divide the possible fire resistance values into values for load-bearing walls (REI…) and non-load-bearing walls (EI…) using the LoadBearing property in the Applicability. The general values ND (not defined) and NE (not required) apply to both categories. To avoid having to include them in both lists, we create a separate list with these two values and define their Applicability for LoadBearing as True\|False. These two ‘Or’ values are split into two individual specifications, one for LoadBearing True and one for LoadBearing false, each with the FireRating values ND\|NE. The next lines then have the same applicability as one of the existing specifications and can be merged. This results in two different specifications. An exception is the use of the SpecificationCardinality ‘Required’. If this function is used to require the existence of elements in the model, the ‘Or’ values cannot be split into individual specifications, as this would lose the logic that only one of the defined elements must be contained in the model. CAUTION: Therefore, specific and general values cannot be combined when SpecificationCardinality ‘Required’ is defined and incomplete selection lists may result.
\&	And	This symbol makes it possible to link several values with an ‘And’ (see ‘Example specifications’, row 49). It is used to combine several facets into one specification. This logic always refers to all columns that belong to a facet. Care must be taken to ensure that the same number of ‘And’ symbols are used in all columns of the Facet (e.g. PropertySet: Pset_WallCommon&Pset_WallCommon; Property: LoadBearing&Compartmentation; PropertyValue: True&False). With an optional parameter in IDS, as with PropertyValue, values can also be left blank (e.g. True&). This means that the second value is not defined and the IDS specification specifies that the property must exist with any value. Different facets in a line are also merged into one specification. Furthermore, several lines that have the same applicability are also merged into one specification.
pattern=	Regex pattern	Definition of a schema for the character string of the value (see ‘Example specifications’, row 49). Is defined by regular expressions (regex).
length=	Exact length of a value	Restriction of the number of individual characters of a value
length>=	Minimum length of a value	Restriction of the number of individual characters of a value
length<=	Maximum length of a value	Restriction of the number of individual characters of a value (see ‘Example specifications’, row 50)
<	smaller than	Restriction of a numerical value
<=	smaller or equal as	Restriction of a numerical value (see ‘Example specifications’, row 51)
>	greater than	Restriction of a numerical value
>=	greater or equal as	Restriction of a numerical value

Limitations

The decimal separator of a numerical value must be a point or a comma.

The name of a specification cannot be defined by the user. It is generated automatically from the IFC entity.

Defining custom values for the purpose and milestone of the IDS is not possible. These values are automatically generated from the general columns. The phases are saved as milestones and the combination of roles and use cases as purpose.

IDS4ALL Converter Documentation

Introduction

Structure of the ‘Example specifications’ sheet

Special characters / symbols

Limitations