Before moving on to the software examples (how to ensure the principles of RDS/CCI), let’s take a general look with the help of some examples of how the introduction of a unified classification system helps to design an asset-centric unique ID that considers the construction whole lifecycle and is both human and machine readable. If another unique ID has been previously used, it must be linked to the RDS/CCI codes, which are not covered here. In general, it can be noted that any IT system can use its own unique ID value and we may not be able to redefine it in that software/application (take for example BMS or building management system, some security system solutions, room register, property register, etc. – all of them may have their own unique ID logic defined, some for example only in the form of numbers). Therefore, in the context of digital construction or in the context of asset maintenance resulting from it, we have to perform mutual integration of information, where the unique ID resulting from the construction information and based on, for example, the RDS/CCI classification system, is linked to other information systems that are important to the client. Software default unique IDs (GUID, Element ID, Handle etc.) are not human or machine readable, in addition, different software packages do use different unique IDs, and when transferring similar information, we have to do multiple different integrations (extra work).

The adoption of a unique ID across information systems becomes critical if we want to move to model-based maintenance, where, among other things, optimal information exchange transfers must be defined (EIR or exchange information requirements as stipulated by the EN ISO 19650 series). At the same time, it is important to talk about a single, unique ID concept (human and machine readable) at any stage of the construction life cycle, where it is necessary to make summaries or extracts from the quantities/ volumes (either from the building information model or related documentation), which are then used for budget compilations or connected to other information databases. Based on its unique code, RDS/CCI enables automatic connections with other sub-tables (e.g. certain construction aids/resources or construction activities are connected to certain construction components). RDS/CCI provides an opportunity to talk about quantities both on a more general level (international dimension) and also in a more detailed presentation, which already includes RDS/CCI application tables (RDS/R), where in addition to the general level code, the type/subtype context is also introduced. Please note that the RDS/R application tables (types/subtypes) are a supplement to the RDS/CCI core table. RDS/R is a separate development that is briefly introduced in this example.

Classification usually means defining some specific attributes, using them in the context of digital / physical assets. These attributes should be clearly defined and also named, only then can we clearly understand the property value conveyed through them (attribute term = property name that carries the property value). In the examples here, we use CIA-DD attribute groups/logic.

In the CIA-DD table, a uniform structure is ensured through the attribute code (2 letters + 3 numbers), which must remain in place in any application if uniform information exchange is required. In general, however, the name of our attribute also consists of a textual entry, which is not clearly prescribed by the CIA-DD table and which can therefore also be defined on a project or customer basis. Therefore, here is an example of one of the possible naming schemes. Although the textual entry is somewhat free, it must remain within the boundaries set by the property code/definition/standard and should not be confusing. A reference to the CIA-DD table can be added to the attribute code (if it is used in some application), where you can read more detailed information about the given attribute. In this way, attribute definitions are managed from one specific place, where, in turn, connections to other information systems can be found (e.g. IFC property, ETIM code, etc.).

In this example, we limit ourselves to the attributes that are describing class codes of RDS/CCI core tables + additional attributes related to type and ID. At the same time, it is also possible to create an extended view, which includes the attribute information of the so-called yellow/red tables (CCI-EE part). However, it is worth emphasizing that the attributes of the core tables are the most decisive, and all the attribute information does not have to be included in the model. Thanks to the attributes of the core tables, additional attributes can be linked outside the models as well.

Below is a list of CIA-DD attributes used in the following examples. It is important to ensure that attributes with the same structure are used in any software, so that we can understand the information exported from any source software in the same way. Please note that some attributes are only used for certain types of elements, for which you can find more information in the software examples.

Attribute name	General description of the attribute
AN010_Name	common name, asset type name (e.g. Hinged door)
AN112_Type	provides the asset element type code (e.g. QQC10)
AN114_ID	provides an ID associated with the type (e.g. QQC10_01 – i.e. hinged door in placement 01)
AN130_System	provides a description/name of the system (e.g. Above ground wall system)
AN132_SystemType	provides the system code (e.g. B12)
AN134_SystemID	presents the ID associated with the system (e.g. B1201 – unlike the door, for the sake of compactness we write the ID value immediately after the type number, but if desired it can also be distinguished, for example, with an underscore)
AN160_Subsystem	provides a description/name of the part of the system (e.g. Plastered facade w/ homogeneous core)
AN162_SubsystemType	provides the subsystem code (e.g. AD12)
AN164_SubsystemID	presents the ID associated with the subsystem (e.g. AD1201 – unlike the door, for the sake of compactness we write the ID value immediately after the type number, but if desired it can also be distinguished, for example, with an underscore)

Note. We generally write the textual part of the attribute name more compactly and preferably without spaces or any other punctuation marks (including avoiding another underscore or hyphen – so-called CamelCase). The main purpose of this textual part is to make the unique code human-readable, but the alphanumeric part is still more important than that, because it is used for later integrations/extractions. It is clear that the previously presented entries could also be written shorter, but in this example, their readability is the main consideration!

Some attributes are a combination of previous attribute values, so they are presented in a separate table. Please note that these properties use the values of the previously described properties + additional symbols. Therefore, it is important that the value of the basic property is available in a so-called pure form, which allows it to be edited in any way (according to the client-specific information requirement).

Attribute name	General description of the attribute
AR360_UniqueID	collection of two or more reference designations assigned to an object of which at least one unambiguously identifies this object (e.g. if we want to mark the location of a door (building component) in a specific wall (technical system) that belongs to the external wall system (functional system), we can write it: B1201.AD1201.QQC10_01

The examples also include attributes that help to aggregate material-based information or organize quantity related information.

Attribute name	General description of the attribute
PU280_MaterialType	main material type/category/group/class (e.g. wood, concrete, etc.)
VP198_QuantityUnit	measurement unit (e.g. pcs, m, m2, m3)
VP199_QuantityValue	measurement result (numerical value, without units)

Separators defined in the EN IEC/ISO 81346 standard series are used for combining properties, which have a specific meaning and thus help to navigate more easily when it comes to a combined value.

Character/symbol	Description
.	(dot) is generally used as a separator between two different codes, which individually refer to different tables, either simply as a letter code, with a type number or as an ID – e.g. B.AD – here the functional system code (B) is distinguished from the technical system code (AD)
=	(equal sign) as related to the functional aspect of the object (e.g. a wall system can be referred to as =B )
–	(minus) as related to the product aspect of the object (construction element)
+	(plus) when related to the host installation aspect of the object (e.g. meeting room +BAB)
++	(2x plus) when related to the location-based aspect of the object (eg if the sofa is in the meeting room BAB, we add the room reference as: ++BAB)
%	(percent) when related to the type aspect of the object (e.g. we refer to a specific window type as %QQA10)
#	(bars) as related to other aspects of the object
< >	is used when it is desired to refer to a specific table/classifier from which the following code comes – for example, in RDS/CCI tables, <CO> denotes the components table, <CS> denotes the built spaces table. Note. Alternatively, IEC/ISO letter codes can also be used (see below).
/	(slash) is used when you want to mark/refer to two different belongings (reference identifiers) in one data field – for example <CO>QQA /+<CS>BAA1001 means that we are talking about the window (QQA) that is in the room BAA1001 (room reference as <CS>), the slash distinguishes two different reference identifiers and + indicates that we are talking about belonging to another element
_	(underscore) is used as an additional character if you want to distinguish the type and ID value more compactly, thereby improving readability and, if necessary, allowing you to use, for example, 3 digits instead of 2 digits in the ID value.

It is very important to distinguish between the value represented by an attribute and the extra character that uses that value. These are different things! And as long as the value is a property in itself, you can do “whatever” with it, in other words, mark it with one or another reference identifier (character) according to the information requirements.

So, if I add a tag with the code QQA to the plan, it may not tell the user anything, while if I add an additional markup (reference, character) in front of it: <CO>QQA, I clearly indicate that it is a window, because this is the code used by the window when viewed accordings to the components <CO> table. However, I do not want to mark this additional value <CO> directly to the QQA property, because it makes it difficult to reuse the QQA value in some other situation (e.g. when creating a unique ID, etc.).

RDS/CCI uses a two-letter code when referring to a specific table. However, it can also be done in the manner marked by ISO 81346-12, but with certain fundamental differences. Namely, the codes for the following tables are provided there (EN ISO 12006-2 extended view).

Letter code	Description
A	Actvity space
B	Built space
C	Construction complex
D	Construction aid
E	Construction entity
G	Construction agent
L	Construction element
P	Construction product
R	Construction process
S	Storey
Z	Zone

In the following examples, we will use ISO 81346-12 single-letter codes where necessary.

In addition to the above, other attributes that represent information content may also be included, but again using the CIA-DD code. Some examples can also be found in software examples/templates. When including information content, it is worth considering whether its presence is necessary/important in the context of construction information or whether it is reasonable to include this information into another information system. Accordingly, the scope of information content in the included templates has been kept to a minimum. Of course, the context of the client/project participant always comes into play here, what information content is needed!

In the following subsections, we will discuss more specific examples in which the previous principles have been applied. Although the software examples are limited, the principles used therein can be applied to any software that a particular user prefers. However, in the more technical part (which follows the more general examples), we will take a closer look at how the software templates presented are structured and how to implement the classification system in specific software.