Alberto Bartoli

Andrea De Lorenzo

Eric Medvet

Fabiano Tarlao

Your Paper has been Accepted, Rejected, or whatever: Automatic Generation of Scientific Paper Reviews

Peer review is widely viewed as an essential step for ensuring scientific quality of a work and is a cornerstone of scholarly publishing. On the other hand, the actors involved in the publishing process are often driven by incentives which may, and increasingly do, undermine the quality of published work, especially in the presence of unethical conduits. In this work we investigate the feasibility of a tool capable of generating fake reviews for a given scientific paper automatically. While a tool of this kind cannot possibly deceive any rigorous editorial procedure, it could nevertheless find a role in several questionable scenarios and magnify the scale of scholarly frauds.

A key feature of our tool is that it is built upon a small knowledge base, which is very important in our context due to the difficulty of finding large amounts of scientific reviews. We experimentally assessed our method 16 human subjects. We presented to these subjects a mix of genuine and machine generated reviews and we measured the ability of our proposal to actually deceive subjects judgment. The results highlight the ability of our method to produce reviews that often look credible and may subvert the decision.

Introduction

Peer review, i.e., the process of subjecting a work to the scrutiny of experts in order to determine whether the work deserves publication, is a keystone in scholarly publishing. The review process should ensure that a published paper is of high scientific quality, which in its turn preserves the reputation of the corresponding publishing venue and improves the prestige of its author. On the other hand, peer review is just a piece of broader process involving several entities whose incentives may or may not actually drive the overall process toward those ideal goals. Authors are increasingly subject to strong pressures in the form of research evaluation procedures in which the indicators that play a key role are often mostly numerical [START_REF] Bartoli | Bibliometric evaluation of researchers in the internet age[END_REF]. Reviewers tend to be overworked and often receive little credit for their hard work [START_REF] Csiszar | Peer review: Troubled from the start[END_REF], while at the same time being interested in increasing some counter of program committees or editorial boards in which they are involved. Commercial publishers may find in scholarly publishing excellent opportunities for profit [START_REF]HEFC: Identification and dissemination of lessons learned by institutions participating in the research excellence framework (ref) bibliometrics pilot[END_REF], even in the form of journals with little or no scrutiny: a periodically updated list of predatory publishers has grown by 50 times in the last 5 years, including 923 publishers in its latest release [START_REF] Beall | List of predatory publishers[END_REF].

While there is no doubt that most published research follows a rigorous and honest path, it is evident that actors involved in research may now find ways to maximize their personal benefits disregarding the ideal objective of the scientific environment as a whole, by following practices that are questionable or simply fraudulent [START_REF] Bowman | Predatory publishing, questionable peer review, and fraudulent conferences[END_REF][START_REF] Dadkhah | Affiliation oriented journals: Don't worry about peer review if you have good affiliation[END_REF]. Unfortunately, this claim is not a mere theoretical possibility. Questionable operators have emerged that run bogus journals and conferences which have no other purpose than generating profit while uttering worthless scientific literature [START_REF] Butler | The dark side of publishing[END_REF]. Supposedly peer-reviewed journals accept for publication papers that have been randomly generated [START_REF] Eldredge | Mathgen paper accepted! Technical report[END_REF] or publish papers which clearly have not been proof-read by anyone [START_REF] Oremus | This is what happens when no one proofreads an academic paper[END_REF]. Misbehaving researchers attempt to inflate their records by ghostwriting papers on nonexistent research [START_REF] Qiu | News publish or perish in china[END_REF]. Not surprisingly, the critical reviewing step has been exploited as well. Computer intrusions on the editorial system of a major commercial publisher have forced the publisher to retract several published papers [START_REF] Reller | Faking peer reviews[END_REF]. In the last few years, hundreds of published papers have been retracted by several commercial publishers in many independent events [START_REF] Fischman | Fake peer reviews, the latest form of scientific fraud, fool journals[END_REF][START_REF] Ferguson | Publishing: The peer-review scam[END_REF][START_REF] Callaway | Faked peer reviews prompt 64 retractions[END_REF], due to the discovery of reviews fabricated by the authors themselves which provided journals with suggested reviewers along with fake contact information which actually routed communication to the authors or their colleagues.

In this work, we investigate the feasibility of more fraud opportunities in the form of a procedure for automatic generation of fake reviews. We propose a method for generating automatically text which (a) looks like the typical scientific paper review, (b) is tailored to the specific paper being reviewed, and (c) conveys a recommendation specified as input. A tool that is capable of generating fake reviews systematically and at no cost may be misused in several ways. Busy people which want to be involved in as many reviewing committees as possible might choose a recommendation and then generate reviews very quickly, perhaps without even reading the paper or after just a superficial look. Predatory publishers might attempt to improve their credibility by sending many reviews to authors. Of course, reviews generated by our tool will certainly be detected as being fake by any decent editorial process. On the other hand, as pointed out above, perverse incentives and unethical conducts might find a role for a tool of this kind, which may potentially magnify the scale of frauds in the reviewing process in several ways. In this respect, it is important to keep in mind that a few years ago Springer and IEEE retracted more than 120 published papers which were computer-generated nonsense [START_REF] Noorden | Publishers withdraw more than 120 gibberish papers[END_REF]. Our proposed tool could find more constructive applications, though. For example, the steering committee of a conference could inject fake reviews in the discussion phase without informing the program committee and then observe the outcome.

Our proposed method constructs a review tailored to a specific paper, with a specified recommendation, based solely on the paper text and a corpus of reviews written by humans for other papers. A key aspect of our proposal is that it builds upon a relatively small knowledge base (some tens of reviews) while commonly used methods for text generation, such as Artificial Neural Networks (ANN), typically require a very large amount of data in order to build an effective generative model. Applying those methods in the context of scientific review generation is difficult because of the difficulty in finding a large amount of samples of scientific reviews, in particular, of negative reviews.

An important contribution of our work is the experimental campaign performed involving human subjects. We performed an intrinsic evaluation aimed at assessing the ability of our method to generate reviews which look like as being written by a real human reviewer. Moreover, we performed an extrinsic evaluation aimed at assessing the impact on the decision about accepting or rejecting a paper under review. Although our experimental campaign is not a replica of a real editorial process and thus may provide only a preliminary assessment, our results do provide interesting insights.

Related work

To the best of our knowledge, no method for the automatic generation of reviews of scientific papers has been proposed before. From a broader point of view, our proposal is a form of Natural Language Generation (NLG), which is widely used in many different fields such as spoken dialogue systems [START_REF] Wen | Semantically conditioned lstm-based natural language generation for spoken dialogue systems[END_REF], machine translation [START_REF] Sutskever | Sequence to sequence learning with neural networks[END_REF], and as a mean for creating editorial content by turning structured data into prose [START_REF] Wright | Algorithmic authors[END_REF].

A notable use of NLG for scientific purpose, which is particularly relevant to our work, is the software SCIgen1 . This tool generates pdf files consisting of syntactically correct random text which is formatted like a scientific publication, including randomly generated figures, plots, and code fragments. Later and independently from its creators, SCIgen has been used in order to test the submissions standard of conferences and to prove that nonsense papers may actually be published, even by respected publishers [START_REF] Noorden | Publishers withdraw more than 120 gibberish papers[END_REF]. This phenomenon has been investigated also in [START_REF] Labbé | Duplicate and fake publications in the scientific literature: how many scigen papers in computer science?[END_REF], which studies the spread of fakes and duplicates through notable publishers. The fact that a tool which was born as a "toy" for Computer Science researchers led to actual malicious behaviors suggests that other types of cheating may arise, including the creation of false reviews: this consideration is indeed the main motivation of our work.

Our work proposes a corpus-based NLG method. Corpus-based methods aim at training text generation rules automatically from text examples of the desired text generator output. An example of corpus-based method applied to text generation in dialogue is the work in [START_REF] Oh | Stochastic natural language generation for spoken dialog systems[END_REF]. The cited work proposes a class-based n-gram language model (LM) that improves over template-based and rule-based text generation systems. Belz [START_REF] Belz | Automatic generation of weather forecast texts using comprehensive probabilistic generation-space models[END_REF] proposes a corpus-based probabilistic generation methodology and apply it to the automatic generation of weather forecast texts. The work in [START_REF] Rieser | Natural language generation as planning under uncertainty for spoken dialogue systems[END_REF] assesses a new model for NLG in dialogue systems by maximizing the expected reward using reinforcement learning.

A different approach to NLG is based on Artificial Neural Networks (ANN). Kukich [START_REF] Kukich | Where do phrases come from: Some preliminary experiments in connectionist phrase generation[END_REF] implemented a stock reporter system where text generation is done at phrase level using an ANN-based approach. A recent work demonstrated the effectiveness of Recurrent Neural Networks (RNN) for natural language generation at character level [START_REF] Mikolov | Recurrent neural network based language model[END_REF]. A variant of RNN, Long Short-Term Memory (LSTM) [START_REF] Hochreiter | Long short-term memory[END_REF], proved its ability to generate characters sequences with long-range structure [START_REF] Graves | Generating sequences with recurrent neural networks[END_REF]. The authors of [START_REF] Potash | Ghostwriter: Using an lstm for automatic rap lyric generation[END_REF] showed the ability of a LSTM framework to automatically generate rap lyrics tailored to the style of a given rapper. Zhang and Lapta [START_REF] Zhang | Chinese poetry generation with recurrent neural networks[END_REF] proposed an RNN-based work for generating Chinese poetry.

Beyond unbounded text generation, LSTM for NLG has also been used in the generation of image descriptions [START_REF] Karpathy | Deep visual-semantic alignments for generating image descriptions[END_REF][START_REF] Mao | Deep captioning with multimodal recurrent neural networks (m-rnn)[END_REF][START_REF] Vinyals | Show and tell: A neural image caption generator[END_REF] and in the generation of descriptive captions for video sequences [START_REF] Venugopalan | Translating videos to natural language using deep recurrent neural networks[END_REF].

All the generative methods based on neural networks require a huge amount of learning data, usually orders of magnitude more than the amount of data that we could find in our scenario (i.e., scientific reviews). Methods for data augmentation capable of decreasing the amount of learning data required for training a neural network effectively certainly deserve investigation in our context [START_REF] Chatfield | Return of the devil in the details: Delving deep into convolutional nets[END_REF].

Our approach

The problem consists in generating, given a paper a and an overall recommendation o ∈ {accept, neutral, reject}, a review r which (i) appears as generated by a human (ii) for the paper a and (iii) which expresses a recommendation o for a. In our work, we assume that the paper a is a plain text which consists of the concatenation of the paper title, abstract and main content.

Our method requires a set R of real paper reviews, i.e., each review r ∈ R has been written by humans. We pre-process each review in R as follows: (i) we split the document in a sequence {t 1 , t 2 , . . . } of tokens according to the Penn-Treebank procedure; (ii) we execute a Named-entity Recognition (NER) 2 [34] on the token sequence; and (iii) we execute a Part-of-Speech (POS) annotation3 [START_REF] Toutanova | Feature-rich part-of-speech tagging with a cyclic dependency network[END_REF] on the token sequence; finally (iv) we classify each token in {t 1 , t 2 , . . . } as being or not being a specific term, according to an heuristic procedure (see below).

When generating a review for a paper a with a specified recommendation o, our method performs 3 steps, described below in full detail: (i) it builds a set S of sentences from reviews in R and replaces each specific term in each sentence with a specific term of a; (ii) it removes from S the sentences which express a sentiment which is not consistent with o; (iii) it reorders and concatenates the sentences in S obtaining a review for a. Specific terms identification. With this procedure, we aim at identify the specific terms of a document d-i.e., those terms which are relevant to d. To this end, we defined a simple heuristic. Let {t 1 , t 2 , . . . } the sequence of tokens for d, where each token has been annotated with NER and POS taggers. A token t ∈ {t 1 , t 2 , . . . } is a specific term if it meets all the following criteria: (i) t has been annotated as a noun (NN) or as an adjective (JJ); (ii) the length in characters of t is at least 2; (iii) t contains at least one letter. Specific terms replacement. In this step, we aim at constructing a set S of review sentences tailored to a. To this end, we proceed as follows, starting with S = ∅. For each review r ∈ R, we split the review in a set S r of sentences. We obtain (according to the procedure described above) the set W a of specific terms of a, retrieve the set W r of specific terms of r, and set W a = W a \ W r and W r = W r \ W a . Then, for each sentence s r ∈ S r , we generate a random mapping from items in the set W s r of specific terms of W r which occur in s r to items in W a such that: (a) each item in W s r is mapped to exactly one item in W a , (b) no items in W s r exist such that they are mapped to the same item in W a , and (c) for each item w s r mapped to an item w a , the POS and NER annotations of w s r are the same of respective annotations of w a . If such mapping is possible, we replace each occurrence of a term of W s r in s r with the mapped term in W a and add the modified sentence to S; otherwise, we proceed to the next sentence.

In other words, after this procedure, S contains all the suitable sentences generated by iterating the term replacement procedure for all the reviews in R.

Sentiment analysis. In this step, we aim at selecting the sentences of S which express a sentiment consistent with the specified overall recommendation o. To this end, we apply a pre-trained Naive Bayes sentiment classifier 4 [36] to each sentence s ∈ S, basing on the assumption that a positive sentiment can be associated with an accept recommendation, a negative sentiment with a reject recommendation, and a neutral sentiment with a neutral recommendation.

After the application of the sentiment classifier, we retain in S only the sentences for which the outcome is consistent with o.

Sentences reordering. In this step, we aim at generating the final output of our method (the automatically generated review) by selecting, reordering, and concatenating a subset of sentences of S. The rationale for the selection and reordering is to obtain a review (a) whose length is realistic, w.r.t. a typical review, and (b) which has an overall structure which resembles a typical reviewe.g., an opening sentence, some considerations, a conclusive remark.

Concerning the reordering, we based on the assumption that sentences may be classified as suitable for opening part, central content, and closing part. Accordingly, we built a classifier which takes as input a single sentence and outputs a label in {opening, central, closing}. We took the general purpose text classifier based on maximum entropy5 described in [START_REF] Manning | Optimization, maxent models, and conditional estimation without magic[END_REF] and trained it using all the sentences of the reviews in R, which we automatically labeled as follows: if the sentence was the first sentence in its review, we associated it with the label opening; otherwise, if it was the last sentence, we associated it with closing; otherwise, we associated it with central.

When generating a review, we apply the classifier to each sentence in S and then randomly select 1 opening sentence, 3 central sentences, and 1 closing sentence. Finally, we concatenate those 5 sentences and obtain the review for a.

Experimental evaluation

We performed two experimental evaluations involving human subjects for assessing our proposed method ability to generate reviews which (a) look like as they have been written by real human reviewers for the specified paper, and (b) can affect the decision about accepting or rejecting the specified paper. That is, we performed an intrinsic evaluation and an extrinsic evaluation, respectively.

We built a dataset composed of 48 papers and 168 reviews, which we obtained from the F1000Research, Elifescience, Openreview and PeerJ web sites-which publish reviews of accepted papers along with corresponding full texts-and from our lab publication records; we used the reviews of the dataset as the set R while running our method. Moreover, for the purpose of performing our evaluations, we associated an overall recommendation (i.e., a label in {accept, neutral, reject} with each review in the dataset. Since the sources we considered vary in the way, if any, they classify reviews according to overall recommendation, we proceeded as follows. If a review was explicitly associated with an overall recommendation by its author, we associated it with the suitable label-e.g., positive recommendations to accept, negative recommendations to reject, and all the other recommendations to neutral. Otherwise, if a review was not explicitly associated with an overall recommendation, we considered the outcome of the publishing process which, for published papers, was always acceptance.

In order to provide a comparison baseline for our review generation method, we designed and built a simple baseline generation method based on Markov chains. To this end, we trained a second order Markov chain, operating on tokens, on all the reviews in the dataset: before the training, we added a special token t end at the end of each review. When generating a review with the baseline method, the specified paper a and the overall recommendation o are not considered and the following steps are performed. First, a review in the dataset is randomly chosen and its first two tokens are fed into the Markov chain generative model. Then, the generative model is run until the token t end is obtained. Finally, the output is obtained by concatenating all the generated tokens.

In our experimentation, we involved a number of human subjects, who were asked to examine the generated reviews and then to answer some questions. In order to gain more insights about our method effectiveness, we grouped the subjects according to their presumed familiarity with scholarly publishing, resulting in 3 classes. The experienced class is composed of professors, PhD student, and postdocs; the intermediate class is composed of undergraduate students; the novice class is composed of all the remaining subjects (who were anyway sufficiently proficient with English).

Intrinsic evaluation

In the intrinsic evaluation, we built a number of forms, each showing the title of a paper a randomly chosen from our dataset and a set of 10 reviews randomly sampled for the following sets: (a) the real reviews in the dataset actually related to a, (b) the real reviews in the dataset not related to a, (c) a set of reviews generated using the baseline method, and (d) a set of reviews generated using our method with a and a random overall recommendation o as input. Since the size in characters of the real reviews can widely vary, we limited the number of sentences presented to the subject to 5, as for our generated reviews, randomly sampled from the corresponding reviews while maintaining the original ordering. We asked the subject to say, for each review in the form, if "it appeared as a genuine review written by a human reviewer for the paper with the shown title". We gathered results from 16 subjects-5 novice, 3 intermediate, and 8 experienced.

Figure 1 shows the key findings of the intrinsic evaluation: the figure plots the percentage of positive answers (on the y axis) to the form questions for each kind of review (bar group) and for each class of subjects (bar fill pattern). It can be seen that our method generates reviews that are considered as written by a human in almost one case on three-the figure being greater for novice subjects an smaller for experienced subjects. Moreover, the deceiving ability is larger than the baseline: approximately 30% vs. 10%. Concerning the real reviews, Figure 1 shows that, as expected, they are properly recognized ≈ 85% of the times: this finding suggests that the truncation of real reviews does not severely affect their appearance.

Baseline

Extrinsic evaluation

In the extrinsic evaluation, we built a number of forms, each showing the title of a paper a randomly chosen from our dataset and a set of 3 reviews randomly sampled for the sets described at points a, b, and d in the previous section. Real reviews were possibly limited in length as in the intrinsic evaluation. The form also showed, next to each review, the corresponding overall recommendation. We asked the subject to answer the following two questions: 1. "basing on these 3 reviews, would you recommend to accept or reject the paper?"; 2. "while taking your decision, in which order the 3 reviews influenced you?" We gathered results from 13 subjects-3 novice, 3 intermediate, and 7 experienced. Table 1 summarizes the key findings of the extrinsic evaluation. In the left portion the table shows, for each subject class and for all the subjects, the number of forms in which at least a real and a generated reviews were discordant w.r.t. the recommendation (Discordant column), the number of discordant forms for which the subject took a decision in line with the generated reviews (and hence against the real reviews, Subverted column), and the ratio among Subverted and Discordant. In the right portion it shows the number of forms, for each kind of reviews, in which a review of the corresponding type were stated to be the most influencing by the subject; moreover it shows the percentage of forms in which the generated reviews were stated to be the most influencing. The most interesting, and somewhat surprising, finding is that in the 25% of cases the decision of an experienced subject agreed with the generated reviews and disagreed with the real reviews: from another point of view, through a generated review we were able to manipulate the outcome of the (simulated) peer review process. Table 1 also shows that, in 26% of cases, a generated review was stated to be the most influencing by the subjects.

Conclusions

We proposed a method for the automatic generation of scientific reviews. The method is able to generate a review of a given research paper with a specified overall recommendation. To this end, it performs multiple steps aimed at generating reviews which resemble human written reviews and hence might potentially induce the reader to accept or reject the reviewed paper.

A key contribution of our work is the experimental evaluation, which involved 16 human subjects. The results show that in ≈ 30% of cases a generated review is considered genuine by the human subjects; moreover, in about 1 among 4 cases, we were able to manipulate the outcome of a (simulated) peer review process through generated reviews which we mixed with genuine reviews.

Beyond these promising results, our proposal needs further investigation and, in this respect, we plan to compare it with other NLG methods, such as ANN, for which, however, a much larger amount of data need to be collected. Finally, it could be interesting to investigate if and how an ontology can improve the review generation process.

Fig. 1 .

 1 Fig. 1. Percentage of reviews considered as written by a human for the specified paper.

Table 1 .

 1 Subject class Subverted Discordant % Our method Original Others % Results of the extrinsic evaluation (see text).

	Experienced	4	16	25.0	10	21	4 28.6
	Intermediate	4	15	26.7	11	18	14 25.6
	Novice	5	21	23.8	11	25	9 24.4
	Overall	13	52	25.0	32	64	27 26.0

http://pdos.csail.mit.edu/scigen/

http://nlp.stanford.edu/software/CRF-NER.shtml

http://nlp.stanford.edu/software/tagger.shtml

http://sentiment.vivekn.com

http://nlp.stanford.edu/software/classifier.shtml


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

Mirjana Radonjic-Simic
email: mirjana.radonjic-simic@dhbw-mannheim.de

Julian Reichwald
email: julian.reichwald@dhbw-mannheim.de

Dennis Pfisterer
email: pfisterer@itm.uni-luebeck.de

Generic UIs for requesting complex products within Distributed Market Spaces in the Internet of Everything

Keywords: Automatic User Interface Generation, Semantic Web, Internet of Everything, User Interface Ontologies, Commercial Exchange, Distributed Market Spaces, Complex Products

Distributed Market Spaces (DMS), refer to an exchange environment in emerging Internet of Everything, that supports users in making transactions of complex products; a novel type of products made up of different products and/or services that can be customized to better fit the individual context of the user. In order to express their demand for a particular complex product in a way that is interpretable by the DMS, users need flexible User Interfaces (UIs) that allow context-focused data collection related to the complexity of the user's demand. This paper proposes a concept for generic UIs that enables users to compose their own UIs for requesting complex products, by combining existing UI descriptions for different parts of the particular complex product, as well as to share and improve UI descriptions among other users within the markets.

Introduction

Emerging Internet of Everything (IoE) is opening up new opportunities for commercial exchange, giving the rise to novel types of products and services. Due to the increased interconnectivity of its participants (companies, institutions, individuals) on one hand and processes, data and things on the other [START_REF]Cisco: The internet of everything for cities[END_REF], the IoE is enabling exchange environments, where products and services are customized and compound, as they are made up of many components provided by different suppliers [START_REF] El Sawy | Business modelling in the dynamic digital space: An ecosystem approach[END_REF]. Furthermore, these products and services can be orchestrated in complex products (i.e., an arbitrary combinations of individual products and/or services) and customized in a way to consider the unique conditions determined by the user's context. As such, complex products can better fit the individual needs of the users, thus, create richer consumer experiences that have not been possible before.

Contemporary solutions for commercial exchange are mostly focused on availability of individual products and services within their domain boundaries, or certain pre-defined combination of them traditionally bought together, however, are limited in their ability to support complex products, which need to fulfill particular user-defined criteria, going beyond the existing product/service descriptions. Consider the simple use case of booking a flight, hotel, rental car and guided tour. While already feasible today, it is a complex task to solve in order to fulfill different constraints (e.g., place, time, price, personal preferences). It can get exceptionally complex if many auxiliary conditions or products are involved. To make informed decisions, users need to know where and how to find viable product and/or service offers i.e., to engage search engines, visit diverse online platforms, shops, etc. while confronting with plenty of different user interfaces, search/selection criteria and representations of product/service description. After finding viable offers, users must compare, aggregate and infer all relevant information, considering the particular user context. The complexity of above mentioned activities and related user involvement lead to the adverse selection [START_REF] Akerlof | The market for lemons: Quality uncertainty and the market mechanism[END_REF] i.e., choosing good enough, instead of optimal products/services, and increases the transaction costs (i.e., the buyers' costs to acquire information about seller prices and product offerings).

Distributed Market Spaces (DMS) proposed by [START_REF] Pfisterer | Business model design and architecture for the internet of everything[END_REF], refers to a IoE exchange environment that supports market participants (i.e., consumers and producers) in making (distributed) transactions for complex products. But, to build a complex product requests on their own, the users need an alternative to express their demand for a particular complex product, in a way, that is interpretable by the DMS. Therefore, flexible user interfaces are needed to allow data collection of an arbitrary combination of the products and/or services, fulfilling user-defined criteria and spanning over different product/service domains related to the complexity of the user's demand.

In this paper, we propose a concept for generic user interfaces (UIs) for requesting complex products within Distributed Market Spaces in the Internet of Everything -a concept that alleviates the effects of adverse selection by supporting the users crafting complex product requests in a seamless manner; a manner of enabling users to:

compose a new, customized UI for requesting a complex product in a particular user-defined context, by combining existing UI descriptions for different parts of the complex product, which can be rendered for different platforms / technical contexts (e.g., mobile or webbased apps) create a request for complex products interpretable by the DMS and share and improve UIs for complex products within markets. This paper is organized as follows: First, Section 2 describes the setting in which our proposed concept is applied and defines the main requirements. Next, Section 3 presents the architecture and functional structure of the proposed solution, followed by a demonstrator implementation in Section 4. Thereafter, Section 5 discusses on related work and Section 6 concludes the paper with a summary and outlook.

Motivation and Background

In the following, we briefly describe the setting, i.e., the context in which the proposed concept of generic UIs is applied. Afterwards, we define the overall objectives and consider these as the requirements for the demonstrator implementation, as shown later in Section 4.

The Application Context

Distributed Market Spaces (DMS) [START_REF] Pfisterer | Business model design and architecture for the internet of everything[END_REF], refers to a model of commercial exchange that supports market participants in making distributed transactions of complex products. Figure 1 illustrates the conceptual structure of the DMS, showing the involved parties, their roles and relationships on the left, and on the right, the DMS functional structure with its components and high-level interfaces, represented through the sets of exchanging messages, required to support the interactions along involved parties.

Market Space1

Market Spacen Market Space2

... As shown in Figure 1a, the DMS is used by peers, i.e., potential transaction partners defined by their intention; buyers are peers intending to buy complex products while sellers are peers intending to sell products and/or services. Peers connect to one or more independent market spaces (MS) and multiple of these market spaces form the Distributed Market Spaces (DMS). A peer may offer products and services on one or more market spaces (e.g., Peer 2 offers product P 1 and service S 2 ) as well as, request a complex product by sending the request to one or more market spaces (e.g., Peer 2 also requests the complex product CP 1 ).

The peer interface component (user application), as shown in Figure 1b, is split into two parts: a seller and a buyer side. In this paper, we focus on the user application buyer side, which is responsible to: transform a user's intention into a complex product request, distribute these requests to multiple market spaces, receive (partial) complex product offers and re-combine them into multiple complete complex product proposals, rank them according to the buyer's context and requirements, as well as to coordinate the distributed buying transaction. The user application is therefore comprised of the CPR Builder, Coordinator, the (De-) Composer and Ranking component.

The proposed concept of generic UIs is applied in the context of Complex Product Request Builder, CPR Builder component highlighted blue (Figure 1b).

Overall Objectives

The main task of the CPR Builder as a component of the user application, is to transform a user's intention into a complex product request, which can be distributed to one/multiple market spaces within the DMS.

For the generic UIs concept to be implemented in context of the CPR Builder, following two basic prerequisites need to be assumed. First, in order to be able to match the incoming requests with the available offerings, the market space needs to understand the semantics of the product/service offerings (i.e., 'supply semantics'). Second, it needs to understand the semantics of the different requests, provided by the user as a complex product request (i.e., 'demand semantics').

As to [START_REF] Pfisterer | Business model design and architecture for the internet of everything[END_REF], the DMS supports the 'supply semantics' using a domain-agnostic database, containing the information about registered sellers, as well as the description of available products and services they can potentially offer, encoded in RDF [START_REF]W3C: Resource description framework[END_REF].

The challenge at this point, is the possible gap between the product/service descriptions provided by the supply-side and the demand descriptions requested by the demand-side.That is, because the data to describe a complex request is usually different from the data contained in the product/service descriptions. For example, a product description usually contains a price tag for one unit -a demand usually contains a price range. A more complex example is the generalisation of the demand: a product description could be a specific offering for a Ticket for the musical 'Chicago' -a general demand for a concert could be 'all musicals and rock concerts' that somehow are related to 'Chicago'. Given that, it is not always possible to use the product/service description data as a blueprint for the demand requests. Therefore, the DMS uses dedicated demand descriptions, defining the demand in a way, that can be mapped to the descriptions of the offerings.

As the main purpose of the CPR Builder is to enable users to craft complex product requests in a seamless manner, the potential buyers should be able to combine different product/service requests into a single complex product request, hence to compose a specific UI variant that:

is tailored to their demand for a particular complex product -i.e., an arbitrary combination of products and/or services, e.g., a flight, hotel, rental car and tickets for the events at the destination,

supports the context-information defined by the user, i.e., user's preferences and criteria e.g., a ticket for a certain musical vs. more general proposal for events like theater, concert or ship cruise, and produces output in the form of a request for complex product interpretable by the DMS.

Composing a specific UI variant includes finding, selecting and combining existing UI descriptions for the different parts of the complex products, while considering the user's preferences in terms of the generalisation (e.g., concert vs. general event planning) or granularity (e.g., less questions vs. detailed specification depending on the user's context). Hence, we can detail this overall objective into following functional requirements: R 1 : Different UI descriptions for the same demand request supplying different questions based on the user's preference for more/less specific questions. R 2 : Different UI descriptions containing demands for multiple products to allow context-focussed interfaces. R 3 : Composition of different UI descriptions into a single UI description for the particular complex product request

Having outlined the main prerequisites and requirements, in following, we use them as the rationale for the conceptualisation of the overall solution.

Proposed Solution

As an explanation of the proposed solution, in this section, we first introduce the foundations and core elements, followed by the functional aspects and more detailed description of the inner workings.

Overview -Generic UIs for complex product requests

The proposed solution extends the DMS concept, outlined in Section 2.1, by enabling users to craft complex product requests. It uses the Complex Product Builder to combine individual UIs and generate complex product requests from the collected data. For the automatic generation of the involved UIs, the solution builds on the results of the mimesis project [START_REF] Hitz | mimesis : Ein datenzentrierter Ansatz zur Modellierung von Varianten für Interview-Anwendungen[END_REF] and extensions that map the approach to ontological descriptions [START_REF] Hitz | mimesis : A Data-Centric Approach for Generating User Interfaces for Interview Applications Using Ontologies[END_REF].

In the proposed solution of generic UIs, we use Semantic Web technologies as they provide the necessary mechanisms to get a rich description of the data involved and incorporate techniques for reasoning on that data. The foundation of the proposed solution is built on ontologies describing different views of the participants (demand-, DMS-and supply-side) and ontological descriptions for the UIs to meet the requirements R 1 ,R 2 and R 3 (cf. Section 2.2).

Figure 2 shows the core elements of the proposed solution. The central component is the Complex Product Builder, that orchestrates the generation of the UI. It allows the selection of UI descriptions, the generation of their concrete UIs, aggregation into a single UI (similar to 'mesh-up' approaches [START_REF] Pascalau | Mashups : Behavior in Context ( s )[END_REF], though using generated content) and building of a complex product request based on the data entered by the user. A Supply Ontology (SO) is used by the peers (seller side) to describe product instances on which market spaces within the DMS can operate. To describe the demand for a product/service, a Demand Ontology (DO) is used; it defines the possible request data to be specified by the peers (buyer side) and thus, can be interpreted by the market spaces. Finally, User Interface Description Ontologies (UIO) describe the UI variants based on the data to be collected. These are used to build the concrete UI and to generate output, that corresponds to the related demand ontologies.

The following Section 3.2, outlines the functional structure of the solution needed to fulfil defined requirements (R 1 , R 2 , R 3 ), followed by Section 3.3, that provides a detailed description of the ontologies, used in this solution -especially focussing the UIO and its mapping to the DO.

Functional View -Processing complex product demands

The workflow for building a complex product request starts with the buyer aggregating the UI for a specific complex product need. As shown in Figure 2 (Step 1), the buyer selects suitable, task related UI descriptions provided by a UI Description Repository -e.g., a search engine collecting UI descriptions for demands on the Internet, or a repository of community-rated UI descriptions (which usually were manually or semi-automatically crafted based on the related DOs). The result of this step, is a collection of user-selected, context-related UI descriptions to be presented to the user by the CPR Builder.

The collection of UI descriptions is sent to the generic UI Builder component, that generates the final UIs based on that descriptions and returns the results. The components are aggregated by the CPR Builder into a single UI and are presented to the user (Steps 2 and 3). When the user finished entering data, the data for each UI component is mapped to instances of the corresponding DO (Steps 4 and 5). The information on how the data elements relate to DO elements is part of the UIO (cf. Section 3.3). The resulting DO instances are aggregated into one complex product request, that is enriched with context data and thus, as shown in Step 6, ready for further processing.

Information View -Ontologies in detail

Supply Ontology (SO): The Supply Ontology is the common vocabulary to describe products/services provided by a seller. As in [START_REF] Pfisterer | Business model design and architecture for the internet of everything[END_REF], this enables a market space to process product/service data and clearly determines the data and semantics that can be used for a certain product/service instance description. A simple product instance is shown in Listing 1.1 as an example. It describes a ticket offer for the musical 'Chicago' at the 'Alte Oper Frankfurt' [START_REF] Pfisterer | Business model design and architecture for the internet of everything[END_REF] using existing ontologies GoodRelations4 and Ticket ontology5 . Listing 1.1: Exemplary description of a offering. related to the corresponding Supply Ontology. Listing 1.2 shows an example of a request following a DO for event tickets. It describes a demand for a ticket for a musical or rock concert with a name containing 'Chicago' (could be the musical or the band).

Although, the DO is related to a corresponding SO (here the Ticket Ontology), it extends the elements with request-related extensions (e.g., tiod:eventcategory; for a more general demand for event categories, or the use of gr:hasMaxCurrency-Value for specifying a maximum price for a ticket.

User Interface Description Ontologies (UIO): A set of User Interface

Description Ontologies is used to describe the possible UIs for the buyer side. A UIO describes the UI for a specific dialog variant by describing the data to be collected in sufficient detail. It contains all necessary information needed to (1) derive a User Interface and (2) to relate the collected data to a demand instance specified by Demand Ontologies.

For the description of UIs we apply the approach of the mimesis project introduced in [START_REF] Hitz | mimesis : Ein datenzentrierter Ansatz zur Modellierung von Varianten für Interview-Anwendungen[END_REF] and its application onto ontologies [START_REF] Hitz | mimesis : A Data-Centric Approach for Generating User Interfaces for Interview Applications Using Ontologies[END_REF]. The basic idea of the approach is to define a model of the data processed/collected by the application and derive UIs for different platforms and user contexts from this model. For this purpose, the basic data model is enriched with information needed to derive UIs: this includes structural information (e.g., type restrictions, grouping, sequence of elements) and behavioural information (e.g., visibility rules, reactions to the changes, validations to perform). The resulting model is data centric, technology agnostic and can be used to derive UIs for different kinds of platforms and contexts of use (e.g., mobile apps, web based-, rich client-or speech based UIs). Further details of the approach can be found in [START_REF] Hitz | mimesis : Ein datenzentrierter Ansatz zur Modellierung von Varianten für Interview-Anwendungen[END_REF].

The idea of the mimesis approach -to describe the semantics of the data in more detail -additionally allows to add information for each element on how it is to be mapped to elements defined within a DO. Using that information an instance (individual) of the UIO containing the user input can be used to generate a corresponding instance of the DO as resulting output.

The approach is suitable to meet the requirements R 1 , R 2 and R 3 listed in Section 2.2. To achieve that, ontological descriptions of the UI for different product demands are used. These contain:

a description of the data with UI specific enhancements, as defined in mimesis for the derivation of UIs (as proposed in [START_REF] Hitz | mimesis : A Data-Centric Approach for Generating User Interfaces for Interview Applications Using Ontologies[END_REF]) and the information for the mapping of that data onto DO instances, needed to produce the demand requests.

Hereby, different UI variants for a demand can be defined, that might contain different questions depending on the user's context (cf. R 1 ). Since the mapping information contained in the UI description can reference arbitrary ontologies, it is also possible to provide UIs containing questions spanning different DOs (cf. R 3 ). The approach is also capable to address requirement R 3 : the CPR Builder is able to choose a set of different as building blocks from which an aggregated UI can be presented to the user. Figure 3a shows a possible variant for a UI relating to the above example DO instance, in Listing 1.2. The UI for a concert demand contains two groups of questions (Details for title or genre and Price range). It illustrates, that the relation to the DO is not one-to-one. For example, the data are grouped differently and there is no currency selectable (which is already set by the CPR Builder from the user's context data). Additionally, there is a value restriction for concert category, which might be a subset of the possible values defined in the DO.

Figure 3b shows a structural graph of the UIO for the displayed UI. The UI consists of two groups (Pricerange and Concertdetails). These encompass the Listing 1.3: Basic User Interface Ontology for a concert demand (excerpt).

1 @prefix : <http://mimesis.solutions/products/concert#> .

2

@prefix owl: rdf: xsd: rdfs: 3 @prefix mdt: <http://mimesis.solutions/datatypes#>.

4

@prefix man: <http://mimesis.solutions/annotations#> 5 @base <http://mimesis.solutions/products/concert> . ... The additional information needed for the derivation of a concrete UI and for the mapping to the Demand Ontology is shown in Listing 1.4. As this is meta information, describing the element in more detail, mimesis uses the annotation concept of OWL to specify these details. For each element (data element or group) there exist mimesis-specific entries (e.g., the sequence of the questions in line 3, or specific type information and restrictions in line 4 and 5). The mapping onto instances for DO elements is provided using annotations starting with the prefix 'sw:'. It contains information to which class an entity belongs to (e.g., line 19 maps Concert.concertdata to a tiod:TicketRequest). It is defined to which property a data element maps, which type it has and to which individual it belongs to (e.g., line 6 -8 map Concertdetails.concertcategory to the type tiod:eventcategorylist and assigns it to the ticketrequest instance using the property name tiod:eventcategory ). Given that information a demand instance, following the DO as shown in Listing 1.2, can be generated in combination with the instance data gathered by the UI.

13 ########### Object Properties #########

Demonstrator

As a proof of the concept, we built a demonstrator that implements the proposed approach for aggregating the UIs for a complex product request and matching the collected data to a Demand Ontology. As a use case, we chose 'organising a city trip' which includes the planning of events, transportation and overnight stays. The buyer should be able to select the desired components for his trip, and enter the required demand information for each component. As the final Listing 1.4: Additional UI and DO related Data for a concert demand.

1 2 ########### Annotations ##########

28

:Concertdata.concertdetails man:sequence "1" .

29

... step of the demonstrator, the collected data for each component is shown as an instance of the related Demand Ontologies. The demonstrator implements the solution architecture outlined in Section 3.2 and shown in Figure 2. Its central component, the CPR Builder, is implemented as a web application using HTML/JavaScript as a platform technology, and uses a local repository for the management of available UI descriptions. Additionally, the UI Builder and Ontology Mapper components are implemented as separate Web Services, based on the work in [START_REF] Hitz | mimesis : A Data-Centric Approach for Generating User Interfaces for Interview Applications Using Ontologies[END_REF].

The UI Builder Service is responsible for generating the UIs based on the UI Description Ontologies; it accepts UIOs as input and is able to generate a final UI for different technology plattforms (here HTML/Javascript). The Ontology Mapper Service, on the other hand, is responsible for generating a DO instance, based on a certain UIO and corresponding user input submitted in the form of a JSON object.

The demonstrator follows the workflow outlined in section 3.2. First, the buyer searches for product components using a google-like search facility, and selects/collects the components according to his preferences and requirements as shown in Figure 2, Step 1. An example of such a search is shown in Figure 4a, where the user enters 'travel' into the search field, and gets available components matching the search critera (e.g., 'visit a concert' of 'rent a car'). The user selects viable components, which are collected like products in a shopping cart (Figure 4a). When the user finished the selection, the corresponding UIOs of the selected components are sent to the UI Builder Service that generates final UIs (Figure 2, Steps 2 and 3). These are aggregated by the client application into one UI and presented to the user for input. The aggregation of the UI based on the selected components is shown in Figure 4b. After having entered the demand data for each component, the CPR Builder sends the collected data along with the corresponding UIO to the Ontology Mapper Service, which is responsible for mapping the collected data to the DO according to the information contained in the UIO, and returns an instance of the DO (Figure 2, Steps 4 and 5). The results of this step are finally displayed by the demonstrator for each component as shown in Figure 4c. In a further step (not part of the demonstrator) these DO instances can be aggregated into one complex demand and processed by the CPR Builder, as described in Section 2.1.

Summarizing, the demonstrator shows that it is basically possible to dynamically generate UIs for complex products, satisfying the requirements defined in Section 2.2. Users can be enabled to choose the UIs they want/need and combine them to build requests for desired complex products. These UIs may span different domains and can be combined to build a unified interface for the users. Moreover, the demonstrator also underlines the advantage of using UIOs as separate descriptions; since a UIO contains all information to generate a UI, as well as the information about how to produce instance data (understandable by the market spaces), the UIOs are actually independent from the target system. Therefore, they can be independently distributed and modified -as long as the output conforms to the specified demand ontologies.

Yet, our demonstrator does not cover all functionality needed to combine different demands in a seamless manner; currently it combines UIs for product components as separate, self relying units -ignoring possible relations between them. For example, it does not implement a context, which components and their UIs may share and react to (e.g., recognizing and omitting questions, that were already asked in other components, or pre-fill values from a global context).

Related Work

In this section, we provide an overview of the operational solutions, concepts and approaches relevant to the presented work, and briefly discuss why these are not suitable to meet the defined requirements.

Electronic marketplaces (e-marketplaces), as well-established solutions for commercial exchange, enable only compositions of individual products/services within their domain boundaries, or they offer pre-defined combinations of them, which are traditionally bought together and determined by recommender systems. Even though there exist some advanced solutions, such as, e.g., [START_REF] García-Gómez | Challenges for the comprehensive management of cloud services in a paas framework[END_REF] enabling the composition of individual services considering a wider set of userdefined criteria, these are domain-specific solutions, and as such, are limited in their capabilities to support users requesting complex products spanning over different product/service domains related to the complexity of the user's demand.

The Intention Economy (IE) [START_REF] Searls | The intention economy: when customers take charge[END_REF], also called Project Vendor Relationship Management (VRM), refers to an exchange environment that focuses on a buyers' intention to conduct a transaction with potential sellers (i.e., vendors). By using VRM tools, buyers are supported to describe their needs by creating a personal request for proposal (pRFP) and make them visible for the vendors. Even though, the VRM tools support pRFP there is no obvious evidence that they support composing context-focussed UIs.

Web of Needs (WoN) [START_REF] Kleedorfer | The case for the web of needs[END_REF], refers to a framework for a distributed and decentralized e-marketplace on top of the Web. WoN aims to standardize the creation of owner proxies, which describe supply or demand, represent the intention to enter a transaction, as well as contain information of the owner needed for conducting the transaction [START_REF] Kleedorfer | Beyond data: Building a web of needs[END_REF]. Generally, WoN supports describing the user's need for complex products, but, if the user wants the system to process the complex product, he can publish a 'complex need', waiting for a matching service capable of interpreting his 'complex need'. Given that, the effects of adverse selection are still retained, and native support for requesting complex products remains insufficient.

Concluding, contemporary solutions of commercial exchange are limited in supporting users requesting complex products; approaches such as IE or WoN, address some of the requirements, but do not represent a comprehensive solution. Either they provide tools that need to be integrated with other solutions to be fully usable, or they address our requirements only partly.

Next, we elaborate on the approaches focusing on automatic generation of UIs and the different aspects of the UI generation that can be applied to our presented work.

User Interface Description Languages (UIDL) focus mainly on the description of concrete UIs in a technology independent way. Examples are JavaFX [START_REF] Fedortsova | JavaFX Mastering FXML[END_REF], UIML [START_REF] Abrams | UIML: An appliance-independent XML user interface language[END_REF], and XForms [START_REF] Dubinko | XForms 1.0 W3C Recommendation[END_REF]. The essential idea is to model dialogs and forms by declarative 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., MARIA [START_REF] Paterno | Maria: A Universal, Declarative, Multiple Abstraction-Level Language for Service-Oriented Applications in Ubiquitous Environment[END_REF] or model conversations, like in [START_REF] Popp | Automatic generation of the behavior of a user interface from a highlevel discourse model[END_REF], [START_REF] Raneburger | A Process for Facilitating Interaction Design through Automated GUI Generation[END_REF]. They focus on a 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.

Existing ontology based approaches generally rely on the concepts of the mentioned approaches and use ontologies to represent the information. 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] use web service descriptions to derive UI descriptions based on a UI ontology, adding UI related information to the concept descriptions. 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 which models the interaction. ActiveRaUL [START_REF] Sahar | ActiveRaUL : Automatically generated Web Interfaces for creating RDF data[END_REF] combines an UIDL with a data-centric approach and thus contributes to the generation of UIs for arbitrary ontologies. They derive a hierarchical presentation of an ontology and map it to an -yet simple -ontology based on the UI description.

In view of our requirements (cf. Section 2.2) it can be stated that the aforementioned approaches are restricted mainly to the definition of UIs and dialog flows. They do not contain concepts to associate (map) the collected data to results of arbitrary ontology instances that might have a different structure as in the UI. Additionally, they are restricted to the environments where a reasoner is available at runtime to infer the dynamic behavior of UIs based on already entered data (e.g., showing/hiding UI parts, as in [START_REF] Liu | Deriving user interface from ontologies: A model-based approach[END_REF]). This is a drawback for environments like web-based, single-page applications, where a reasoner is not available at runtime. Finally, UIs and task models are mostly modeled using a large amount of artifacts, thus, they can hardly be used to generate targetsystem independent variants that differ in content, depending on the context of use [START_REF] Coutaz | User interface plasticity: model driven engineering to the limit! In[END_REF].

Conclusion and Future Work

In this paper, we proposed a concept for generic UIs that enables users requesting complex products within DMS in the IoE. In order to express their demand for a particular complex product, in a way, that is interpretable by the DMS, users need flexible UIs that allow context-focused data collection related to the complexity of the user's demand.

In order to identify the overall objectives, which need to be supported by the generic UIs concept, we first looked at the prerequisites and objectives derived from the DMS as the application context. Afterwards, we operationalized these objectives into the requirements and used them as the rationale to conceptualize the overall solution as well as to elaborate on existing approaches and initiatives related to the presented work. Thereafter, and in the view of these requirements, we implemented an initial demonstration of the proposed generic UIs concept, using an exemplary use case.

As the demonstrator shows, it is basically possible to dynamically generate UIs for complex products where UIs may span different domains, and can be combined to build a unified interface for the users. It also underlines the advantage of using User Interface Ontologies as separate descriptions, so that they can be independently shared and modified. However, the presented demonstrator does not cover all functionality needed to combine different demands; currently it composes UIs for product/service components as separate, self-relying parts ignoring possible relations between them. Furthermore, it does not consider a wider user-related context that components and their UIs may share and react to.

In our future work, we will concentrate on these two areas of improvements, as well as, on the extensive prototypical implementation to conduct a sophisticated analysis of the strengths and weaknesses of the proposed concept.

Figure 1 :

 1 Figure 1: Conceptual structure of the DMS.

Figure 2 :

 2 Figure 2: Core elements of the solution architecture.

  (a) UI Variant for a concert demand. (b) Graph of the UIO.

Figure 3 :

 3 Figure 3: UI and its structure.

6

  <http://mimesis.solutions/products/concert> rdf:type owl:Ontology .

9 : 10 : 11 :

 91011 Concertdata rdf:type owl:Class . Concertdetails rdf:type owl:Class . Pricerange rdf:type owl:Class .

12

 12

  (a) Searching for suitable UIs. (b) Entering data in meshed-up UI.(c) Gathered data as Demand Ontology instance.

Figure 4 :

 4 Figure 4: Aggregating UI and entering data

1

  PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> The Demand Ontology is closely related to the Supply Ontology and defines the data that can be used to describe the demand for a certain product (e.g., concert ticket) or product category (e.g., ticketing in general). The DO describes the maximum of requestable information, thus, what the market space is able to understand and handle regarding the questions Listing 1.2: Example of a request for a ticket.

	@prefix gr: <http://purl.org/goodrelations/v1#>	3
	@prefix tio: <http://purl.org/tio/ns#>	4
	@prefix tido: <http://demandontologies.org/ticketdemands#>	5
	@base <http://mimesis.solutions/products/concert/individuals> .	6
		7
	### http://mimesis.solutions/products/concert/individuals# _ i1462530726859 : _ i1462530726859 rdf:type owl:NamedIndividual ; :concertdata :ticketrequest _ i1462530726859 .	8 9 10
		11
	### http://mimesis.solutions/products/concert/individuals#ticketrequest _ i1462530726859 :ticketrequest _ i1462530726859 rdf:type <tido:TicketRequest> ,	12 13
	owl:NamedIndividual ;	14
	gr:name "Chicago" ;	15
	tido:eventcategory "musical|rockconcert"^^<tido:eventcategorylist> ; gr:hasPriceSpecification :hasPriceSpecification _ i1462530726859 .	16 17
		18
	### http://mimesis.solutions/products/concert/individuals# hasPriceSpecification _ i1462530726859	19
		7
	dms:ticket1 a tio:TicketPlaceholder ;	8
	dms:PSO1 a gr:Offering ;	12
	gr:name "Ticket for Chicago Musical"@en ;	13
	gr:description "The #1 American Musical in Broadway History:Chicago at Alte Oper	14
	Frankfurt"@en ;

2

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> 3 PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> 4 PREFIX gr: <http://purl.org/goodrelations/v1#> 5 PREFIX tio: <http://purl.org/tio/ns#> 6 PREFIX dms: <http://www.itm.uni-luebeck.de/dms/#> 9 rdfs:label "Ticket for Chicago Musical at Alte Oper Frankfurt"@en ; 10 tio:accessTo <http://data.linkedevents.org/event/chicagomusical> . 11 dms:TRIO Tickets ltd. gr:offers dms:PSO1 . 15 gr:includes dms:ticket1 ; 16 gr:hasBusinessFunction gr:Sell ; 17 gr:hasPriceSpecification 18 [ a gr:UnitPriceSpecification ; 19 gr:hasCurrency "USD"@en ;

20 gr:hasCurrencyValue "49.50"^^xsd:float ; 21 gr:validThrough "2016-09-26T23:59:59"^^xsd:dateTime ] .

Demand Ontology (DO):

1 @prefix : <http://mimesis.solutions/products/concert/individuals#> . 2 @prefix ... owl: rdf: xml: xsd: rdfs: 20 :hasPriceSpecification _ i1462530726859 rdf:type <gr:UnitPriceSpecification> , 21 owl:NamedIndividual ; 22 gr:hasMaxCurrencyValue "35"^^<xsd:float> .

  #

	:Concertdata.concertdetails rdf:type owl:FunctionalProperty , owl:ObjectProperty ;	14
	rdfs:domain :Concertdata ; rdfs:range :Concertdetails .	15
	###########	Data properties	##########	19
	:Concertdetails.concertcategory rdf:type owl:DatatypeProperty , ... ;	20

16

:Concertdata.pricerange rdf:type owl:FunctionalProperty ,owl:ObjectProperty ; 17 rdfs:domain :Concertdata ; rdfs:range :Pricerange .

18 ...

21 rdfs:range mdt:manyOfMany ; rdfs:domain :Concertdetails . 22 :Concertdetails.name rdf:type owl:DatatypeProperty , owl:FunctionalProperty ; 23 rdfs:range xsd:text ; rdfs:domain :Concertdetails . 24 :Pricerange.maxprice rdf:type owl:DatatypeProperty , owl:FunctionalProperty ; 25 rdfs:domain :Pricerange ; rdfs:range xsd:integer . 26 ... data fields and their types (e.g., name and concertcategory) to be presented to the user. Listing 1.3 shows an excerpt of the UIO in OWL/Turtle notation [23].

  #

	:Concertdetails.concertcategory man:sequence "2" ;	3
	man:type "manyOfMany" ;	4
	man:restrictedTo>"musical|classical|rock|jazz|all" ;	5
	man:swForIndividual "ticketrequest" ;	6
	man:swProperty "tiod:eventcategory" ;	7
	man:swType "tiod:eventcategorylist" .	8
	man:swProperty "gr:name" ;	10
	man:swType "gr:name" ;	11
	man:swForIndividual "ticketrequest" .	12
	:Concertdata.pricerange man:sequence "2" ;	13
	man:swClass "gr:UnitPriceSpecification" ;	14
	man:swProperty "gr:hasPriceSpecification" ;	15
	man:swIndividual "hasPriceSpecification" ;	16
	man:swForIndividual "ticketrequest" .	17
	:Concert.concertdata man:sequence "0" ;	18
	man:swClass "TicketRequest" ;	19
	man:swIndividual "ticketrequest" .	20

9

:Concertdetails.name man:sequence "1" ; 21 :Pricerange.maxprice man:sequence "1" ; 22 man:initialValue "30" ; 23 man:unit "EUR" ; 24 man:swProperty "gr:hasMaxCurrencyValue" ; 25 man:swForIndividual "gr:hasPriceSpecification" ; 26 man:type "number" ; 27 man:swType "xmls:float" .

http://www.heppnetz.de/projects/goodrelations/

http://www.heppnetz.de/ontologies/tio/ns