Ilona Paweloszek
email: ipaweloszek@zim.pcz.pl

Jerzy Korczak
email: jerzy.korczak@ue.wroc.pl

Ilona Pawełoszek

An Approach to Discovery of Customer Profiles

Keywords: Customer profile, Data mining, ontology of marketing, semantic models

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

In the age of personalization, one of the greatest challenges for marketers is eliciting and communicating customer requirements. A customer profilealso known as a customer personais a set of data describing a high-level abstraction model that depicts the key characteristics of a group of consumers who could be interested in a specific product. Personas are fictitious, specific, concrete representations of target users [START_REF] Wyse | Advantages and Disadvantages of Face-to-Face Data Collection[END_REF].

Construction of customer profiles promotes overall internal alignment and coordination of marketing strategy with product development which helps to drive down cost of promotion by reducing the number of useless marketing messages and ineffective contacts with customer. Although making use of customer feedback is an established method of gathering marketing intelligence, interpreting data obtained by traditional structured methods such as questionnaires, interviews and observation, is often too complex or too cumbersome to apply in practice [START_REF] Wyse | Advantages and Disadvantages of Face-to-Face Data Collection[END_REF][START_REF] Pruitt | The persona lifecycle: Keeping people in mind throughout product design[END_REF].

Today, a lot of data can be gathered in an automatic way from transactional systems. These data describe the features of customers (such as age, the place of residence, number of family members, etc.) as well as behaviors (such as time and purpose of transactions performed by the customer, amounts and frequency of expenditures).

The discovery of useful knowledge from databases is one of the major functions of analytical decision support systems [START_REF] Montgomery | Marketing Information Systems. An Emerging View[END_REF][START_REF] Stair | Principles of Information Systems[END_REF]. Various data mining algorithms can be used to discover and describe behavior patterns of individuals and to relate them with personal data collected in CRM data bases.

Unfortunately, most of the systems lack semantics, which can be considered a key component for business knowledge management. Marketing databases are today very broad. The volume of information is so huge that the analysis by classical database methods is becoming increasingly difficult. In recent years a few solutions have appeared improving the process of database exploration and the integration of semantics in decision-making processes [START_REF] Nogueira | Comparison of classifiers efficiency on missing values recovering: Application in a marketing database with massive missing data[END_REF][START_REF] Cao | Ontology-based Integration of Business Intelligence, Web Intelligence and Agent Systems[END_REF][START_REF] Matsatsinis | Intelligent support systems for marketing decisions Springer Science & Business Media[END_REF][START_REF] Grassl | The reality of brands: Towards an ontology of marketing[END_REF][START_REF] Pinto | Ontology-supported database marketing[END_REF][START_REF] Pinto | Ontology based Data Mining -A contribution to Business Intelligence[END_REF][START_REF] Zhou | An application intersection marketing ontology. Theoretical computer science: Essays in memory of Shimon Even[END_REF].

A few proposals for marketing ontologies have appeared in recent years. E. Barbu [START_REF] Barbu | An ontology-based system for the marketing information management[END_REF] presents General Marketing Ontology, in which the main concepts originate from sources such as Web marketing repositories and tools allowing for the semi-automatic creation of ontology on the basis of documents important to managers of SMEs. H. Saggion describes a project of integration in the BI system, founded on the module of gathering information in an e-business domain using ontology and natural language [START_REF] Saggion | Ontology-based information extraction for business intelligence[END_REF]. The documents describing profiles of companies are collected from different sources, analyzed, grouped and annotated within the ontology. The semantic models are also exploited in many search engines dedicated to marketing information, i.a. Magpie, KIM, SemTag, On-To_-Knowledge, Vision, h-TechSight [START_REF] Bouquet | ConTeXtualized local ontology specification via CTXML[END_REF][START_REF] Dill | Semtag and seeker: Boot-strapping the semantic web via automated semantic annotation[END_REF][START_REF] Domingue | Magpie: Supporting Browsing and Navigation on the Semantic Web[END_REF]. The methods of data exploration have become a very popular tool used in marketing strategies [START_REF] Linoff | Data Mining Techniques: for Marketing, Sales, and Customer Relationship Management[END_REF][START_REF] Ohsawa | Data Mining for Design and Marketing[END_REF][START_REF] Poh | Neural networks for the analysis and forecasting of advertising and promotion impact[END_REF][20]. It is a well-known fact that the effectiveness of marketing activities depends to a large degree on directing relevant advertisements to the right recipients. One of the essential functions of customer relationship management is customer segmentation which is the process of dividing the customer data set into distinct and internally homogeneous groups in order to develop differentiated marketing strategies according to their characteristics [START_REF] Tsiptsis | Data mining techniques in CRM: Inside customer segmentation[END_REF].With this aim in mind, a segmentation of customers consists in finding customers with similar preferences, needs and behavior. A segment corresponds to target class of customers, for example, travelers that are people with high income who travel often. In case of large data sets the experiential classification can be insufficient to distinguish segments. In such situations data mining methods such as clustering and decision trees can be helpful. The terms of cluster and segment are often used interchangeably, which is not always the same.

Clusters are groups of customers with similarities found by a clustering algorithm. Therefore, a cluster not necessarily represents a segment, so the semantic interpretation of clusters is required and might be difficult. It should be noted that in many cases the segment can consist of a few clusters.

The segmentation of customers not only facilitates choosing a right product, but also allows one to provide the customers with information that would be interesting for them. The new knowledge obtained from data exploration processes and presented as ontology on one hand describes concepts and relations, and on the other facilitates access to the important and useful information in the marketing database for a manager [START_REF] Pawełoszek | From Data Exploration to Semantic Model of Customer, submitted to[END_REF].

Information on the place of the customer's residence is currently not enough for product promotion purposes. The company should know also who the customer is, what his or her characteristics are, what is valuable, what is attractive, and what is completely uninteresting or even annoying. For example, to target the advertising to young people, it is better to prepare a marketing campaign on the Internet, but the internet advertising may not be so effective in the case of a product targeted to older people, who usually are not familiar with computers.

Marketing applications increasingly often use customers' psychographic profiles [START_REF] Vyncke | Lifestyle segmentation: From attitudes, interests and opinions, to values, aesthetic styles, life visions and media preferences[END_REF][START_REF]Values, Lifestyles, and Psychographics[END_REF], developed on the basis of information which is continuously collected during interactions between the company and its customers. The companies seek to register every possible communication record of the customer (phone calls, logging into the system, loyalty cards, using mobile applications, payments, history of transactions, etc.). Determining the customer's needs in advance, and an individual approach to each of them, is becoming the aim of marketing activities of large organizations.

The structure of this paper is as follows. In section 2, the problem of customer profile discovery is defined. In the next section, the sources of data necessary to build classification and prediction models are presented, with particular emphasis on clustering algorithms and classification trees. The last section presents the case study of data exploration methods along with semantic models and their role in developing the customers' profiles in the context of promotion of payment cards.

The Problem of Developing the Customer's Profile

Many approaches to building a marketing strategy are described in the literature [START_REF] Linoff | Data Mining Techniques: for Marketing, Sales, and Customer Relationship Management[END_REF][START_REF] Poh | Neural networks for the analysis and forecasting of advertising and promotion impact[END_REF][START_REF] Armstrong | Forecasting for Marketing[END_REF][START_REF] Chattopadhyay | Application of Artificial Neural Network in Market Segmentation: A review on recent trends[END_REF][START_REF] Yao | Forecasting and Analysis of Marketing Data using Neural Network[END_REF]. In this paper, in accordance with marketing theory literature, the creation of customers' profiles is emphasized as an essential tool of marketing strategy implementation [START_REF] Prymon | Marketingowe strategie wartości na rynkach globalnych, Wydawnictwo UE we Wrocławiu[END_REF].

The focus of the project was put on discovery of the bank customer's profile with the aim of identifying potential recipients of dedicated payment cards. Generally the main source of information in the research on a customer's profile is the history of transactions on the customer's bank account. Usually, historical data is complemented by personal information (such as: age, gender, place of residence, number of children) which has undeniable influence on the consumer's preferences and thus may constitute a good base for the customer's classification and for choosing a suitable payment card. This information, its scope and quality, has a significant impact on the predictive quality of the developed model.

Well-targeted promotion is a key determinant of the effectiveness and efficiency of a marketing campaign. The initial choice of a product, made on the basis of information about consumers' preferences, can reduce the time of marketing phone calls, and ensure the right choice of communication channels to reach the potential customers. It reduces ineffective contacts with customers who might not be interested in a particular offer. Finally, better communication influences the effective utilization of resources, which should decrease the costs of promotion.

On the payment cards market there are a large number of products dedicated to various groups of customers, for example: students, people who travel often, seniors, young parents, etc. To make these considerations more precise, let us assume that the bank is going to propose payment cards to its customers, corresponding to the following customer segments:

─ "Travelers" a dedicated credit card for frequent travelers, offering all kind of additional discounts on airline tickets, accommodation, hotels, insurance. ─ "Eternal students"-a credit card dedicated to the so-called "eternal students", offering extra discounts on concerts and events. ─ "Still young"a credit card dedicated for seniors, offering discounts for coffee bars, additional health insurance, free medical exams. ─ "High heels"a credit card dedicated to women, offering additional discounts to shoe stores and clothing. ─ "Business card"a card dedicated to business people, offering additional discounts for elegant clothing stores or tickets in Business Class.

The five segments have been briefly characterized by marketing analysts on the basis of their professional experience. Therefore the goal of the project was to improve the scope and specification of segments using data mining methods.

The specificity of the offered cards has decisive influence on the selection of data for analysis. For example, the "Travelers" card should be interesting to young or middle-aged people who are financially well-off. Their transaction history is dominated by multiple expenditures for touristic purposes, such as tickets, travel agency services, expenditures and mobile top-ups made from abroad. The target group for "Eternal students" cards should be addressed to young people, not having children (their profiles are characterized by i.a. low expenditures on articles for children). Considering the discounts for various events offered, this card can be proposed to people whose transaction history reveals a party lifestyle. The "Still young" card should be offered to older people who have significant expenditures on healthcare services. The "High heels" card should be interesting mainly for middle aged women. Important information for choosing this type of card will be whether the customer has children and therefore increased expenditures on children's articles and healthcare services. The potential customers for the "Business card" are middle-aged people, settled down and having substantial income.

Description of Data

In the project, the data about customers was extracted from transaction-oriented systems and mobile banking applications. The experimental data file contains 200 000 anonymized records of customers, describing their personal data, bank products at their disposal, incomes, expenditures and financial transactions The data underwent statistical analysis and initial transformation. More detailed information about the data can be found in [START_REF] Pawełoszek | From Data Exploration to Semantic Model of Customer, submitted to[END_REF].

Taking into consideration the selected algorithms of data exploration, the data were converted to numerical values, including continuous, discrete or binary types. The attributes of very low variances and redundant ones were eliminated. In the case of missing values, the descriptions were completed using the nearest neighbor algorithm [20,[START_REF] Han | Data Mining: Concepts and Techniques[END_REF]. On the file prepared in such a way, the normalization was performed which was necessary for heterogeneous variables. As a result of the initial transformations and features reduction, the set of 200 000 observations with 24 variables of the interval [0,1] was given for the further phases of data exploration.

Process of Determining Customer Profile

The study assumes that the bank intends to expand its offer for customers of one of five dedicated payment cards. The promotion is intended to avoid the phenomenon of miss-selling, or incorrect identification of the targeted groups of customers.

Generally speaking, the primary idea of the solution was to divide the customer database into semantically interpretable clusters, and then to design a classifier which will permit accurate definition of the customer profiles. In the final task of exploration, the results is used to build the ontology of knowledge about the customers and its use in marketing decision making [START_REF] Linoff | Data Mining Techniques: for Marketing, Sales, and Customer Relationship Management[END_REF].

For clustering, four algorithms were chosen: k-means, SOM neural networks, hierarchical clustering, and supervised by the user [START_REF] Han | Data Mining: Concepts and Techniques[END_REF][START_REF] Aggarwal | Data Clustering: Algorithms and Applications[END_REF]. The obtained partitions by the first three algorithms were very similar. The results showed to some degree not only imperceptible clusters by traditional marketing methods, but also unnoticeable relationships between characteristics of customers and offered products.

Fig. 1. Diagram of the data mining process

Taking as a criterion for aggregation the distance between clusters and semantics of the data, five clusters corresponding to the five potential market segments were generated. Although it has been verified by specialists, this partition did not show clusters of good quality in the marketing sense. Carrying out further clustering algorithms using k-means clustering and hierarchical clustering showed the groups of customers more homogenous in terms of semantics, but still not satisfactory. Therefore, a new method of clustering was proposed to guide the marketing specialist.

Clustering with user engagement was founded on the preliminary elimination of irrelevant attributes related to the specificity of the clusters sought. This operation made it possible to determine subsets with the high possibility of finding clusters semantically interpretable. For example, one can limit the search space for the clusters associated with "High heels" segment by eliminating irrelevant attributes such as: number of transactions on fuel, travelling, healthcare, number of children and mobile top-ups. The most relevant attributes were: gender (woman), age (20 to 60 years old) and monthly income (higher than 1,500 PLN).

Within these constraints the data file containing 200 thousand instances was reduced to approx. 60 thousand clients, women who fulfilled these restrictions. Figure 1 shows a diagram of the process of the data mining platform using Orange 1 .

In order to interpret the obtained clusters, four classifiers were applied: inductive decision trees, Multi-Layer Perceptron, Naive Bayes and CN2 [20,[START_REF] Larose | Data Mining and Predictive Analytics[END_REF].

Comparing with the previous publication [START_REF] Pawełoszek | From Data Exploration to Semantic Model of Customer, submitted to[END_REF], in this paper the research was extended to all classes of customers.

During the analysis of the clusters, it turned out that women to whom "High Heels" can be addressed were dispersed into five clusters C1, C2, C3, C4 and C6. Of these five clusters, the marketing analysts were particularly interested in the clusters with the highest number of instances, C6 and C1, whose initial definitions were extracted from the decision tree (Fig. 2), namely: C1  C6: ((Gender true) and (Amount_Entertainment_Transactions <= [START_REF] Armstrong | Forecasting for Marketing[END_REF]951)

and ((CreditCard true) and (Village True)) or ((CreditCard false) and (Village false)))

In the process of rule validation, the analysts have rejected the condition concerning Amount_Entertainment_Transactions and turned it into the condition (Entertain-mentTransactions true), indicating women who have done at least one entertainment transaction, regardless of the amount.

Fig. 2. Fragment of a decision tree for clusters C1 and C6

Legend: The values refer to the nodes of the cluster ID, the degree of homogeneity of the cluster (in %), and the number of instances. The names of the attributes in the nodes have been shortened for visual reasons.

Finally, after all transformations the rules describing the considered classes -were the following:

 Class "High heels" if ((Gender women) and (EntertainmentTransactions true))

Note that the new class definition is different from the one specified in the suggested restrictions referred to age and income. The final definition of potential customers for a "High Heels" card was given in Fig. 4.  Class "Travellers" if ((AmountRailwayTrans>=1,000) or (AmountPetrolTrans>=1,000))

The class describes the people who travel a lot, thats why both amounts of railway and petrol transactions are high. The customers use both train and car transport.

The new sample of data marke das "Travellers" consists of 1,175 persons.  Class "Business Card" if (Age<=60 and MonthlyIncome>=7,000)

To choose the right potential customers for Business Cards we were searching for women and men with higher than average level of income -as per our assumption it is more than 7,000. Usually they are middle age and older persons but the assumption was made that maximum age is 60 years old. New sample of data is marked as "Business Cards" class and it consists of 500 customers. This class is the smallest one, average income is 10,209;  Class "Eternal students"-if (Age<=40 and AmountOfTransEntertainment>=1,000)

People who could be interested in the offer "Eternal Students" are young people who spent more than 1,000 PLN on entertainment transactions. The number of items in this class is 3,762.  Class "Still young"if (Age>=55 and AmountOfTransHealth>=1,000)

The class describes older people who spend significant amounts on health transactions. The number of customers who could be interested in this kind of payment card is 1,071.

After the completion of the data exploration, the construction of the customer ontology started by using the Protégé platform2 . The schema of part of the ontology is shown in Fig. 3. Classes were a priori posed as the groups of customers interested in specific payment cards, indicated in the previous section. Rules and discriminant attributes of the decision tree designated the characteristics of the concepts in the ontology, through the so-called Data Properties, and made it possible to define the customer groups (Fig. 4).

Fig. 3. Diagram of the ontology of customer market segmentation

The ontology so created containing knowledge of the marketing profiles of customers was used not only for information retrieval from the database, but also in the classification of new customers of the bank in connection with the specificity of the products offered.

Using the Semantic Model of Customer

The example shows the utility of ontologies in making marketing decisions related to the preparation of the offer for the bank's customers with the explanation of why a particular card should be offered. It was assumed that the manager does not have complete knowledge of business informatics, and, therefore, that she or he does not know SQL programming nor database schema, nor complex functionalities of the data mining platforms. Protégé has been used to define the semantic model in our case study. The financial data was provided in a format of the Microsoft Excel spreadsheet. To enable ontology content collection the Cellfie plugin3 was used. The Cellfie desktop editor was used to map and to annotate the data in the spreadsheet (columns and rows) to attributes within the financial ontology. The discovered by the data mining algorithms class descriptions were transformed into the set of design patterns. Using knowledge about design patterns improves the database consistency and reduces the amount of time required to validate the data.

The analyst uses only the graphical interface of Protégé, which allows him to consult the ontology of knowledge about customers of the bank (partially shown in Fig. 3), and facilitates access to the marketing database. Fig. 4 shows the example of a class description of potential customers for the "High heels" card. This diagram illustrates on the left the classes of customer cards, and on the right the definition in the form of logical expression describing this class, and at the bottom a list of customers which meet these requirements. Based on this definition, the manager can not only search the database of all customers who meet the class constraints, but also strengthen or weaken the conditions of the class description. It should be noted that these operations do not require the manager's expertise on database structure and language to formulate queries.

Generally, the data mining methods make it possible to retrieve different clusters or groups of customers and their marketing interpretation. The interpretation, written in the form of formal expressions in Protégé, enables the manager to access detailed information about the customers, about groups of customers, dependencies, all axioms of marketing knowledge. Concepts, as well as the relationships between them can be easily changed and updated as a result of acquiring new knowledge, new data or new manager experiences. The paper has presented an analysis of the marketing database containing personal data as well as transactional and financial information. It was shown how one can construct customer profiles through the use of data mining methods. For this purpose, a number of algorithms for clustering and classification were applied. Note that the database schemas are usually designed for efficient data storage, but do not provide a semantic description to facilitate understanding of the data, interpretation, and reasoning. Therefore, the results of data mining were used to construct ontology which describes customer profiles

The use of ontology with an easy to learn visual interface of the Protégé platform allows managers to learn more about the information contained in the databases; it provides clear definitions related to the attribute names in the database. In addition, the proposed ontology contains the pre-defined classes that automatically make it possible to extract the customers' data which conform to particular customer profiles. For large data sets (in this case 200,000 instances), data mining methods supported by the ontology significantly simplified data analysis process. The developed solution can be easily customized to suit the analyst's needs -for example, when one needs to offer a new product, or to define a new class of customer profiles. To extract customer data for a specific marketing campaign, it is enough to enter the profile name (e.g., High heels) to get a list of persons who meet certain criteria.

An important direction for further research is therefore to improve the application interface by way of facilitating and monitoring the data mining process with special emphasis on the needs and skills of business analysts.

Fig. 4 .

 4 Fig. 4. Definition and instances of the "High heels" class

Orange is an open source data visualization and data analysis package for data mining applications, developed by Bioinformatics Labs at University of Ljubljana, Slovenia (http://orange.biolab.si)[START_REF] Demsar | Orange: Data Mining Toolbox in Python[END_REF].

Protégé is a ontology development platform supported by grant GM10331601 from the National Institute of General Medical Sciences of the United States National Institutes of Health. (http://www-med.stanford.edu)

Cellfie is a Protégé Desktop plugin for mapping spreadsheets to OWL ontologies available at https://github.com/protegeproject/cellfie-plugin

Acknowledgments. The authors would like to thank the staff of the VSoft company, Krakow, for providing the Pathfinder package, data, and documentations. The research was carried out as part of project No.POIG.01.04.00-12-106/12 -"Developing an innovative integrated platform for the financial area", referred to as the Project, cofinanced by the European Regional Development Fund and the Innovative Economy Operational Programme 2007-2013. Special thanks to Ghislain Atemezing of Mondeca, Paris, for his helpful suggestions concerning the usage of Cellfie plugin and comments on draft of this paper.


Michael Hitz
email: michael.hitz@dhbw-stuttgart.de

Thomas Kessel
email: thomas.kessel@dhbw-stuttgart.de

Using Application Ontologies for the Automatic Generation of User Interfaces for Dialog-Based Applications

The paper presents a data-centric, model driven approach for the automatic generation of user interfaces (UIs) for dialog-based applications using ontological descriptions. It focuses on Interview Applications, a common pattern e.g. for self-service applications in EIS. Existing approaches for the automatic UI generation usually rely on proprietary, UI-specific description models, designed and developed manually for the application in focus. The manual creation of the artefacts leads to a gap in the automated development, i.e for dialog-based application UIs, where the structure and behavior is driven by the processed data. Furthermore, the UI specific nature of the artefacts impedes their (re-)use in different contexts. The presented approach is a shift away from a UI-specific towards a data-centric method of modelling dialog-based applications, bridging this gap. Application-Ontologies are used as description means, which leads to reusable, sharable model artifacts, applicable to different contexts of use.

Introduction

The ongoing digitalization of business processes in Enterprise Information Systems (EIS) raised the need for exposing different variants of User Interfaces (UI) to let different user groups interact with the systems in different contexts of use and supporting different platforms (e.g. as a desktop, mobile and web application for customers or insurance brokers).

A commonly observed pattern in sales related dialog-based applications is to collect data needed for the execution of a business process in a directed dialog in form of an interview (a.k.a form filling or directed dialog [START_REF] Chlebek | User Interface-orientierte Softwarearchitektur[END_REF]). Examples for these Interview Applications can be found i.e. on the internet or web based business portals: e.g. the booking of a flight, the money transfer in a banking portal or the request of a quote for an insurance product. The application type is characterized by a high degree of standardization and clearly defined interaction concepts (mostly motivated by company style guides or platform standards). Thus the UIs for this application type are well suited for automatic generation.

Although there exist quite a lot of approaches for the model driven generation of UIs (see Related Work), they are not widely used in practice [START_REF] Meixner | Past, Present, and Future of Model-Based User Interface Development[END_REF]. Mostly they rely on manually modelling UI specific artefacts (e.g. concrete UI descriptions, taskflowand related data models), which are closely coupled and thus complex to create and maintain. In addition, the UI specific nature and proprietary descriptions impedes their reuse in different contexts [START_REF] Coutaz | User interface plasticity: model driven engineering to the limit! In[END_REF]. Furthermore, the manual development of the artefacts leads to a clear break and a gap in the automated application development -especially for data-driven applications as the aforementioned Interview Applications, where the structure and behavior of the UI is closely related to the data.

The objectives of this paper are to present an approach, that (1) bridges this gap by pushing the description from proprietary UI-specific information towards a datacentric model for applications and (2) to use common non-proprietary descriptions (i.e. RDF/OWL Ontologies) as modelling means.

The approach is based on the thesis, that structure and behavior of UIs for Interview Applications rely on the characteristics and semantics of the processed data. Thus UIs could be derived from data descriptions that contain the relevant semantic information. The proposed solution uses a single, declarative model of the processed data, which is augmented by additional semantical information used to infer all necessary information required to derive UIs.

The mayor benefits of this approach are to get (1) a single, UI agnostic artefact related to the processed data that allows an improved automation for application variant development and (2) a non-proprietary, shareable application description, applicable to different contexts of use.

The proposed approach in this paper contributes to the field of model driven development of user interfaces for dialog based applications. It adds concepts for the use of semantic knowledge about the processed data, its representation as ontology and its use to derive UIs

The paper is organized as follows: first the basic idea of a data-centric description, the character of Interview Applications and the information required to automatically generate user interfaces are elaborated. Then the representation of the information by means of ontologies and its concepts is presented followed by an outline of the derivation process for the UIs. Finally, evaluation of the concept and related work is presented, followed by a conclusion.

Data-centric Description of Interview Applications

The basic assumption of the data-centric approach is, that manually developed UIs for Interview Applications are built on the characteristics and semantics of the data processed by the application. Application developers use this knowledge to build suitable frontends for the data -e.g. a reasonable selection, grouping and sequence of input elements, the showing/hiding of sections or the navigation between pages [START_REF] Coutaz | User interface plasticity: model driven engineering to the limit! In[END_REF]. The knowledge is used implicitly by the developer and based on his experience or other rules, that are tacit knowledge. The basic idea is to incorporate this semantical knowledge into a data-centric model along with the processed application data.

The following sections illustrate the character of Interview Applications and show which information is needed to derive a UI.

2.1

Character of Interview Applications

Interview Applications collect related data in a meaningful sequential flow of questions in a dialog with the user. Depending on already entered information the flow might change and, if applicable, further questions are asked or omitted when necessary.

The following example illustrates the data-driven character of Interview Applications. It contains most characteristics that need to be modeled in a data-centric description, listed in the next section.

Example: quote for a liability insurance. The computation of a quote for a liability insurance is chosen as a sample use case. Such calculators are a very common application type in the insurance domain and incorporate multiple interaction patterns common for Interview Applications.

Fig. 1 shows an example of a graphical UI as used by an agent. The agent enters successively data that is needed for computing a quote. In Fig. 1a) subsequent questions are asked concerning the customer (e.g. name and marital status). On the left side there is a hierarchical navigation that allows random switching between various question groups (e.g. customer and contract data).

The data input elements are chosen based on type related properties (e.g. the basic type, value ranges, restrictions etc.). They are ordered in a semantically meaningful manner (e.g. name information before marital status) and have a hierarchical relation to each other (e.g. on the left hand navigation of Fig. 1a) contact information is shown as part of customer data).

The processed data elements are semantically interrelated. This reaches from related content (e.g. the zip code is related to a certain city) to existential relations, e.g. the date of marriage and partner data only exist if the marital status is set to married (Fig. 1a the city according to a given zip code or explicitly initiated user actions (e.g. opening a customer database to prefill customer data, Fig. 1a,❸).

Information Needs for Automatic Generation of UIs

In previous work (cf. [START_REF] Hitz | mimesis : Ein datenzentrierter Ansatz zur Modellierung von Varianten für Interview-Anwendungen[END_REF], [START_REF] Hitz | Interner Projektbericht zu mimesis[END_REF]) we derived a set of interaction patterns and extracted information, that is needed to build UIs that behave as in the example above. This was done by analyzing existing 'real-life' applications used in a major insurance company and match the findings to existing work within the field of UI generation (e.g. [4][20]).

The analysis leads to a set of information, needed to automatically derive UIs using these patterns. The information can be grouped into two categories (cf. Table 1).

Type related and Structural Information (I 1 -I 4 ):

This information is needed to describe the data elements (i.e. types and type restrictions like ranges or allowed values), their structure (i.e. grouping and hierarchical correlation) and a meaningful temporal succession of the questions within the interview [START_REF] Constantine | Software for use: a practical guide to the models and methods of usage-centered design[END_REF], which is based on the semantical cohesion.

Behavioral Information (I 5 -I 7 ):

This is needed to model the dynamic, data-related aspects of the UI for examination at runtime; i.e. conditions about the existence/activation of elements/groups bound to the content of other data elements within the model, the indication for complex validation, operations associated with data elements and groups triggered on changes of the input data (reactions) or triggered by the user (actions) [15][20]. This set of information was found adequate to derive different aspects of the UI following the interaction patterns in focus. Table 1 summarizes the usage of the information within a derivation process which will be detailed in section 4. Based on the findings, a meta model was developed that incorporates the identified information and served as a foundation to develop data descriptions for Interview Applications. Fig. 2 shows this meta model as UML diagram.

A data description (DataDescription) consists of a succession of data groups (DataGroup) that might contain an ordered list of further groups or data elements (DataItem). This constellation allows to model the requested structural information regarding cohesion, (hierarchical) grouping and temporal succession (order) of the elements (I 2, I 3, I 4 ). Groups and data items are detailed by attributes/facets. E.g. the type information (I 1 ) and existential and activation conditions (I 5 ) can be specified for each description element in the model. Further facets are used to specify the element more precisely in terms of data related aspects i.e. type restrictions that are usually part of a type system like XML-Schema (I 1 ). Table 2 summarizes the semantics of the facets for DataGroups and DataItems. Additionally, each description element might have associated validation-, reaction-and action operations (I 6 , I 7 ) . These are detailed by further facets (cf. Figure 2) like a name for the operation, triggering events and references to model elements needed for the execution of the operation (input/output parameters) [START_REF] Hitz | mimesis : Ein datenzentrierter Ansatz zur Modellierung von Varianten für Interview-Anwendungen[END_REF]. Elements are referenced by an identifier in dotted notation, pointing out their position in the model hierarchy to be retrieved at runtime (cf. section 4, step3). The resulting model addresses the first objective of this paper stated in section 1: an approach describing Interview Applications based on their processed data, augmented by data related information, that can be used to derive UIs. To achieve the second goal -using sharable and common means for the description -we apply this model to RDF/OWL as a common language in the field of semantic web technologies.

Using Ontologies as Application Description

The objective is to describe the mapping of the information requirements (I 1-I 7 ) listed in section 2.2. towards RDF/OWL and hence develop an application ontology. RDF/OWL [START_REF] Hitzler | OWL 2 Web Ontology Language Primer[END_REF] and its basic features are selected as a well understood, widely adapted technology used in different contexts for which tooling is available (e.g. reasoners, APIs). Table 3 summarizes the RDF/OWL features and concepts that are used to model the identified information requirements (I 1-I 7 ).

Table 3. Mapping of information needs to RDF/OWL features

Ontologies in general are intended to describe entities, relationships, contained data elements and additional facts in a way that inferences are built upon that knowledge. Hence the mapping of most of the structural information as identified in section 2.2 to RDF/OWL is a straight forward task.

To illustrate the mapping, Listing 1 shows a simplified application ontology for the customer data example in section 1.1 1 : DataGroups are modeled as owl:Classes within an ontology and their hierarchical relations as owl:ObjectProperties (e.g. customerdata as an object property of a Liability with range Customerdata). The Classes section declares the DataGroups (e.g. Customerdata, Contractdata and Fullname) as part of the application ontology (i.e. an ontology for a liability insurance <http://…/liability/v1#>). DataItems are defined likewise as owl:DatatypeProperties, containing information to which class they belong to, along with basic type information (e.g. Listing 1, exemplary data associated with an Address). Using these basic concepts, the structural information of I 2 and I 4 and partially I 1 are covered. However not all of the identified information needed for UI generation can be expressed out-of-the-box. Ontologies are made for knowledge representation and therefore RDF/OWL does not contain information like sequence of data (I 3 ), existential conditions (I 5 ) or functional aspects (I 6, I 7 ) in its basic language. To the best of our knowledge, RDF/OWL does neither include a concept for the description of operations nor for declaratively modelling conditions/references on instance data. To express the information needed, we use the OWL annotation concept as used by [START_REF] Khushraj | Ontological approach to generating personalized user interfaces for web services[END_REF][7] to produce a profiled ontology. This allows to incorporate the information declaratively and leads to an application ontology, that is (1) still covered by basic RDF/OWL (and thus can be used for standard reasoning) yet (2) exposes the additional information for reasoners (e.g. UI generators) that do understand the profile.

Listing 1. Excerpt of the resulting RDF/OWL model in Turtle notation

Table 4 lists the used annotations within the proposed profile along with their mapping to the information needs. As an example, Listing 1 shows annotations for type, sequence, validation and reactions applied to elements of the sample ontology.

The proposed mapping onto RDF/OWL constructs addresses the second objective of this paper stated in section 1: it leads to an ontological description for Interview Applications. Hence it incorporates all the information contained in the meta model in section 2.2, UIs may be derived based on such an ontology (cf. section 4 and 5). Hence it uses a common language and describes the processed data for an application, @prefix : <http://mimesis/insurance/liability/v1#> . @prefix mdt: <http://mimesis /datatypes#>. @prefix owl: <http://www. it can be used in different contexts and is not limited to UI generation. An example for a non-UI use will be given in the evaluation section. Nevertheless, the approach has limitations regarding its universality. The consequence of a profiled ontology using proprietary annotations is, there has to be a reasoner that is aware of the profile. The contained information is not interpretable to general reasoners and thus it is not shared as 'world knowledge'. The proposed solution is consciously limited to hierarchical ontologies. This is not a restriction for Interview Applications as they operate on hierarchical data structures by definition. But this characteristic prevents the approach to be applied to arbitrary ontologies that might have a reticular graph structure. Sahar et al. [START_REF] Sahar | ActiveRaUL : Automatically generated Web Interfaces for creating RDF data[END_REF] address this problem in the context of UI generation. The results found there may be used to extend the applicability of the proposed approach in future work.

Derivation Process for UIs

As outlined in Table 1 (section 2.2), the information contained in the proposed model is used for the automatic derivation of UIs. Fig. 3 outlines the derivation process. The basic approach is based on the concepts of the CAMELEON framework as proposed by Calvary [START_REF] Calvary | The CAMELEON Reference Framework[END_REF]. The starting point for the UI derivation process is an instance of the data-centric application model (data-centric core model). It contains the description of the processed data of the application according to the structure and properties presented in section 2.2.

Step 1: the core model is transformed into an abstract UI (AUI) using information about the context of use to concretize the information contained in the data-centric model. This step is crucial to generate usable UIs from a solely data-centric model that intentionally omits technical details. This phase includes the enrichment with labels, explaining texts and help information (depending on the language context), the mapping of data types to concrete types of the AUI (e.g. the mapping of the custom type zip to a text field restricted to 5 digits, if the language context is German) and abstract UI input elements. For instance, a number range control for a numerical value (I 3 )

:type Typeinformation for a group or element.

(I 1 )

:<constraint> typerelated constraints -> XMLSchema , e.g. :restrictedTo, :initialValue, :max, :min

(I 1 )
behavioral information

:existIf

Conditional expression

References data within the hierarchy using path expressions at runtime for an instance.

(

:activeIf

Conditional expression

References data within the hierarchy using path expressions at runtime for an instance. having min /max restrictions or a oneOfManySelection control for elements restricted to a set of possible values. The information needed here is derived from I 1, I 2, I 3 and I 4 .

Step 2: derives a concrete UI (CUI) from the AUI description by incorporating the device context for which the UI is intended. It includes the mapping of fields onto pages (pagination) by using information about device restrictions (e.g. for mobile devices) and exploiting the cohesion information contained in the data-centric model. The latter indicates how a flow of questions may be split up and positioned on pages for different device categories. The information needed here is derived from I 2 and I 4 .

Step 3: Depending on the technological context a final UI is derived by generating concrete UI Widgets for the AUI controls. Besides, an access mechanism to user entered data at runtime needs to be supplied, allowing the implementation of the functional aspects, e.g. a model for evaluation of visibility in Model-View-Controller application. The information for the functional aspects is derived from I 1, I 5, I 6 and I 7 .

Demonstration and Evaluation

The following sections focus on the validation of the stated objectives to show that (1) a data-centric approach may lead to an increased automation and is suitable for generating UIs for Interview Applications, (2) ontologies can be used within the approach to describe application UIs in a non-proprietary way that are (3) shareable and thus applicable for different contexts of use.

Our research on the topic of data-centric application descriptions is conducted using the Design Science Research (DSR) [START_REF] Peffers | The Design Science Research Process: A Model for Producing and Presenting Information Systems Research[END_REF] and Action Design [START_REF] Sein | Action Design Research[END_REF] approach. The resulting artefacts (i.e. data-centric meta model, derivation process and ontological description) are refined in several iterations and evaluated per iteration by implementation and technical experiments with prototypes -which is a commonly applied technique for evaluation of algorithms and models [START_REF] Peffers | Design Science Research Evaluation[END_REF].

The evaluation of the approach was conducted in association with a major German insurance company (Allianz Deutschland AG) from which we drew the data for the evaluation. The insurance company provided a set of typical 'real-life' Interview Applications that were used for the analysis phase and the validation of the implementation. From this set, relevant applications were selected that cover the interaction patterns identified during analysis and to demonstrate the usefulness of the automated process and afterwards the ontology developed in this paper.

To allow a deeper investigation, an online-link2 is provided that lists sample resources for the liability quote application used throughout this paper. It shows a working example of application variants and the complete application models mentioned below.

Evaluation of the viability of the data-centric approach (1)

First, the derivation process outlined in section 4 was implemented resulting in a Transformation Service (exposed as RESTful webservice), which transforms a datacentric application description to a final UI for different platforms. The implementation was based on available components from previous work done by Hitz [8]. The implementation focused on web-based Interview Applications covering HTML/JavaScript UIs for different device categories (mobile, desktop). In addition, another prototype for rich client UIs using JavaFX was established recently. Fig. 4 shows the basic setting for the implementation. The aforementioned selected applications were described as a first step by using a DSL (domain specific language) as proposed in [START_REF] Hitz | mimesis : Ein datenzentrierter Ansatz zur Modellierung von Varianten für Interview-Anwendungen[END_REF] (Fig. 4, upper left), which contains a model following the proposed meta model (cf. section 2.2). These models were imported into the data-centric core model and used by the transformation service to produce final UIs for different platforms as outlined in section 4.

Results: The implementation of the transformation process and its application to existing Interview Applications showed that the information outlined in section 2.2 is appropriate to derive non-trivial UIs for the identified interaction patterns in practice. The functionality of the generated UIs corresponds to a large extent to the already existing manually designed counterparts which served as a basis for the analysis. It could be demonstrated, that a single artefact is sufficient to model Interview Applications and that the data-centric approach leads to a high degree of automation for generating different variants for the applications (e.g. different technologies, navigation, input styles). However, limitations could be observed in situations, where the outlined model did not contain enough semantical information for a selection of sophisticated widgets for the generation of the final UI. For example, the use of a selection panel using buttons instead of a dropdown box depends on the character of the question (like 'product component selection'). This issue was solved by extending the model with additional properties like semantical tags for an element.

The results of this implementation are already used in production environments of Allianz Deutschland AG, e.g. to dynamically generate the UIs of complex electronic risk acceptance check applications for different products on customer and agent portals.

Applicability of Ontologies (2)

To evaluate the applicability of the approach to ontologies, a comparative evaluation was chosen based on the implementation of the first step (Fig. 4). The goal was to demonstrate that the proposed ontology has the same expressive power as the DSL used in the first step and thus produces the same output. To achieve this, the same applications were modeled using the proposed ontology (cf. section 3) and an import module was implemented, that mapped the ontology contents to the core model of the transformation service (Fig. 4, lower left). This was used to generate final UIs, which were compared to the ones generated in the first step.

Results: The results clearly show that both kinds of description can be mapped to the same core model and bear the same expressive power. The implementation showed, that the proposed approach for using ontologies to describe Interview Applications leads to the same results as the solution using the proprietary DSL used in [START_REF] Hitz | mimesis : Ein datenzentrierter Ansatz zur Modellierung von Varianten für Interview-Anwendungen[END_REF]. Though it is no formal proof, the result clearly indicates that the data-centric approach may be applied to ontological descriptions of Interview Applications.

Ontology Based, Shareable and Reusable Application Descriptions (3)

For the suitability of the proposed ontology as shareable, reusable application descriptions, we applied the approach to a concept for distributed marketspaces working with generic UIs for the specification of complex products. This work is already published in [START_REF] Hitz | Generic UIs for requesting complex products within Distributed Market Spaces in the Internet of Everything[END_REF] and thus summarized here. The objective was to show, that application ontologies as proposed above can be (1) shared and used to generically build composed UIs and (2) can be used for non-UI-specific purposes -in this case to deduce a complex product request from the user input, that is an instance of the applications data model represented by the ontology.

For this purpose, a demonstrator was implemented that used the aforementioned results. Fig. 5a shows the basic architecture of the demonstrator. As generic user frontend a Complex Product Builder (CPB) application was implemented, that let the user search and select Application Ontologies (AO) as proposed in this paper (Fig. 5a,❶). These are drawn from a shared UI description repository containing arbitrary UIOs for different product components (e.g. the booking of a concert or flight). The user selected AOs for his demand are sent to the Transformation Service (Fig. 5,❷), which returns the generated UI partials for each AO. These are aggregated into a UI presented to the user (Fig. 5b). Since the UI partials are generated from the elements contained in the AO, the user input clearly relates to the corresponding ontology elements. This allows to build an instance model for each presented AO containing the input data of the user using an Ontology Mapper (Fig. 5,❸). The result is a set of ontology instances on which a reasoner can build inferences and derive a complex product request, which can be sent to the Distributed Market Space for further processing (i.e. generating a quote/proposal for the requested product components).

Results: Although the demonstrator is yet still a proof-of-concept, it already showed, that it is possible to share application descriptions and thus provide generic UIs based on Application Ontologies. AOs can be assembled from arbitrary sources (e.g. topicrelated repositories for insurance, travel planning etc.). The UIs can automatically be derived and aggregated based on the contained information. As a second result the demonstrator showed, that these ontological descriptions can be used for non-UIspecific purposes like reasoning on instances of the AOs and thus further processing in backend systems that do understand the used ontologies.

Related Work

The research on the automatic generation of UIs covers many contributions during the last years that are based on model-driven concepts. There are several approaches focusing on different aspects of UI generation.

User Interface Description Languages (UIDL) focus mainly on the description of concrete UIs in a technology independent way. Examples are JavaFX 3 , UIML [START_REF] Abrams | UIML: An appliance-independent XML user interface language[END_REF], UsiXML [START_REF] Limbourg | USIXML: A User Interface Description Language Supporting Multiple Levels of Independence[END_REF] and XForms 4 . The essential idea is to model dialogs and forms by using technology independent descriptions of in-/output controls and relations between elements and behavior (e.g. visibility) within a concrete UI.

Task-/conversation based approaches describe applications by dialog flows which are derived from task models -e.g. CAP3 [START_REF] Van Den Bergh | CAP3: Context-Sensitive Abstract User Interface Specification[END_REF], MARIA [START_REF] Paterno | Maria: A Universal, Declarative, Multiple Abstraction-Level Language for Service-Oriented Applications in Ubiquitous Environment[END_REF] and conversation based [START_REF] Popp | Automatic generation of the behavior of a user interface from a high-level discourse model[END_REF]. They focus on a concrete model of the dialog flows and their variants. To generate an application frontend, the steps in a dialog flow are associated with technology independent UI descriptions displayed to the user.

Data-centric approaches can be found in JANUS [START_REF] Balzert | The JANUS Application Development Environment-Generating More than the User Interface[END_REF] and Mecano [START_REF] Puerta | Beyond data models for automated user interface generation[END_REF] which use a domain model as starting point for the derivation of UIs. While JANUS is designed to provide CRUD-like interfaces that work on a persisted domain model that does not support much dynamics in the UI, Mecano adds these aspects to its description.

Existing Ontology based approaches generally rely on the concepts of the mentioned approaches and use ontologies to represent the information about concrete UIs. For instance, in analogy of UIDL approaches, Liu et al. [START_REF] Liu | Deriving user interface from ontologies: A model-based approach[END_REF] propose an ontology driven framework to describe UIs based on concepts stored in a knowledge base. Khushraj et al. [START_REF] Khushraj | Ontological approach to generating personalized user interfaces for web services[END_REF] uses web service descriptions to derive UI descriptions based on a UI ontology, adding UI related information to the concept descriptions (profile). In analogy with task based approaches, Gaulke et al. [START_REF] Gaulke | Using profiled ontologies to leverage model driven user interface generation[END_REF] use a profiled domain model enriched with UI related data to describe a UI and associate it with an ontology driven task model. ActiveRaUL [START_REF] Sahar | ActiveRaUL : Automatically generated Web Interfaces for creating RDF data[END_REF] combines an UIDL with a data-centric approach and makes a significant contribution to the generation of UIs based on arbitrary ontologies. They derive a hierarchical presentation of an ontology and map it to an ontological UI description. Since there is not much semantic information contained, the resulting UIs are yet very simple and not very feature rich regarding the supported interactions.

Dissociation: A main goal of the proposed data-centric approach is to minimize the number of needed artefacts and to use a representation that can be reused for different purposes. The models of the aforementioned approaches usually do not contain enough semantical information for reasoning that could be used for deriving UI variants. The UIs are manually modeled using a large amount of artefacts. This opens a gap in automating the process for building UIs. In addition, the produced artefacts are usually proprietary and UI-specific. That impedes their reuse for other purposes related to application generation.

The solution proposed in this paper is based on the application's processed data and enriches its model by additional semantics. This leads to a single, central description for the application that serves as a knowledge base for the automatic derivation of UI variants. The data-centric approach allows the reuse of the model in different contexts and -by using a non-proprietary representation for the model -the sharing and integration into different environments. Though this approach is restricted to interview applications, it allows a significantly simplified modelling process, since the results can be derived from a single source.

Conclusion

In this paper a data-centric, model driven approach for the automatic generation of user interfaces for dialog based Interview Applications is presented. The approach is based on a UI-agnostic, data-centric description for applications. The foundation is a model of the processed application data which is enhanced by type-related, structural and behavioral information to yield automatically generated UI variants as demonstrated in the previous sections. The information needs are identified and a meta-model is derived from which the UIs can be inferred. Furthermore, the information needs are mapped to an ontological description relying on RDF/OWL constructs to get a non-proprietary representation of that information to be used in different contexts. A process to derive UIs from such a data-centric model is outlined. Finally, the evaluation is presented which (1) provides an implementation of the generation process for UIs from data-centric application descriptions, is used as proof-of-concept regarding the (2) usefulness of the ontological descriptions for UI generation and (3) its viability as sharable, non-proprietary means for generating UIs for data-driven applications.

The results of the evaluation indicate, that using a data-centric model is feasible for UI generation in case of Interview Applications. Since the number of artefacts is reduced to a single, UI-agnostic application model, the step for declaring UIs manually can be eliminated. Because of its data-centric nature, it can be used for non-UI-specific tasks. Using a universal representation as RDF/OWL adds even more value, as the application model is sharable and the contained semantics can be exploited by standard tools for reasoning on the model and instances.

The approach is intentionally restricted to dialog based Interview Applications that are very important and frequently used in EIS, e.g. in the insurance domain. Since a limited set of applications was used for the analysis, we cannot claim completeness of the identified interaction patterns. The practical use of the approach will bring forth additional interaction patterns extending the basic information set in future. Regarding the proposed use of ontologies, the evaluation strongly indicates the usefulness for UI derivation -though it is restricted to hierarchical structures and uses proprietary annotations and thus restricting its universality. Future work might concentrate on finding more general ways for incorporating the information and exploit existing approaches to apply the approach to arbitrary ontologies.

  Fig.1shows an example of a graphical UI as used by an agent. The agent enters successively data that is needed for computing a quote. In Fig.1a) subsequent questions are asked concerning the customer (e.g. name and marital status). On the left side there is a hierarchical navigation that allows random switching between various question groups (e.g. customer and contract data).The data input elements are chosen based on type related properties (e.g. the basic type, value ranges, restrictions etc.). They are ordered in a semantically meaningful manner (e.g. name information before marital status) and have a hierarchical relation to each other (e.g. on the left hand navigation of Fig.1a) contact information is shown as part of customer data).The processed data elements are semantically interrelated. This reaches from related content (e.g. the zip code is related to a certain city) to existential relations, e.g. the date of marriage and partner data only exist if the marital status is set to married (Fig.1a, ❶❷). Additionally, dialogs show dynamical behavior: input is validated and field content might need adjustment as a reaction to changes in other fields (e.g. prefilling

Figure 1 :

 1 Figure 1: UI for calculating a quote

  of the element in the flow of questions.

(I 5 )

 5

Figure 3 :

 3 Figure 3: Derivation process for UI variants

Figure 4 :

 4 Figure 4: Basic setting for evaluation

3 I

 3 . Fedortsova et al, 2014 : http://docs.oracle.com/javase/8/javafx/fxml-tutorial/preface.html 4 M. Dubinko et al, 2003: http://www.w3.org/TR/xforms a) Basic Architecture (modified from [10]) b) sample UI for a travel booking request

Figure 5 :

 5 Figure 5: Generic UIs for complex product requests

Table 1 .

 1 Information needs for a datamodel and its use to derive UIs.

type related & structural information (I1) type information for a data element or group

	ref	information need	usage for UI derivation
			selection of suitable input control based on type and specified
		(e.g. based on XMLSchema)	restrictions (e.g. presets and value ranges); providing type-related
			validations
	(I2) hierarchical grouping of elements	grouping of questions into display units; dependencies and
			hierarchical inclusion of groups; derivation of suitable navigation
			structures (sequential, tree, ...).
	(I3)

temporal succession of data-or group elements within the flow of questions

		display order of groups and input controls
	(I4) semantic cohesion of elements	arrangement of controls (e.g. proximity of a zip code and city);
		identification of possible breakpoints for pagination

behavioral information (I5) existence and activation conditions for data and group elements

		show/hide or de-/activate groups and questions, triggered on
		change of already entered data.
	(I6) validation operations	trigger (complex) validations operations usually related to already
		entered data
	(I7) actions and reactions	trigger operations on change of already entered data (reaction) or
		initiated by the user (action).

Table 2 :

 2 Facets for DataGroups and DataItems

	Facet	Description	contents
			boolean
			expression.
			Referencing model
			items.

DescriptionElement name* unique name as identifier for the element [a-zA-Z0-9]+ type type of the group or data item s. below existsIf Condition for the existance of the group or element. if it evaluates to true, the data is relevant and presented boolean expression. Referencing model items. activeIf Condition for the editability of the group or element. if it evaluates to true, the data is editable , else just displayed. DataGroup type type of the group cardinality possible cardinality of the group. Defines, how often the group might be repeated. (e.g.used to express, that a person might have multiple addresses) *: no limit <n>: fixed value <n>..<m>: range DataItem type type of the data item simple datatypes: semantics according XML-Schema custom datatypes e.g. domian or context specific. implies additional behavior (e.g. country specific validation for a zip code). simple datatype: text, number, boolean, date, float custom datatype: email, zipcode, phone, licenseplate + restrictions additional type specific constraints XMLSchema (e.g. min/maxInclusive) additional facets for datatypes restrictedTo restriction of possible vaules Value ranges, e.g. dog|cat|mouse + multiple allows multiple values to be selected true, false required idndicates that the data is not optional true, false initialValue initial value of the content Depending on type and restrictions

Figure 2: Metamodel in UML notation

  w3.org/2002/07/owl#>. ... @base <http://mimesis /insurance/liability/v1> .

		#### Data properties
		:Address.building_no rdf:type owl:DatatypeProperty...;
		rdfs:domain :Address ;
		rdfs:range mdt:buildingNo ;
		:Address.city rdf:type owl:DatatypeProperty .. ;
		rdfs:domain :Address ;
		rdfs:range mdt:text ;
		:Address.country rdf:type owl:DatatypeProperty...;
		rdfs:domain :Address ;
	...
	#### Object Properties:
	:Liability.customerdata rdf:type owl:ObjectProperty... ;
	rdfs:domain :Liability ;
	rdfs:range :Customerdata ;
	:Liability.contractdata rdf:type owl:ObjectProperty ... ;
	rdfs:domain :Liability ;
	rdfs:range :Contractdata ;
	:Customerdata.address rdf:type owl:ObjectProperty... ;	Examples for Annotations
	rdfs:domain :Customerdata ;	# sequence and additional type information
	rdfs:range :Address ;	:Maritalinformation.status rdf:type ... ;
	:Customerdata.fullname rdf:type owl:ObjectProperty ... ;	ma:initialValue "married" ;
	rdfs:domain :Customerdata ;	ma:restrictedTo "married|notmarried|divorced" ;
	rdfs:range :Fullname ;	ma:sequence "1" .
	:Customerdata.maritalinformation rdf:type	# existance
	owl:ObjectProperty , ... ;	:Customerdata.partnerinformation rdf:type ... ;
	rdfs:domain :Customerdata ;	ma:existsIf "(liability.customerdata
	rdfs:range :Maritalinformation;	.maritalinformation.status == 'married')".
	:Customerdata.partnerinformation rdf:type	# validations, reactions, actions
	owl:ObjectProperty;	:Address.city rdf:type owl:DatatypeProperty ;
	rdfs:domain :Customerdata ;	ma:sequence "4" ;
	rdfs:range :Partnerinformation ;

#### Classes : :Liability rdf:type owl:Class . :Customerdata rdf:type owl:Class . :Fullname rdf:type owl:Class . :Maritalinformation rdf:type owl:Class . :Address rdf:type owl:Class . :Partnerinformation rdf:type owl:Class . :Contractdata rdf:type owl:Class . rdfs:range mdt:country ; :Address.eMail rdf:type owl:DatatypeProperty... ; rdfs:domain :Address ; rdfs:range mdt:eMail ; :Address.street rdf:type owl:DatatypeProperty... ; rdfs:domain :Address ; rdfs:range mdt:text ; :Address.zip rdf:type owl:DatatypeProperty... ; rdfs:domain :Address ; rdfs:range mdt:zip ; ma:validations "change:validators.validateCity( liability.customerdata.address.zip)" .

Table 4 .

 4 Elements of the annotation profile

Link to website with additional content: https://doi.org/10.13140/RG.2.2.16564.24963