## 4 Concept Development
### Data Model for Software Products  
Figure 2 shows the developed data model for the products on the platform, which consists of the classes for products in a specific variant and version, product categories, properties, and product-type groups (PTG) in a specific version. The class Product represents software applications as well as web services or content, referenced by the enumeration Category. A relevant aspect of the modeling of software products is the specification of properties using the class property. This allows for grouping and filtering of products into entities of the ProductTypeGroup. The PTGs can later be used in workflows as placeholders for any products with comparable functionality, e.g., to replace a product in a toolchain for a specific task with a product with equivalent functions and properties.  
Figure 2: Relations between products, product-type groups, and properties in the data model.  
A Product is classified by different types of properties: general properties, technical properties, category-specific properties, and PTG-specific properties. General properties must be specified equally for all products on the platform, regardless of their respective product-type groups. Examples for general properties are the product name, and the product or API endpoint route. Technical properties must be specified for all products with regard to be available for the certification of import and export functionalities. This essentially includes the compatibility with interfaces and file formats to further perform a compatibility check for workflows. Category-specific properties must be differentiated for the app, service, and content categories. Required PTG-specific properties must be mandatory captured by the respective product in order to be classified in a specific PTG. Additional optional features can also be specified on a PTG-specific basis.  
Compatibility is the ability of two systems or components to exchange information without loss and to use this information in the same context [45]. Using different IT products from various vendors, the collaborative BIM method requires that information can be created and exchanged compatibly. The platform provides information on the supported formats for input and output data of IT products to enable a uniform, transparent source of information for software procurement in AECO industry. The BIMSWARM Composer is used for this purpose, wherein compatibility properties are considered. The basis for the compatibility checks in the Composer are the detailed software product information, provided in the form of compatibility properties, which represent the possible exchange formats. The data structure of the compatibility properties bases on the metadata for documents defined in DIN SPEC 91391-2 [9], in which an internationally standardized media type, a file schema, as well as the version and a subset of a file schema are defined.  
The integration of specific IT products within BIM use cases requires a data structure that can map the interaction of the corresponding applications, as well as the decentralized data store, and allows for monitoring the underlying process execution via a central platform. Toolchains represent a process in which applications, services, and content are modeled based on the process steps of, e.g., a BIM use case (see Figure 2).