UIMDF Catalogue

The UI Fragment Properties Model defines properties for the meta description of UI Fragments and their types. The properties are intended to be used in order to provide machine-interpretable information that allows the automatic selection and adaptation of UI fragments dependending on the intended use case, the context of use, and more. The properties are also for the use of semi-automatic applications like search functionality in fragment libraries and based on that the sharing of once developed UI fragments on marketplaces or to distribute them on another way. This is being facilitated through fragment properties as they specifically take into account that fragment developers and solution developers are seperated into multiple persons, roles, or business units. The model or the fragment catalog is organized as follows: - Audit Properties: For organizing and maintaining libraries and repositories of ui fragments. - Technical Properties: For describing the UI Fragment as a computational artifact that provides its own API for the integration into a solution. - Use Case: For describing the main information about what is represented in the UI fragment and which task can be conducted using the UI fragment. - Context-of-Use: For describing the constraints that influenced the UI design. - Content Markup Properties: Are used to apply any property to sections or parts of the UI fragment. - Property Types: The type descriptions of all properties in the catalogue that enable the property instanciation in form of propety value statements.

The domains catalog is a collections of some basic domain descriptions. A domain, in general, is a field of knowledge each of which is characterized by its own wording, concepts and their typical representations, techniques, processes, tasks, expectations, etc. When designing computer systems to support tasks that can be seen as belonging to one or more of these domains, the domain characteristics should be taken into account. This catalog defines a hierarchical domain structure where each sub domain is the specialization of its parent domain. The general topic of this catalog is to specify domains that are relevant for plant operations. However, a more general approach may be developed in future. Thus, the top-level domains are separated into the aspects of the technical system, the product, and human aspects since every technical system needs to be operated. Each technical system is designed according to the needs of the industrial branch. This is why another top-level domain category lists different industrial branches. In order to specify the concrete domain a techical system has been designed for, it may be necessary to enlist multiple of the domains specified in this catalog. The combination of domains may be seen as an implicitly specified new domain that has overlapping aspects with each of the listed domains. This approach also enables to further define more domains or domain aspects by use of different not necessarily consistent criteria. In this catalog, not all domain entries will be fully specified as more specification work needs to be done.

The tasks catalog defines abstract task classes each of which characterizes human activities that are intended to change the state of system entities, environmental entities or even the state of personnell or third parties. The task definitions in this catalog are abstract task classes, also referred to as task types. This means that these definitions are independent of the actual entities the task is performed with. The state change that is associated with a task class is, thus, also to be described in an abstract way, independent of the actual entities. However, it is still possible to restrict a task class to entity classes that is that certain classes of tasks can only be performed with or are only specified for certain types of entities. The task definitions (TaskType elements) within the catalog are associated to an inheritance semantics that is expressed by use of the tree containment structure. The tree structure implies that subordinate task definitions are specializations of their respective superordinate task definitions. Subordinate definitions, thus, inherit all properties, activities, task characeristics, duties, relations, needed tools, etc. However, the specialization also implies an alteration to these features by the subordinate definition in any of these regards. Task description categories on the other hand are simple collections of task definitions without further semantics. Currently, this catalog only provides a basic collection of task definitions that might not match tasks with similar terms used, but dissenting defiitions and structures, that are common to the industry. Also the categorization may be subject to future improvements, as there may be multiple categorization criteria applied that are not clearly expressed. The main idea in mind when identifying task types was a plant's lifecycle and the respective activities for every phase.

The UI device properties catalog contains properties that can be used to select appropriate UI fragments depending on the properties of the available platforms and on the design constraints of the respective fragment. The device properties presented herein may also be used for the design process of interactive systems. However, this catalog is not fully developed. Single properties may not be sufficient regarding the data type modeling and also the actual properties may not be up-to-date. This catalog has been designed in order to show how the properties modeling could be done in general and in order to make some device properties available to case studies regarding the selection of UI fragments. The main categories of the available properties are organized depending on the modality, i.e. the used or available information channels to and from the user. That is how multimodal devices providing a combination of different modalities can be designed. - Abstract Properties: Mostly classes of information on an abstract level that can be provided by users as system input are specified. Each of the properties does not rely on the actual channels used for information exchange. - Visual Properties: Properties regarding the visual information in- and output are specified. Human personnell uses their eyes to perceive information from the interactive system. Visual or graphical information input will be performed indirectly, e.g. by using their hands. - Auditive Properties: Properties regarding the auditive information in- and output are specified. Human personnell uses their ears to perceive information and their voices to provide information. - Haptical Properties: Properties regarding the haptival information in- and output are specified. Human personnell might mostly use their hands to percieve and provide information. - Physical Properties: Properties regarding the physical shape of interaction devices are being specified. - Property Types: Specialized property types for the device description are defined. Other property types from the common property types catalog will also be used.

The Common Property Types Catalog contains property data type definitions that are commonly used throughout other catalogs. For that, the property type collection 'Basiy Types' contains various Property Type elements.

The purpose of this catalog is to make concepts that are specified in arbitrary contexts or documents available to modelers within a development environment. For that, such concepts are listed including unique identifiers that can be used to refer to these concepts. For example for different software platform architectures or user interface technologies, usable identifiers are specified that may be shared, and thus, used consistently. Another example are concepts, terms, classes, or relations that are specified in standards such as from the DIN, ISO, EN, IEEE, etc. organizations. These concepts are defined in the standards, however, they are not referrable as there is no commonly defined address scheme. This catalog is probably the one with the most experimental status as some of the information has been used to specify properties elsewhere and the catalog entries have not been streamlined or properly developed. However, since these concepts may be referred to by case-studies, the catalog has not yet been reworked. In some cases, for the purpose of compactness, concept definitions within a concept category are just listed without further documentation or URL references being printed. The documentation page of the containing category may be surfed to in order to fetch an entry's identifier. The catalog is subdevided into the following parts: - The external concept category 'Plant Model Concepts' may be referred to from within a plant model in order to provide semantics. - The 'AAS Semantics' concepts may be used in conjunction with an AAS metamodel, if such a metamodel poses restrictions. E.g. a generic reference may provide the semantics of a type reference in the case of model elements not providing such a specialized reference feature or only too few. - The 'User Interfaces' category provides various extendable subcategories that provide valid values for value statements of properties that are defined in other categories. - The 'Standards' category provides referrable identifiers for concepts that are defined in some selected standards for the use in plant models and models referring to those plant models.

The UI platforms catalog is intended for future specifications of user interface hardware. It is subdevided into the categories 'Platform Types' for the description of the execution environments as defined by hardware computing features, and 'Device Types' for the description of final devices and their usage characteristics. Both catagories are intended to provide a classification or inheritance scheme, that allows to specify actual platforms and devices with their respective properties, but also categories of platforms and devices with shared properties. This is useful if, for example, software solutions shall be developed and described that may be executable and usable on a number of similar platforms or devices. For the further description of platform or device types, appropriate properties are to be used that are defined elsewhere as, for example, in the ui device properties catalog.