D2.4 - Final Models and Validation

SmartSociety Hybrid and Diversity-Aware Collective Adaptive Systems When People Meet Machines to Build a Smarter Society

Grant Agreement No. 600584

Deliverable D2.4 Working Package WP2

Final Models and Validation Dissemination Level 1 (Confidentiality): Delivery Date in Annex I: Actual Delivery Date Status2 Total Number of pages: Keywords:

1

PU 31/1/2015 January 29, 2016 F 105 Provenance, Reputation, Accountability, Transparency, Scalability, Ride Share Application

PU: Public; RE: Restricted to Group; PP: Restricted to Programme; CO: Consortium Confidential as specified in the Grant Agreeement 2 F: Final; D: Draft; RD: Revised Draft

c SmartSociety Consortium 2013-2017

2 of 105

Deliverable D2.4

http://www.smart-society-project.eu

c SmartSociety Consortium 2013-2017

Deliverable D2.4

Disclaimer This document contains material, which is the copyright of SmartSociety Consortium parties, and no copying or distributing, in any form or by any means, is allowed without the prior written agreement of the owner of the property rights. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the SmartSociety Consortium as a whole, nor a certain party of the SmartSocietys Consortium warrant that the information contained in this document is suitable for use, nor that the use of the information is free from risk, and accepts no liability for loss or damage suffered by any person using this information. This document reflects only the authors’ view. The European Community is not liable for any use that may be made of the information contained herein.

Full project title:

Project Acronym: Grant Agreement Number: Number and title of workpackage: Document title: Work-package leader: Deliverable owner: Quality Assessor: c SmartSociety Consortium 2013-2017

SmartSociety: Hybrid and Diversity-Aware Collective Adaptive Systems: When People Meet Machines to Build a Smarter Society SmartSociety 600854 WP2 Modelling Framework Final Models and Validation Luc Moreau, SOTON Michael Rovatsos, UEDIN Simone Fischer-H¨ ubner, KAU 3 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

List of Contributors Partner Acronym UEDIN UoS UoS UoS

4 of 105

Contributor Michael Rovatsos Heather Packer Luc Moreau Darren Richardson

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

Executive Summary This report summarises the results of work on WP2 tasks. It includes a summary of mechanisms, software and outcomes of preliminary validation experiments. We start by defining a set of requirements for computational modelling in the context of Hybrid and Diversity-Aware Collective Adaptive Systems (HDA-CASs) that take account of the specific, distinguishing properties and features of this class of systems. This is followed by describing the computational modelling methodology for HDA-CASs developed in the work package to fulfil these requirements. This methodology is based on an iterative process of establishing: 1. core vocabularies of concepts; 2. defining interaction models; 3. implementing services in a data-centric; 4. model-compliant way; 5. capturing the run-time of the operation in provenance data that can be mapped onto these models; and 6. adapting the initial design based on insights derived from provenance-based analysis.

Subsequently, this methodology is exemplified by the SmartShare case study, where we review how these steps were performed for that particular system, which has already been fully implemented following our methodology, and is currently being deployed among realworld user communities. The remainder of the deliverable focuses on validation experiments that demonstrate the computational benefits of using a provenance-centric approach to modelling systems operation and evolution. It also focuses the ways in which the aggregation and explanation methods we have proposed provide powerful tools for: developers when implementing and analysing HDA-CAS; machine peers to adapt automated decisions to the observed evolution of the system; and for non-expert users to inspect the internal workings of the system in a human-readable way. We conclude with a reflection on achievements of the work package and lessons learnt, where we also comment on possible future improvements to the proposed methods.

c SmartSociety Consortium 2013-2017

5 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

Table of Contents 1 Introduction

7

2 Computational Modelling Methodology

9

3 Computational Modelling Infrastructure

11

3.1

CAS Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2

Scalable Provenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3

Multiagent Coordination Protocols . . . . . . . . . . . . . . . . . . . . . . . 12

3.4

Explanation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5

Privacy and Provenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Experimental Results

17

4.1

prov template and Scalability in SmartShare . . . . . . . . . . . . . . . . 17

4.2

Patterns of Use in Provenance . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3

4.2.1

Identifying Provenance Patterns . . . . . . . . . . . . . . . . . . . . 18

4.2.2

Tool for Development . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Narrative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Achievements and Lessons Learnt

24

A HDA-CASs Vocabulary

30

B Templates

41

C Generating Narratives from Provenance Chains

84

D PROV-Template Evaluation

90

E URI Narrative Evaluation

95

F A Narrative of an Example PROV Summary

6 of 105

100

http://www.smart-society-project.eu

Deliverable D2.4

1

c SmartSociety Consortium 2013-2017

Introduction

The overall objective of WP 2 is to develop a modelling framework that provides the means to model the operation and dynamics of large-scale hybrid and diversity-aware collective adaptive systems (HDA-CASs). In order to take account of the specific properties of HDACASs in the process of computational modelling, the proof-of-concept models developed

by WP 2 in the context of specific SmartSociety systems, as well as the more general methodology it proposes for modelling future HDA-CASs have to address a set of key requirements: 1. They need to respect hybridity, i.e. provide descriptions that are both machine- and human-readable and capable of capturing the entities and operations involved in hybrid social computations. In the work conducted in WP 2, this has been mainly achieved by making use of provenance data as the intermediate language shared by different peers and components in HDA-CASs. Provenance data provides us with a generic and lightweight language with clear semantics that support interoperability, and we have developed explanation and summarisation techniques to translate it to human-readable natural language.

2. They should address diversity, i.e. be flexible enough to support analysis by multiple stakeholders with different perspectives and interpretations. This is achieved by grounding the modelling framework in a data model that is based on a minimal shared ontological vocabulary, and by describing all relevant system operation in terms of this data model. This allows for the use of generic query mechanisms in order to generate different views of the data as required by a diverse set of stakeholders.

3. They should provide scalability in terms of reflecting complex decentralised interaction processes among large numbers of human and machine peers in a lightweight way that also facilitates inspection and analysis. This is supported by the provenance templates and aggregation mechanisms we have developed, and which allow for effective generalisation from large numbers of individual instances of operations observed in the system.

4. They should support transparency and accountability, and provide poly-centric mechanisms that promote shared responsibility, e.g. feedback and reputation. The first two properties are enabled by mapping the architectural and procedural model of c SmartSociety Consortium 2013-2017

7 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

HDA-CASs we have implemented directly onto a corresponding provenance model, so that a full trace of all relevant system operation is captured in provenance data.

Feedback and reputation, on the other hand, are additional mechanisms that enable us to include human accounts of events occurring in the system (feedback), and further machine use of information derived from this human input (reputation) to adapt system behaviour.

5. They should support collectives, both in terms of collaborating teams and as units of analysis in terms of types and roles of participants and interaction processes between them;

6. They should support system-level adaptability by accounting for multi-faceted, multistakeholder analysis and linkage mechanisms to support the identification and response to emergent behaviour. This, again, is ensured by flexible analysis and querying mechanisms over provenance data, but also by including feedback and reputation information for further human and machine decision making in the system, which allows peers to take emergent patterns of behaviour into account.

This deliverable summarises the work completed within WP 2, to address the above requirements in the proposed modelling framework. Much of this work was performed within the context of the development of the SmartShare application in order to ensure grounding in a real systems context and realism of conceptual and abstract models, and the individual technical contributions that have been delivered have been previously documented in deliverables D 2.1, D 2.2, and D2.3. Here, we therefore focus on a summary of the main insights, and on validation results.

We start by presenting the generalised modelling methodology extracted from designing and implementing the above components in the SmartShare scenario to satisfy the requirements in the list above (Section 2). The computational modelling infrastructure developed in SmartSociety that provides the tools for applying this methodology is presented in 3. Section 4 presents experimental results that serve to validate the proposed techniques against the initial requirements. We conclude with a reflection on lessons learnt (Section 5) from work on WP2, and a discussion of the wider implications of the results of the work package for the SmartSociety project.

8 of 105

http://www.smart-society-project.eu

Deliverable D2.4

2

c SmartSociety Consortium 2013-2017

Computational Modelling Methodology

In this section, we describe the methodology we have developed to support the development of solid engineering principles for HDA-CASs as far as computational modelling is concerned, in terms of design principles (mapping the requirements laid out in the previous section to concrete design elements), operational principles (the affordances of computational models when the system is in operation), and adaptation strategies (in terms of an iterative, observation-based engineering process model reflected in the methodology).

At a general level, our methodology consists of the following steps: 1. Develop a specific vocabulary of agents, entities and activities to describe relevant processes in the HDA-CAS: This step defines the conceptual space within which the system will operate, and specifies what processes fall within the boundaries of the system.

2. Design the interaction model(s) underlying the social computations that should be supported by the HDA-CAS: In this step, the “protocols� that will govern collective interactions are specified in terms of communication between interacting peers, control flow of the collective coordination procedure, data access and synchronisation through shared state.

3. Create a data-centric implementation of the orchestration system: The orchestration system will enact the interaction models defined in the previous step, and it is important that its operations are defined in terms of manipulation of information expressed using the vocabulary defined for the HDA-CAS in question.

4. Map the vocabulary and design templates to capture the creation, modification and use of entities: The operations of the orchestration system (and those of any additional services operating on the primary data that drives the HDA-CAS) have to be mapped to a provenance model that will serve as the foundation for computersupported observation and analysis of the HDA-CAS. 5. Define querying and summarization functionalities for different stakeholders: These will produce the analysis facilities the system provides to human and machine peers for its analysis, and have to be adapted to the needs of the stakeholders involved, as well as to their interpretations (e.g. summaries for the platform operator might be different than for end users). c SmartSociety Consortium 2013-2017

9 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

6. Observe and validate HDA-CAS in operation and iterate through the above steps.

The individual steps in this methodology need to be performed in a domain-specific way for each individual CAS, and we have summarised how they were following in the development of the SmartShare application as a concrete use case described in Table 1 below. These steps have been described separately in previous deliverables in more detail, and demonstrate the main contribution of our methodology which is enabling engineers to support their own designs and implementations of systems that provide user-centric integration of data semantics and large-scale distributed interaction in HDA-CASs. EDIN

SOTON

IMAG

1. Core CAS Vocabulary Development a. Design the core vocabulary describing generalised terms applicable to all HDA-CASs 2. Component Design a. Design the interaction model for the social computation

b. Design the reputation service and its API

c. Design the interaction with Orchestrator and Reputation services

d. Add terms specific to the designed interaction models for the reputation, orchestrator and mobile application 3. Implementation a. Implement the orchestration service

b. Implement the reputation service

c. Implement of the SmartShare mobile application

4. Design Templates a. Refine vocabulary based on the implementation step 3. b. Design templates using the vocabulary 5. Define Summarization Functionalities a. Identify core elements used b. Identify core elements used to describe social computations to generate reputation for orchestration d. Define querying and summarization functionalities for different stakeholders, using the core elements identified in 5a., b. and c.

c. Identify core elements used in the UI

6. Iteration a. Observe and validate HDA-CAS in operation and refine the models by iterating through the above steps.

Table 1: Table showing the steps taken to develop the SmartShare application

10 of 105

http://www.smart-society-project.eu

Deliverable D2.4

3

c SmartSociety Consortium 2013-2017

Computational Modelling Infrastructure

This section provides an overview of the models, architectures, and implementations developed in WP 2. Together, these provide a set of scalable, linkable, semantic, distributed computation techniques that provide the scaffolding for the methodology discussed in Section 2. This section highlights that, though exemplified and specifically implemented using the SmartShare scenario in the previous section, the core contributions in terms of computational modelling, and the systems infrastructure to support them are in themselves domain-independent and reusable.

3.1

CAS Vocabulary

The core HDA-CAS vocabulary and its extension describes the core vocabulary and subtypes defining SmartShare specific agents, entities and activities (see Appendix A). Together with the ontologies and formal models it provides semantics for the entities described by this vocabulary. The additional subtypes for SmartShare enable the summarizations and explanations to provide individualised descriptions of SmartShare agents and activities. Specifically, the vocabulary focuses on describing three components: (1) agents within HDA-CASs, including users, peers, and collectives and their properties; (2) activities; and, (3) entities describing plans, tasks and messages.

3.2

Scalable Provenance

prov template3 , built on the prov language, provides scalability benefits and enables adaption for HDA-CASs using provenance information (supporting requirements 3 and 6 in Section 1), which include: 1. The scalability in its engineering, where the logging of values is separate from provenance generation (supporting our scalability Requirement 3 see Section 1).

2. The decoupling of the semantics from the variables’ values allows the values to be expanded by more than one template, which may or may not use all of the variables. This flexibility allows the template to adapt to changes in an HDA-CAS, whose vocabulary or computational model may change over time (supporting our adaptability Requirement 6 see Section 1).

3

prov template https://provenance.ecs.soton.ac.uk/prov-template/

c SmartSociety Consortium 2013-2017

11 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

3. The flexibility to annotate variables in a template using RDF types as extra attributes. This can be used align the provenance element’s types to other vocabularies. It can also be used to annotate variables that might contain private information, where different privacy policies and expansion strategy might be used when handling this variable (supporting our adaptability Requirement 6 see Section 1).

4. The reduction of overhead costs associated with network, storage and access (supporting our scalability Requirement 3 see Section 1). This is evaluated in Section 4.1.

A prov template is designed to model a specific activity. The templates designed for the SmartShare application are documented in Appendix B, some of the templates are agnostic to the SmartShare application, however, they are specific to the type of service.

For example, the UI templates can be used for other HDA-CASs UIs. Other templates used in SmartShare are application specific. For example, the orchestrator templates that are specific to SmartShare use vocabulary designed for the generation of ride plans and their negotiation.

3.3

Multiagent Coordination Protocols

Another central element of the technical infrastructure that enables our computational modelling methodology has been the definition of a formal framework to enact multiagent coordination protocols in a purely data-driven way, and the implementation of an orchestration system to build scalable and robust CASs. Essentially, this framework allows us to model distributed interactions (implementing the “Play-by-data� paradigm for social orchestration we have proposed) by way of a set of data stores which are modified by individual peers as they interact with each other via the orchestration system, which controls how these data stores are updated and kept consistent with each other (for example, if one peer decides to stop contributing to a joint activity, not only should other participants be made aware of this, but also should this peer no longer be able to effect changes on the shared state of the task she no longer contributes to). This re-interpretation of distributed multi-agent interaction as data is exemplified in figure 1.

In deliverable D 2.2, we provided a formal semantics for the general (domain-independent) orchestration model by translating agent protocols to interlinked message stores.

12 of 105

http://www.smart-society-project.eu

c SmartSociety Consortium 2013-2017

Deliverable D2.4

REJECT(p, o, t) REJECT(a3 , o, t2 ) INFORM TASK(o, p, t) INFORM INVALID(o, p, t) REQUEST(p, o, I, G, C) REQUEST(a1 , o, I, G, C1)

INFORM TASK(o, {a1 , a2 }, t1 )

REQUEST(a2 , o, I, G, C2)

AGREE(p, o, t)

REQUEST(a3 , o, I, G, C3) ′

INFORM INVALID(o, a2 , t2 )

INFORM TASK(o, {a2 , a3 }, t2 )

AGREE(a2 , o, t2 )

′

REQUEST(a4 , o, I , G , C4 ) NO SOLUTIONS(o, p, I, G, C) NO SOLUTIONS(o, a4 , I ′ , G′ , C4 ) NO SOLUTIONS(o, a3 , I, G, C3)

AGREE(a2 , o, t1 ) AGREE(a1 , o, t1 )

Figure 1: Data-centric view of the interaction model underlying the SmartShare application (only the task composition and negotiation stages are shown). Each message type corresponds to a data store (document), where every individual message contributed by a peer is linked to subsequent messages that are causally connected to it. For example, tasks specified in INFORM TASK messages are linked to the task REQUESTs they correspond to. The orchestration service manages dependencies and ensures shared state is always kept consistent. All major operations of this service are stored by the provenance service, so that the provenance store provides a full up-to-date trace of the operation of the HDA-CAS.

In our implementation of SmartShare, these data stores are simply Web documents, and peers interact via a REST API. In this way, we can easily link the operations performed among peers (as mediated by an orchestration platform) to provenance data referring to the original documents. The semantics of the model, based on a distributed sequential state transition model that borrows much from formalisms used in the AI planning systems literature, enable us to translate interaction models expressed in multiagent protocol diagrams (which are similar to UML sequence diagrams) into a set of simple addition and deletion operations on “message stores” that correspond to the message types in the original protocol.

This translation procedure underpinned implementation of the SmartShare orchestration system, where the social computation required for the ridesharing application was defined through interaction protocols, and then translated into a set of Web resources that capture, in this specific case, a distributed team formation activity that involves human peers posting requests and offers, a machine peer calculating possible joint tasks, and the participants of each task iteratively agreeing to it or rejecting it, and, where tasks are agreed, later posting feedback on the execution of these tasks. c SmartSociety Consortium 2013-2017

13 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

In terms of our overall modelling methodology, this step involves identifying all relevant agents, the activities they can perform, the constraints that govern dependencies between these activities, and the aspects of the distributed state of the orchestration process that have to be shared among them. In other words, it supplies the (dynamic) operation model for the HDA-CASs on the basis of the (static) conceptual model previously defined in the respective HDA-CAS vocabulary. It is worth pointing out that the techniques for scalable provenance summarised in the previous section are essential to ensure that the provenance models built for the system can be described at a similar level of abstraction as the orchestration model, so that, for example, message templates in our protocols correspond to parametrised provenance templates, and individual bindings for these can be managed in a scalable way, accommodating large numbers of individual instance operations without growing the respective provenance models in themselves. This is of vital importance if we want to make sure that our systems provide the scalability properties expected of realworld HDA-CASs.

3.4

Explanation Techniques

It is often necessary for HDA-CASs that make decisions based on provenance documents to communicate that provenance information to their human users in order to facilitate transparency and accountability. It would be possible to use graphical approaches for this, but, in many cases, it is more natural or appropriate to communicate this data either textually or verbally. In order to support this, systems have to be created that can convert the abstract, graphical representations of provenance into a linear, textual form.

During this project, explanation techniques have been developed using the prov types and CAS types of prov elements along with their relationships to generate human-readable descriptions in order to support transparency and accountability (see Requirement 4 in Section 1). These descriptions can be embedded into CASs to show transparently how resources are used and generated by the system. They can also describe user behaviour, which helps increase users’ awareness of others and their actions, thus supporting accountability.

As part of the work reported in the paper “Generating Narratives from Provenance Relationship Chains� [1] (see Appendix C), we identified that the biggest problems of utilising the structure and elements in provenance data were: 1. Identifying and presenting interesting facts to support a particular use case. For 14 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

example, a user can view an explanation about someone else to aid in their decision to share a ride with them, a narrative can provide evidence of reliability from the provenance based on features such as the number of feedback reports left by a user, or the number of times this user has interacted with SmartShare.

2. How to describe prov elements without referring to long complicated URIs, while exploiting their context and structure in a linguistic manner. It is worth noting that URIs, per the RFCs that define them, formally contain no linguistic information that would facilitate natural language generation. However, many system developers have created systems that mint meaningful URIs, for a number of possible reasons, such as increasing code maintainability. This means that if one were able to understand how this linguistic information is often informally encoded in URIs, then it would be possible to exploit this information for the purposes of natural language generation.

The sentence templating and the generation of human-readable URIs approaches used to for explanation generation are described in Appendix C and Section E, they supports diversity by enabling provenance information about reputation to be consumed easily by humans. In extension to this work, we are currently developing sentence templating and human-readable URIs to support both accountability and transparency. We have planned an evaluation which will run in February, it will evaluate explanations from the provenance generated by the reputation service that will enable users to understand (1) how their reputation is generated, which takes into account the decay of feedback reports (supporting both accountability and transparency of the reputation service); (2) recommendations of which subject to choose, which are motivated by whether a subject routinely leaves feedback and whether they rate highly, which contrasts to using just a reputation rating to support decision making (supporting both user and machine accountability and transparency); and (3) how they are perceived by others, which aims to increase their awareness that their actions within an HDA-CAS has consequences (supporting the user’s accountability and the machine’s transparency).

3.5

Privacy and Provenance

During our collaboration with WP1, we identified general cases where the structure of a PROV document can leak sensitive information. This collaboration resulted in a draft paper[2] which was presented at the IFIP Workshop on Open Research Problems in Network Security. We also developed the following example, which exposes sensitive inforc SmartSociety Consortium 2013-2017

15 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

mation, based on theSmartShare scenario. Alice has a SmartShare receipt she wants to claim for, but Bob doesn?t want his destination to be made public. Provenance is published when: Alice tweets that she is traveling to London; Bob’s generates a diary entry exposing that he is traveling with Alice; and the company Alice works for publishes the details of the claim because of their transparency policy (see Figure 2). The combined provenance (see Figure 3) exposes that Bob travelled to London. We will explore how to reduce exposing sensitive information from provenance in WP1.

Figure 2: Bundles showing the provenance published when Alice tweets, Bob’s calendar and Alice’s claim

Figure 3: Combined provenance documents

16 of 105

http://www.smart-society-project.eu

Deliverable D2.4

4

c SmartSociety Consortium 2013-2017

Experimental Results

In this section, we describe lab-based experiments and their results to validate that our methodology supports the design of HDA-CASs and their analysis. In our validation experiments, we use small-scale simulated scenarios with the SmartShare application to demonstrate how the requirements from Section 1 are supported by our methods. Naturally, as large-scale real-world data is not available yet, we will not be able to fully evaluate the scalability-related requirements through experimental evaluation. However, many of these issues have already been validated in simulation experiments and do not rely on having real-world data. A full evaluation will have to be postponed until the real-world SmartShare deployment (which is currently in progress) has produced sufficient data.

Specifically, in this document we evaluate the following hypotheses: 1. prov template provides a significant reduction to networking overheads by reducing the number of bytes sent over the network.

2. The Aggregator of Provenance Types (APT) [3] approach enables the evaluation of user behaviour, specifically, it can support the evaluation of splices of the population, such as drivers and commuters, and casual users and daily commuters.

3. The APT approach enables the visual evaluation of resources used in social computations.

4. URIs in provenance data contribute to its illegibility and transforming the information in the URI can provide a suitable substitute in explanations.

5. Explanations generated using our application-independent provenance explanation system provide more readable sentences compared with translating a triple directly into English.

4.1

prov template and Scalability in SmartShare

In this section, we summarise our evaluation (see Appendix D) where we compare the network costs of using prov template against prov documents (see Hypothesis 1). We investigated the sizes of provenance templates, bindings and expansions for the SmartShare application in three different languages used to express provenance. In our investigation, we found that there are three factors which influenced their size: (1) language used to c SmartSociety Consortium 2013-2017

17 of 105

c SmartSociety Consortium 2013-2017

prov APT

Deliverable D2.4

Nodes 259 54

Edges 751 68

Table 2: The number of nodes and edges in the generated provenance and its summarization express it; (2) characteristics of a template; and (3) types of data expressed in the bindings.

On average using prov template reduces the number of bytes sent by 26.75% 45.03% 42.96% for TTL, provn, and JSON, respectively.

4.2

Patterns of Use in Provenance

In this section, we present examples of provenance summaries generated from data collected from the SmartShare application. We first discuss the reduction of nodes in a provenance graph and its summary for a two-person ride. We then evaluate Hypotheses 2 and 3, where we aim to show that the APT approach enables the evaluation of user behaviour as well as the visual evaluation of resources used in social computations.

The Aggregator of Provenance Types (APT) generates provenance summary reports, which provide an overview of the provenance generated by an application. In the case of the SmartShare application, provenance summaries describe the actions of users and how response objects are used. On average for a two-person ride, the summarization approach reduces the number of nodes and edges by 4.8 and 11.04 times, respectively (see Table 2). This reduction enables users to review the patterns in provenance which can show the frequency of activities and entities in relation to others. A narrative detailing the summary of a two-person ride is given in Appendix F. In the following subsections, we discuss features in the provenance summaries that show the difference between different types of user behaviour and how it can be used a development tool for HDA-CASs (supporting Requirements 2 and 6, respectively, as described in Section 1).

4.2.1

Identifying Provenance Patterns

APT can be used to provide an insight into patterns in provenance, so that these patterns can be used to classify the provenance’s subjects and their actions. Automatic identifications of these patterns would allow CASs to adapt their behaviour. For example, the 18 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

orchestrator uses the reputation rating to generate matches, however, if the system observed that the reputation was not frequently used when a user accepts a ride, then the orchestrator could reduce the influence of the reputation when generating future matches.

The summaries can be generated to provide an overview of the whole CAS, one or more of its components, and provenance generated by a particular user’s or set of users’ actions.

The output of APT can be adapted by specifying which element types can be featured or collapsed together. For example, FeedbackReports and ReputationReports can both be described as Report types and prov entities, and can be collapsed together using the Report or Entity type. Generalising feedback and reputation reports would reduce the number of elements on the summary, which may be useful when looking at other factors.

However, if evaluating the use of entities of type ReputationReports then it is useful to use this level of granularity of types. Currently, APT is adaptable through using a SPARQL query which categorises each element in a prov document using its type defined in its extra attributes.

The data collected during the three Italian deployments of SmartShare will be used to compare the following: 1. Daily commuters and casual travellers - Daily commuters’ and casual travellers’ behaviour will be evaluated using APT. Differences of behaviours between these types of commuters and casual travellers will be observable in summaries, which will highlight frequencies of user’s actions and their actions’ results.

In order to analyse the users’ behaviour, we will focus our analysis to the UI’s provenance because it provides details about the users’ behaviour, where in contrast the orchestrator and reputation services provide details about the generation of resources related to them (ride requests, rides, feedback reports, etc). The UI’s expanded provenance documents will be archived using the ProvBindings service.

We then identify all of the users4 that the provenance references using a script, which runs the a SPARQL query used to classify the prov element’s types for each identified user. Each SPARQL query will only summarise provenance about a specific user.

In order to analyse a user’s behaviour ground truth provenance summaries are required for daily commuters and one-time travellers. We will compare the similarity of a user’s summary with the ground truth. Identifying whether the patterns for 4

We only store a hash of the users’ name in the provenance.

c SmartSociety Consortium 2013-2017

19 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

daily commuters and one-time travellers are dramatically different could indicate that each type of users could benefit from a UI that supports these two types of users.

2. Drivers and passengers - The behaviours of drivers and passengers will also be observable in summaries. We will analyse differences in their behaviour, summaries for both drivers and passengers will be compared. The summaries will enable us to observe differences in their interactions with the UI, where summary patterns are created when users view pages in a particular order which results in specific types.

We will investigate the frequency with which users check whether there are available rides and the frequency of successful requests.

In order to analyse the commuters and drivers, we will generate provenance summaries from the UI’s expanded bindings. We focus our analysis on the UI’s provenance because it provides the detail we require to analyse the features described in the above paragraph. The UI’s expanded provenance documents will be archived using the ProvBindings service. The bindings will then be classified using a SPARQL query, which matches whether a provenance document refers to a new offer page or new search. This, in turn, indicates that the user is a driver or commuter, respectively.

The differences identified in this analysis could be used to influence the mechanisms specifically for drivers and passengers. For example, if the provenance summary shows that passengers submit more ride requests and after investigating the ride plan resources it reveals that they haven’t been matched to a plan because of their ride preferences, a mechanism to show ride offers to passengers that are a close match to their parameters could increase their success.

3. Viewing reputation vs. not viewing reputation - SmartShare application users have the choice to view reputation before they accept a ride. Provenance summaries show whether reputation has been used and the frequency of its use in relation to the number of times the accept a ride page is viewed. Figure 4 shows an extract from a provenance summary showing provenance generated by the UI, and is focused on the view where they can select which rides to accept. These provenance summaries are generated from a two-person ride where the only difference is that one set of users viewed reputations and the others do not. In more detail: 20 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

(a) Nodes 22 and 16 in Figures 4b and 4a, respectively, are the summary nodes for the page where the user can select to view a user’s reputation before agreeing to share a ride with them. (b) Node 18 in Figure 4b contains responses from the reputation and orchestrator which are required when viewing reputation, there is no such node in Figure 4a.

The patterns in Figure 4 are general patterns when observing the use of reputation, specifically where a node representing the page to accept a ride is summarised (Nodes 22 and 16 in Figures 4b and 4a, respectively) and this page is derived from a set of responses (Node 18 in Figure 4b) if the user decides to view the reputation of potential ride participants. In order to understand the trends of use of reputation information, the summary will connect the view and response with a weighted edge.

If the edge is the same width as the others surrounding it, then this indicates that users typically view reputation. If it is thinner, then they do not. This pattern can be detected in the provenance graph algorithmically by using the APT’s summary output by: (a) Querying whether there is a node n1 of type CAS:Response which was derived from a node n2 with type CAS:ReputationReport, where n1 is connected by the was derived from relationship to node n3 with type CAS:View was generated by a node n4 of type CAS:View. (b) Comparing the weight of both the was generated relationship between n3 and n4 and the was derived from the relationship between n1 and n3 , to analyse trends in the use of reputation reports.

4.2.2

Tool for Development

The APT provides an insight into the workings of an application and can be used to debug and optimise code. During the development phase, inconsistencies and irregularities in the summaries may occur because of problems with the templates and bindings, issues in the code, or unexpected and unindented behaviour. Identifying and investigating these inconsistencies and irregularities in summaries supports debugging and code optimisation.

For example, a summary that shows API calls to other services can be used to visually evaluate the frequency of calls made in relation to the other activities and could be used c SmartSociety Consortium 2013-2017

21 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

(a) Without users viewing reputation.

(b) With users viewing reputation.

Figure 4: Extract of provenance summary of users selecting rides to influence caching strategies. Specifically, APT has supported the debugging and code optimisation of SmartShare components to address the following issues: 1. The UI made unnecessary calls to the orchestrator and reputation managers when a user first logs in. This was indicated by the provenance summary in Figure 5, where the reputation manager generates provenance showing that a response is generated and there are no relationships connecting it to entities that the UI or orchestrator are associated with. This indicated that there was an issue, however, it did not indicate which agent was responsible for making the call. Identifying which component was responsible for making the call was determined by examining the sequence of provenance bindings submitted to the provenance store.

2. The reputation values were not being refreshed during negotiation, only when feedback was submitted. This was indicated by the provenance summary in Figure 6, where no calls were made to the reputation manager during the organisation of a ride. The lack of calls made to the reputation manager for one ride may not show that there is a problem because the UI may cache values for optimisation. However, over a period of observation calls for requesting reputation, there was only one which 22 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

Figure 5: This provenance graph shows that there is no connection between the response from reputation and the UI that made the call.

happened after feedback submission.

Figure 6: This provenance graph shows that there were no calls to the reputation manager during the organisation of a two-person ride.

3. Unexpanded variables in an expanded template and binding indicate that there may be issues with these unexpanded values submitted in a binding. When a variable is unexpanded, the APT approach throws an exception. An unexpanded variable may be caused when a variable is not passed to the binding correctly, or there was no resource created and hence there is no URI to reference it. This was the case when the orchestrator responded to an API call requesting ride requests that a user is attributed to. Specifically, there was an unexpanded variable in the ride request call for the orchestrator. This occurred because the call did not match the specification in the documentation, and resulted in a change of the specification, where a ride request was not always used to generate a response. c SmartSociety Consortium 2013-2017

23 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

4. Similar to unexpanded variables, empty values may be caused when a variable is not passed to the binding correctly, or there no resource was created and hence there was no URI to reference it. In the case shown in Figure 7, the unexpanded variable highlighted that there was a caching issue, where the reputation value (node T 33(3)) did not capture the resource’s URI or its freshness, so that it could be periodically refreshed.

Figure 7: Node T 33(3) is a reputation report that is not derived from another entity.

4.3

Narrative Evaluation

In this section, we summarise the results from our evaluation (see Appendix E) of the natural language generation which utilises the structure of the URIs in a provenance record to describe that record. This evaluation enabled us to investigate the legibility of URIs used in Provenance (see Hypothesis 4), and the generation of sentences using our applicationindependent provenance explanation system compared against a direct translation of a triple (see Hypothesis 5). Our study showed that our system (which exploits the linguistic information in URIs) performs significantly better across all evaluated dimensions (grammatical correctness, fluency, and ease of understanding), but most prominently in the perceived fluency.

5

Achievements and Lessons Learnt

In this section, we detail our achievements, reflect on lessons learnt and what we would do differently with hindsight. Our motivation for sharing our lessons learnt is to support 24 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

future HDA-CASs with developing their own specialised vocabularies and enable them to benefit from the tools we developed.

During WP2, we achieved various implementations that support the transparency and accountability, and tools to support scalability of generating, storing, and sending provenance data. Our main achievements include the development of: 1. Tools to summarise provenance types supporting accountability and HDA-CASs development; 2. Approaches to generate narratives based on provenance; 3. A provenance enabled Reputation service; and 4. The ProvBinidngs service to manage a HDA-CASs provenance templates, bindings, and expansions.

During the development of these tools, approaches and services, we identified the following lessons and what we would do differently to take advantage or reduce the effect of any issues we encountered: 1. The provenance summaries were surprisingly informative when viewing how resources are used across multiple components in the SmartShare application as a whole. They were used to identified potential issues with missing and redundant API calls and issues related to the derivation of a resource (see Section 4.2.2). Viewing the summaries enabled WP2 to better understand the processes of the SmartShare components and discuss code optimisation with the project’s partners. The APT approach can be used by developers as a tool to verify how resources are used in an application and debugging tool for across provenance enabled services.

2. The current implementation of the Reputation and ProvBindings service could benefit from improvements. During the development of SmartShare, issues occurred using these services when they received JSON objects not containing the correct keys and empty binding variables. These errors should have been dealt with at the API level, where posted data structures should be verified. In the case of the ProvBindings service, this would require a wrapper for each template to verify that a binding contains a binding variable for each of the variables defined in a template, and that these binding variables are the correct type. c SmartSociety Consortium 2013-2017

25 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

3. The URIs used to expose resources within a HDA-CAS are important because they have knock-on effects on the provenance and provenance summaries. Specifically, provenance uses URIs to refer to resources and makes use of prefixes and local names, long local names make the provenance hard for humans to read and parse.

In order to support privacy, the URIs should not contain private information such as usernames because this will be exposed by the provenance. For the SmartShare application, the ProvBindings service had to parse bindings and their expansions to anonymise usernames to preserve privacy. This added unnecessary load on the provbinidngs service, because it had to load each binding and identify usernames using a regular expression, and then using another regular expression replace all references to the user in the binding. This approach requires prerequisite knowledge about the structure of the URIs used in order to write bespoke regular expressions, and hence this can not be agnostic for other applications. Heuristics for URIs used in provenance would improve readability and reduce privacy issues.

4. A SPARQL query is used to adapt the output of the APT’s approach for analysis.

These queries allow the summaries to be extremely adaptable, however, this level of adaptability may not be necessary for simple tasks. They can be complicated to write and are specific to an application because they are based on its vocabulary. A simple but general approach would be to use a query that classifies all types declared in the provenance, however in some cases this might provide too many nodes in the summary to clearly compare important features. Tools to specify which prov elements should be features would enable this to be more accessible to developers.

5. Better tools to check the well-formed-ness of provenance data would have enabled faster development. In the provenance during the development of the SmartShare application, all of the bindings submitted were valid however, when the bindings were combined there were issues with event ordering, circular derivations and specialisation constraints. Many of these issues were caused by the variables being used as both a request and a response. Tools that identify which nodes might be causing such issues and which bindings they originate from would better support developers.

Regarding the overall computational modelling framework, it is important to highlight how our overall methodology follows a principled approach to HDA-CAS development where the formal specification of the system is rigorously mapped onto provenance models that are used for explanation, analysis, and adaptation. Besides the obvious benefits 26 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

of this approach for supporting transparency and accountability, and the advantages it offers in terms of defining functionalities that support the “social fabric” for these types of systems (e.g. a reputation service capable of explaining its assessments and decisions in a transparent and human-readable way), our approach pushes the envelope of achieving a modelling approach where the system “is” the model plus the run-time data that can be interpreted in terms of this model. This not only facilitates principled development and adaptation, but also supports the hybridity and diversity aspects of HDA-CASs. It enables stakeholders to inspect all definitions of concepts used in the computational model, analysis of the data produced by the system by exploiting a direct mapping from this data to conceptual models with formal semantics in all stages of processing, using both machine- and human-readable representations. We believe that this approach has the capacity to enable future modalities of poly-centric, participatory co-design and coevolution of HDA-CASs by allowing non-experts to look “under the hood” of a complex HDA-CAS.

c SmartSociety Consortium 2013-2017

27 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

References [1] H. S. Packer and L. Moreau, “Generating narratives from provenance relationship chains,” in Proceedings of the 2015 Workshop on Narrative & Hypertext. ACM, 2015, pp. 37–41.

[2] J. Reuben, L. A. Martucci, H. S. Packer, S. Fischer-Hbner, and L. Moreau, “Privacy and provenance: Challenges, requirements and open problems,” IFIP Workshop on Open Research Problems in Network Security. IFIP. Draft Version, 2015.

[3] L. Moreau, “Aggregation by provenance types: A technique for summarising provenance graphs,” arXiv preprint arXiv:1504.02616, 2015.

[4] A. Ratnaparkhi et al., “A maximum entropy model for part-of-speech tagging,” in Proceedings of the conference on empirical methods in natural language processing, vol. 1.

Philadelphia, USA, 1996, pp. 133–142.

[5] P. Treebank, M. P. Marcus, B. Santorini, and M. A. Marcinkiewicz, “Building a large annotated corpus of english: the penn treebank,” 1993.

[6] J. C. Lester and B. W. Porter, “Developing and empirically evaluating robust explanation generators: The knight experiments,” Computational Linguistics, vol. 23, no. 1, pp. 65–101, 1997.

28 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

Appendix The following appendices are taken from other documents and are presented to support the material presented in the deliverable.

c SmartSociety Consortium 2013-2017

29 of 105

c SmartSociety Consortium 2013-2017

A

Deliverable D2.4

HDA-CASs Vocabulary

30 of 105

http://www.smart-society-project.eu

c SmartSociety Consortium 2013-2017

cas:ReputationManager

cas:UserInterface

cas:IncentiveManager

cas:CompositionManager

cas:NegotiationManager

cas:OrchestrationManager

cas:Collective

cas:Agent

cas:User

cas:Peer

cas:Record

cas:API

cas:View

cas:ReputationReport

cas:FeedbackReport

cas:Response cas:Request

cas:Message

cas:Protocol

cas:Plan

cas:Task

cas:Call

cas:Acknowledgement

cas:Identity cas:Capability

prov:Agent

prov:Activity

prov:Entity

cas:Activity

cas:SendingResquest

cas:SubmittingRequest

cas:SendingResponse

cas:ChangingView

cas:GeneratingComposition

cas:PostingTaskRequest

cas:NegotiatingTasks

cas:StoringTask

cas:AuthenticatingIdentity

cas:ComposingTasks

cas:GeneratingReputation

cas:StoringFeedback

cas:SubmittingFeedback

Deliverable D2.4 c SmartSociety Consortium 2013-2017

Figure 8: CAS Vocabulary for the SmartShare demonstrator taken from Deliverable 2.2.

The yellow nodes denote prov dm terms, the pink nodes with black text are core to HDA-CASs, the dark red nodes denote terms used by the reputation manager, the dark blue nodes denote terms used by the orchestration peer, the green nodes denote terms that are used by the UI, and the pink nodes with white text are terms that are non specific to peers but are not in the core vocabulary.

31 of 105

12/22/2014

The SmartSociety CAS Namespace

The SmartSociety CAS Namespace Unofficial Draft 22 December 2014 Editors: Heather Packer, University of Southampton Luc Moreau, University of Southampton This document is licensed under a Creative Commons Attribution 3.0 License.

Introduction The namespace name http://purl.org/cas/ns# defines terms for the SmartSociety Collective Adaptive Systems (CAS).

The index below provides links directly to the definition of the terms within the above specifications.

Index A|C|F|I|K|L|M|O|P|Q|R|S|U|V|W

A Acknowledgement An acknowledgement is a message that is passed between two agents to signify acknowledgement, or receipt of a response, which is part of a communications protocol. cas: Acknowledgement

Activity An activity is the condition in which things are happening or being done. cas: Activity

Agent file:///Users/heatherpacker/cas/landing-page.html

1/9

12/22/2014

The SmartSociety CAS Namespace

An agent is anything that can possibly perform an activity. Alternatively, anything that has capabilities. cas: Agent

API A api is a set of specifications for calls that can be processed by a peer. cas: API

AuthenticatingIdentity Authenticating identity is an activity that authenticates a user. cas: AuthenticatingIdentity

C Call A call is a signal transmitted to a peer over a computer network. cas: Call

Capability A capability is a prospective, though not necessarily planned or agreed, activity. cas: Capability

ChangingView Changing view is an activity that changed the view of a user interface. cas: ChangingView

Collective A collective is an agent that consists of multiple member agents. cas: Collective

ComposingTasks file:///Users/heatherpacker/cas/landing-page.html

2/9

12/22/2014

The SmartSociety CAS Namespace

Composing tasks is an activity that may be comprised of the following activities authenticating identity, computing composition and computinginvalidtasks. cas: ComposingTasks

CompositionManager A Composition Manager A composition manager is a peer which specialises in composing tasks by searching and matching relevant peers and computing plans for a task. cas: CompositionManager

ComputingComposition Computing composition is an activity that computes a set of valid tasks given constraints or negotiation inputs. cas: ComputingComposition

ComputingReputation Computing reputation is an activity that is run by the reputation manager when a feedback report is submitted, it computes a reputation report for all the subjects referred to by the submitted feedback report. cas: ComputingReputation

F FeedbackReport A feedback report is a report about a subject that contains a set of value rating categories. For example, "star rating = 4.3". cas: FeedbackReport

I Identity file:///Users/heatherpacker/cas/landing-page.html

3/9

12/22/2014

The SmartSociety CAS Namespace

Agents, users, peers all have identities. An unauthenticated user gets assigned an identity automatically. cas: Identity

IncentivesManager A incentives manager is a peer that specialises in providing incentives for peers to participate in tasks. cas: IncentivesManager

M Message A message is a piece of information exchanged between agents. cas: Message

N Negotiatingtask Negotiating task is an activity that submits a task which may alter other tasks, it may comprise of an authenticating identity and storing task activities. cas: Negotiatingtask

NegotiationManager cas: NegotiationManager

O file:///Users/heatherpacker/cas/landing-page.html

4/9

12/22/2014

The SmartSociety CAS Namespace

Opinion An opinion is a quantitive value of the estimation of a subjects worth based on feedback categories about it. either an activity, agent, peer, user, or collective, that is being discussed, described, or dealt with in the context of feedback reports and reputation reports. cas: Opinion

OpinionReport An opinion report is a reputation report, which contains a single key value pair and binds an opinion to a value. The value is an aggregation of ratings from a set of reputation topics. cas: OpinionReport

OrchestrationManager An orchestration manager is a peer, which specialises in coordinating the interaction between other peers. cas: OrchestrationManager

P Peer A peer is a software agent in a SmartSociety system that represents another agent. cas: Peer

Plan A plan is a specification for the execution of a task. cas: Plan

PostingTaskRequest Posting task request is an activity that posts a task to orchestration manager. cas: PostingTaskRequest

file:///Users/heatherpacker/cas/landing-page.html

5/9

12/22/2014

The SmartSociety CAS Namespace

Protocol A protocol is a collection of plans that involve communications between peers. cas: Protocol

R ReputationManager A reputation manager is a peer, which specialises in storing feedback about subjects and generating reputation and opinion reports about subjects. A view is an entity pertaining to a view of a user interface. cas: ReputationManager

ReputationReport A reputation report is a report about a subject that contains a set of value rating categories. For example, a subject has been rated with a set of star ratings, and the average of those star ratings are "average star rating = 4.3". cas: ReputationReport

RequestingOpinion Requesting opinion is an activity that requests a opinion report from the reputation manager. cas: RequestingOpinion

Request A request is a call that is used to request information from a service. cas: Request

Respond A respond is an activity that is used to respond to an API call. cas: Respond

Response file:///Users/heatherpacker/cas/landing-page.html

6/9

12/22/2014

The SmartSociety CAS Namespace

A response is an entity that is computed in response to a request. cas: Response

S SendingMessage A sending message is the constituent of a protocol: it involves information exchange. cas: SendingMessage

SendingNegotiationResponse Sending negotiation response is an entity that contains the response to a negotiating tasks. cas: SendingNegotiationResponse

SendingRequest Sending request is an activity that sends a request to peer. cas: SendingRequest

SendingResponse Sending response is an activity that sends a response to peer. cas: SendingResponse

StoringFeedback Storing feedback is an activity used by reputation manager to store a feedback report within it. cas: StoringFeedback

StoringTask Storing task is an activity that stores a task locally. cas: StoringTask file:///Users/heatherpacker/cas/landing-page.html

7/9

12/22/2014

The SmartSociety CAS Namespace

SubmittingTaskRequest Submitting task request is an activity that submits a task, it may comprise of an authenticating identity and storing task activities. cas: SubmittingTaskRequest

SubmittingFeedback Submitting feedback is an activity that submits a feedback report to the reputation manager. cas: SubmittingFeedback

Subject A subject is either an activity, agent, peer, user, or collective, that is being discussed, described, or dealt with in the context of feedback reports and reputation reports. cas: Subject

T Task A task is a potential activity that involves capabilities, potentially contributed by several agents. cas: Task

TaskRequest A task request is a request for a potential activity that involves capabilities, potentially contributed by several agents. cas: TaskRequest

U file:///Users/heatherpacker/cas/landing-page.html

8/9

12/22/2014

The SmartSociety CAS Namespace

User A user is a person who is using a SmartSociety system. cas: User

UserInterface A user interface is a software component that allows a user to view information in a peer and interact with it through API calls. cas: UserInterface email address here $Revision: 1.1 $ of $Date: 2013/04/29$

Deliverable D2.4

B

c SmartSociety Consortium 2013-2017

Templates

c SmartSociety Consortium 2013-2017

41 of 105

Ride Share Templates

April 23, 2015

Contents 1 Templates and Bindings 1.1 Basic Template and Binding Example . . .

1.1.1 Template . . . . . . . . . . . . . . .

1.1.2 Binding . . . . . . . . . . . . . . . .

1.2 Namespaces . . . . . . . . . . . . . . . . . .

1.3 Considerations for Namespaces and Prefixes

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2 2 2 2 3 3

2 Orchestrator 2.1 Submitting Task and Task Requests . . . . . . . . .

2.1.1 Submitting Task Template . . . . . . . . . .

2.1.2 Submitting Task Request Template . . . . . .

2.2 Composing Tasks . . . . . . . . . . . . . . . . . . . .

2.2.1 Composing Task Template . . . . . . . . . .

2.2.2 Composing Task Template without Opinions 2.3 Task Negotiation . . . . . . . . . . . . . . . . . . . .

2.3.1 Task Negotiation Template . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

5 5 5 9 13 13 18 21 21

1

. . . . .

. . . . .

. . . . .

. . . . .

Chapter 1

Templates and Bindings This Chapter introduces how to use PROV Template1 for Ride Sharing scenarios.

1.1

Basic Template and Binding Example

1.1.1

Template

The following template contains two var:composition_manager and var:task, the template is written in the provn format. document prefix ex <http://example.org/> prefix var <http://openprovenance.org/var#> bundle ex:b agent(var:composition_manager) entity(var:task) wasAttributedTo(var:task, var:composition_manager) endBundle endDocument

1.1.2

Binding

The following provenance binding defines variables for var:composition_manager and var:task. The binding is written in turtle2 which will be the format used to submit bindings for ride share. @prefix @prefix @prefix @prefix @prefix @prefix

prov: <http://www.w3.org/ns/prov#> . orchestrator: <http://www.rideshare-orchestrator.com/> . rp: <http://www.rideshare-orchestrator.com/ridePlans/> . tmpl: <http://openprovenance.org/tmpl#> . var: <http://openprovenance.org/var#> . xsd: <http://www.w3.org/2001/XMLSchema#> .

var:composition_manager a prov:Entity ; tmpl:value_0 orchestrator:comp .

1 PROV 2 Turtle

Template: https://provenance.ecs.soton.ac.uk/prov-template/#namespaces http://www.w3.org/TR/turtle/

2

var:task a prov:Entity ; tmpl:value_0 rp:203 ; tmpl:value_1 rp:122 .

The black text will remain the same for all bindings for the example template.

The dark red text refers to the namespaces introduced in the bindings which are not present in the template.

Specifically, @prefix orchestrator: <http://www.rideshare-orchestrator.com/> . @prefix rp: <http://www.rideshare-orchestrator.com/ridePlans/> .. The namespace’s prefixes are used before the variables. The blue text are the values assigned to the variables defined in the template, comp is assigned to var:composition_manager where the namespace is orchestrator, and 122 and 203 is assigned to var:task where the namespace is rp. It is worth noting that it you can create more than on instance of a variable, which is indicated with green font. This may occur when an activity produces more than one entity, for example a composition activity might generate two plans.

1.2

Namespaces

The namespaces presented in Table 1.1 are used in this document: Prefix cas prov tmpl var xsd rideserver rideservice view orchestrator rr rp reputation feedback op

URI http://smartsociety-project.github.io/cas/# http://www.w3.org/ns/prov# http://openprovenance.org/tmpl# http://openprovenance.org/var# <http://www.w3.org/2001/XMLSchema# http://rideshares.info http://rideshares.info/OpenRideServer-RS/ http://rideshares.info/OpenRideServerRS/view/ http://168.144.202.152:3000/ http://www.rideshareorchestrator.com/rideRequests/ http://www.rideshareorchestrator.com/ridePlans/ http://pat.ecs.soton.ac.uk/ http://pat.ecs.soton.ac.uk/application/ 1/feedback/ http://www.pat.ecs.soton.ac.uk/rs/ application/1/reputation/

Namespace Description The cas vocabulary.

Prov Provenance templates Provenance variables XSD The UI. The UI’s service.

The UI’s views.

The orchestration peer.

Ride requests.

Ride plans.

The reputation manager.

Feedback reports.

Reputation.

Table 1.1: Namespaces used in the Ride Share demonstrator.

These namespaces are used as examples in the templates and bindings, and the namespaces will need to be altered in the bindings submitted by different components and deployments so that they are correct.

1.3

Considerations for Namespaces and Prefixes

1. The URI namespace you choose for your vocabulary should be a Web address.

2. Keep prefixes short and consistent. For example, this document uses op as a prefix to http://www.pat.ecs.soton.ac.uk/rs/ application/1/reputation/ 3

for conciseness. However, in deployment we will need to op1 as a prefix to http://www.pat.ecs.soton.ac.uk/rs/application/1/reputation/, and op2 as a prefix to http://www.pat.ecs.soton.ac.uk/rs/application/2/reputation/, to denote the diďŹ&#x20AC;erent applications.

4

Chapter 2

Orchestrator 2.1

Submitting Task and Task Requests

A submission of task occurs when a task is submitted to the orchestrator.

2.1.1

Submitting Task Template

This template describes when the orchestration peer receives a ride task.

5

Figure 2.1: Template for posting ride tasks.

6

Submitting Task Template Variable var:orchestration _manager

Type cas:OrchestrationManager

var:submitted_request

cas:Task

var:task

cas:Task

var:receiving_task_request

cas:SubmittingTaskRequest

var:sending_response

cas:SendingResponse

var:acknowledgement

cas:Acknowledgement

var:acknowledgement_code

cas:Acknowledgement

var:rp_version

cas:task_version

var:rp_id

cas:task_id

var:rp_comments

cas:task_comments

var:rp_route

cas:task_route

var:rp_priceRange

cas:task_priceRange

var:rp_desDateTimeWindowHigh

cas:task_desDateTimeWindowHigh

var:rp_desDateTimeWindowLow

cas:task_desDateTimeWindowLow

var:rp_depDateTimeWindowHigh

cas:task_depDateTimeWindowHigh

7

Description A URI of the orchestrator manager’s API. For example, https://bitbucket.org/ rovatsos/smartsocietyinternal/wiki/SmartSharing/API.md The original URI of the submitted task.

For example, https://client.ss1.u.hopper.com/ ridePlans/1/v/0.0 The URI of the task stored by the orchestrator.

For example, http://client.ss1.u.hopper.com/ ridePlans/1/v/0.1 The URI of the activity that handled the submission of a task request, this URI needs to be unique for each submission.

For example, http://client.ss1.u.hopper.com/ receivingTask/1/.

The activity that sends a response from the submission of a task. For example, http://client.ss1.u.hopper.com/ sendingResponse/1/.

The acknowledgement entity that was after a sending response. For example, http://client.ss1.u.hopper.com/ acknowledgement/1/.

The status code returned by the acknowledgement. For example, 200 String representation of the version of the submitted task String representation of the request id of the submitted task String representation of the comments of the submitted task String representation of the route of the submitted task String representation of the price range of the suhbmitted task String representation of the destination’s datetime maximum value route of the task String representation of the destination’s datetime minimum value route of the task String representation of the departure’s datetime maximum value route of the task

var:rp_depDateTimeWindowLow

cas:task_depDateTimeWindowLow

String representation of the departure’s datetime minimum value route of the task var:rp_destination_location cas:task_destination_location String representation of the destination’s location var:rp_departure_location cas:task_departure_location String representation of the departure’s location var:rp_smoking cas:task_smoking String representation of the user’s smoking preference var:rp_pets cas:task_pets String representation of the user’s pet preference var:rp_currency cas:task_currency String representation of the ride’s currency var:rp_rejectedCommuters cas:task_rejectedCommuters String representation of the ride’s rejected commuters var:rp_agreedCommuters cas:task_agreedCommuters String representation of the ride’s agreed commuters var:rp_potentiallyAgreedCommuters cas:task_potentiallyAgreedCommuters String representation of the ride’s potentially agreed commuters var:rp_rejectedDriver cas:task_rejectedDrivers String representation of the ride’s rejected driver var:rp_agreedDriver cas:task_agreedDriver String representation of the ride’s agreed driver var:rp_potentiallyAgreedDriver cas:task_potentiallyAgreedDriver String representation of the ride’s potentially agreed driver var:rp_potentiallyDriver cas:task_potentiallyDriver String representation of the ride’s potential driver var:rp_commuterOpinions cas:task_commuterOpinions String representation of the commuter opinions var:rp_driverOpinions cas:task_driverOpinions String representation of the driver opinions var:rp_revision cas:task_revision String representation of the task request’s revision var:rp_index cas:task_index String representation of the task request’s index Table 2.1: Variables defined in the Submitting Task template

8

2.1.2

Submitting Task Request Template

This template describes when the orchestration peer receives a ride request.

Figure 2.2: Template for posting ride requests.

9

Submitting Task Request Template Variable Type var:orchestration_manager cas:OrchestrationManager

var:submitted_request

cas:Task

var:task_request

cas:TaskRequest

var:receiving_task_request

cas:SubmittingTaskRequest

var:sending_response

cas:SendingResponse

var:acknowledgement

cas:Acknowledgement

var:acknowledgement_code

cas:Acknowledgement

var:rr_version

cas:request_version

var:rr_id

cas:request_id

var:rr_managedBy

cas:request_manageBy

var:rr_comments

cas:request_comments

var:rr_route

cas:request_route

var:rr_priceBound

cas:request_priceBound

10

Description A URI of the orchestrator managerâ&#x20AC;&#x2122;s API. For example, https://bitbucket.org/ rovatsos/smartsocietyinternal/wiki/SmartSharing/API.md The original URI of the submitted task request.

For example, https://client.ss1.u.hopper.com/ ridePlans/1/v/0.0 The URI of the task request stored by the orchestrator.

For example, http://client.ss1.u.hopper.com/ ridePlans/1/v/0.1 The URI of the activity that handled the submission of a task request, this URI needs to be unique for each submission.

For example, http://client.ss1.u.hopper.com/ receivingTask/1/.

The activity that sends a response from the submission of a task request, this URI needs to be unique for each submission.

For example, http://client.ss1.u.hopper.com/ sendingResponse/1/.

The acknowledgement entity that was after a sending response. For example, http://client.ss1.u.hopper.com/ acknowledgement/1/.

The status code returned by the acknowledgement. For example, 200 String representation of the version of the task request. For example, 1.

String representation of the task request id. For example 1.

String representation of who the ride request is managed by. For example, owner String representation of the comments of the ride request. For example, Comments for agent with username ...

String representation of the route of the ride request. For example, Route description for agent with username.

String representation of the price bounds of the ride request. For example, 10

var:rr_desDateTimeWindowHigh

var:rr_desDateTimeWindowLow

var:rr_depDateTimeWindowHigh

var:rr_depDateTimeWindowLow

var:rr_destination_location

var:rr_departure_location

var:rr_capacity var:rr_rideQualityThreshold var:rr_smoking var:rr_pets var:rr_currency var:rr_mode var:rr_invalidRidePlans var:rr_agreedRidePlan var:rr_driverAgreedRidePlans

cas:request_desDateTimeWindowHighString representation of the destination’s datetime maximum value route of the ride request.

For example, 1423778400000 cas:request_desDateTimeWindowLow String representation of the destination’s datetime minimum value route of the ride request.

For example, 1423695600000 cas:request_depDateTimeWindowHighString representation of the departure’s datetime maximum value route of the ride request.

For example, 1423778400000 cas:request_depDateTimeWindowLowString representation of the departure’s datetime minimum value route of the ride request.

For example, 1423695600000 cas:request_destination_location String representation of the ride request’s destination location.

For example "radius":5,"lat":41.90278,"lon":12.49637 cas:request_departure_location String representation of the ride request’s departure location.

For example "radius":5,"lat":41.90278,"lon":12.49637 cas:request_capacity String representation of the capacity of the ride request. For example, 1. cas:request_rideQualityThreshold String representation of the ride request’s quality threshold. For example, 0 cas:request_smoking String representation of the smoking preference in the ride request. For example, no. cas:request_pets String representation of the pet preference in the ride request. For example, no. cas:request_currency String representation of the currency used in the ride request. For example, euro. cas:request_mode String representation of the mode of the user in the ride request. For example, driver. cas:request_invalidRidePlans String representation of the ride request’s invalidRidePlans. For example, [] cas:request_agreedRidePlan String representation of the ride request’s agreedRidePlans. For example, http://abacus.imaginary:3000/ridePlans/29. cas:request_driverAgreedRidePlans String representation of the ride request’s driver agreed ride plans. For example, [].

11

var:rr_potentialRidePlans var:rr_user var:rr_revision var:rr_index

cas:request_potentialRidePlans

String representation of the ride request’s potential ride plans.For example, []. cas:request_user String representation of user submitting the ride request. For example, agent1. cas:request_revision String representation of the ride request’s revision. For example, 3. cas:request_index String representation of the ride request’s index. For example, 101.

Table 2.2: Variables defined in the Submitting Task Request template

12

2.2

Composing Tasks

The composition of tasks occurs after the submission of a task request to the orchestrator.

2.2.1

Composing Task Template

This template describes the composition of a ride plan.

13

Figure 2.3: Template for generating compositions for ride matches.

14

Task Composition Template Variable var:composition_manager

Type cas:CompositionManager

var:task_request

cas:Task

var:task

cas:Task

var:opinion_report

cas:ReputationReport

var:opinion_request

cas:Request

var:local_opinion_report

cas:ReputationReport

var:computing_composition

cas:ComputingComposition

var:requesting_opinion

cas:RequestingOpinion

15

Description A URI of the composition managerâ&#x20AC;&#x2122;s API. For example, https://bitbucket.org/ rovatsos/smartsocietyinternal/wiki/SmartSharing/API.md A URI of a task request that was used in computing a task compositions. For example, http://client.ss1.u.hopper.com/ rideRequests/1/v/0.1.

A URI of the task that is created by computing compositions. For example, http://client.ss1.u.hopper.com/ ridePlans/1/v/0.1.

A URI of the opinion report which is returned by the reputation service, this URI is returned in the response header by the reputation service, as the anchor in the Link header. For example, https://smartshare.ecs.soton.ac.uk/rs/ response/1/.

A URI of the request used to request an opinion report. For example, http://client.ss1.u.hopper.com/ requesting_opinion/1/ A URL of an opinion report used by the composition manager, the content of the report is the same as the opinion_report sent by the reputation, however it is a diďŹ&#x20AC;erent version because the opinion_report refers to the entity stored by the reputation service.

For example, http://client.ss1.u.hopper.com/ opinionReport/1/.

The URI for the activity that computed the composition of tasks. For example, http://client.ss1.u.hopper.com/ computeComposition/1/.

The URI of the activity that requested an opinion report from the reputation service, this URI is returned in the response header by the reputation service in the Link header. For example, https://smartshare.ecs.soton.ac.uk/rs/ request/1/.

var:receiving_opinion

cas:ReceivingOpinion

var:receiving_task_request

cas:SubmittingTaskRequest

var:rp_version

cas:task_version

var:rp_id

cas:task_id

var:rp_comments

cas:task_comments

var:rp_route

cas:task_route

var:rp_priceRange

cas:task_priceRange

var:rp_desDateTimeWindowHigh

cas:task_desDateTimeWindowHigh

var:rp_desDateTimeWindowLow

cas:task_desDateTimeWindowLow

var:rp_depDateTimeWindowHigh

cas:task_depDateTimeWindowHigh

var:rp_depDateTimeWindowLow

cas:task_depDateTimeWindowLow

var:rp_destination_location

cas:task_destination_location

var:rp_departure_location

cas:task_departure_location

var:rp_smoking

cas:task_smoking

var:rp_pets

cas:task_pets

var:rp_currency

cas:task_currency

16

The URI of the activity that received an opinion report from the reputation service.

For example, http://orchestrator/receiving_opinion/1/ The URI of the activity that handled the submission of a task request, this URI needs to be unique for each submission.

For example, http://client.ss1.u.hopper.com/ receivingTask/1/.

String representation of the version of the task plan. For example, 1.

String representation of the task plan id. For example 1.

String representation of the comments of the ride plan. For example, Comments for agent with username ...

String representation of the route of the ride plan. For example, Route description for agent with username.

String representation of the price range of the ride plan. For example, 10-20 String representation of the destination’s datetime maximum value route of the ride plan.

For example, 1423778400000 String representation of the destination’s datetime minimum value route of the ride plan.

For example, 1423695600000 String representation of the departure’s datetime maximum value route of the ride plan. For example, 1423778400000 String representation of the departure’s datetime minimum value route of the ride plan. For example, 1423695600000 String representation of the ride plan’s destination location. For example "radius":5,"lat":41.90278,"lon":12.49637 String representation of the ride plan’s departure location. For example "radius":5,"lat":41.90278,"lon":12.49637 String representation of the smoking preference in the ride plan. For example, no.

String representation of the pet preference in the ride plan. For example, no.

String representation of the currency used in the ride plan. For example, euro.

var:rp_rejectedCommuters

cas:task_rejectedCommuters

String representation of the ride’s rejected commuters, For example, [] var:rp_agreedCommuters cas:task_agreedCommuters String representation of the ride’s agreed commuters. For example, [] var:rp_potentiallyAgreedCommuters cas:task_potentiallyAgreedCommutersString representation of the ride’s potentially agreed commuters. For example, []. var:rp_rejectedDriver cas:task_rejectedDrivers String representation of the ride’s rejected driver. For example, agent1. var:rp_agreedDriver cas:task_agreedDriver String representation of the ride’s agreed driver. For example, agent1, var:rp_potentiallyAgreedDriver cas:task_potentiallyAgreedDriver String representation of the ride’s potentially agreed driver. For example, None. var:rp_potentiallyDriver cas:task_potentiallyDriver String representation of the ride’s potential driver. For example, agent1 var:rp_commuterOpinions cas:task_commuterOpinions String representation of the commuter opinions.

For example, [http://abacus.imaginary:3000/users/ agent2/opinionsCommuterDrivers/agent1] var:rp_driverOpinions cas:task_driverOpinions String representation of the driver opinions.

For example, ["http://abacus.imaginary:3000/users/ agent1/opinionsDriverCommuters/agent2"] var:rp_revision cas:task_revision String representation of the task request’s revision. For example, 2. var:rp_index cas:task_index String representation of the task request’s index. For example, 29.

Table 2.3: Variables defined in the Task Composition template

17

2.2.2

Composing Task Template without Opinions

This template describes the generation of ride plans without the use of opinions.

Figure 2.4: Template for generating compositions for ride matches.

18

Task Composition Template without Opinions Variable Type var:composition_manager cas:CompositionManager

var:task_request

cas:Task

var:task

cas:Task

var:receiving_task_request

cas:SubmittingTaskRequest

var:rp_version

cas:task_version

var:rp_id

cas:task_id

var:rp_comments

cas:task_comments

var:rp_route

cas:task_route

var:rp_priceRange

cas:task_priceRange

var:rp_desDateTimeWindowHigh

cas:task_desDateTimeWindowHigh

var:rp_desDateTimeWindowLow

cas:task_desDateTimeWindowLow

var:rp_depDateTimeWindowHigh

cas:task_depDateTimeWindowHigh

var:rp_depDateTimeWindowLow

cas:task_depDateTimeWindowLow

var:rp_destination_location

cas:task_destination_location

19

Description A URI of the composition manager’s API. For example, https://bitbucket.org/ rovatsos/smartsocietyinternal/wiki/SmartSharing/API.md A URI of a task request that was used in computing a task compositions. For example, http://client.ss1.u.hopper.com/ rideRequests/1/v/0.1.

A URI of the task that is created by computing compositions. For example, http://client.ss1.u.hopper.com/ ridePlans/1/v/0.1.

The URI of the activity that handled the submission of a task request, this URI needs to be unique for each submission.

For example, http://client.ss1.u.hopper.com/ receivingTask/1/.

String representation of the version of the task plan. For example, 1.

String representation of the task plan id. For example 1.

String representation of the comments of the ride plan. For example, Comments for agent with username ...

String representation of the route of the ride plan. For example, Route description for agent with username.

String representation of the price range of the ride plan. For example, 10-20 String representation of the destination’s datetime maximum value route of the ride plan.

For example, 1423778400000 String representation of the destination’s datetime minimum value route of the ride plan.

For example, 1423695600000 String representation of the departure’s datetime maximum value route of the ride plan. For example, 1423778400000 String representation of the departure’s datetime minimum value route of the ride plan. For example, 1423695600000 String representation of the ride plan’s destination location. For example "radius":5,"lat":41.90278,"lon":12.49637

var:rp_departure_location

cas:task_departure_location

String representation of the ride plan’s departure location. For example "radius":5,"lat":41.90278,"lon":12.49637 var:rp_smoking cas:task_smoking String representation of the smoking preference in the ride plan. For example, no. var:rp_pets cas:task_pets String representation of the pet preference in the ride plan. For example, no. var:rp_currency cas:task_currency String representation of the currency used in the ride plan. For example, euro. var:rp_rejectedCommuters cas:task_rejectedCommuters String representation of the ride’s rejected commuters, For example, [] var:rp_agreedCommuters cas:task_agreedCommuters String representation of the ride’s agreed commuters. For example, [] var:rp_potentiallyAgreedCommuters cas:task_potentiallyAgreedCommutersString representation of the ride’s potentially agreed commuters. For example, []. var:rp_rejectedDriver cas:task_rejectedDrivers String representation of the ride’s rejected driver. For example, agent1. var:rp_agreedDriver cas:task_agreedDriver String representation of the ride’s agreed driver. For example, agent1. var:rp_potentiallyAgreedDriver cas:task_potentiallyAgreedDriver String representation of the ride’s potentially agreed driver. For example, None. var:rp_potentiallyDriver cas:task_potentiallyDriver String representation of the ride’s potential driver. For example, agent1 var:rp_commuterOpinions cas:task_commuterOpinions String representation of the commuter opinions.

For example, [http://abacus.imaginary:3000/users/ agent2/opinionsCommuterDrivers/agent1] var:rp_driverOpinions cas:task_driverOpinions String representation of the driver opinions.

For example, ["http://abacus.imaginary:3000/users/ agent1/opinionsDriverCommuters/agent2"] var:rp_revision cas:task_revision String representation of the task request’s revision. For example, 2. var:rp_index cas:task_index String representation of the task request’s index. For example, 29.

Table 2.4: Variables defined in the Task Composition template

20

2.3

Task Negotiation

The submission of a task negotiation occurs when the negotiation manager receives a task negotiation.

2.3.1

Task Negotiation Template

This template describes the generation of ride plans after a user posts a negotiation oďŹ&#x20AC;er about a ride plan.

21

var:task specializationOf

var:old_task

prov:label cas:Task prov:type cas:Task

specializationOf

prov:label cas:Task prov:type cas:Task

specializationOf

var:negotiation_manager

wasDerivedFrom

var:task_negotiation

used

prov:label cas:NegotiationManager prov:type cas:NegotiationManager

wasAttributedTo

prov:label cas:Task prov:type cas:Task wasDerivedFrom

prov:type prov:Revision

wasDerivedFrom

var:new_task

prov:label prov:type cas:task_agreedCommuters cas:task_agreedDriver cas:task_comments cas:task_commuterOpinions cas:task_commuters cas:task_currency cas:task_depDateTimeWindowHigh cas:task_depDateTimeWindowLow cas:task_departure cas:task_desDateTimeWindowHigh cas:task_desDateTimeWindowLow cas:task_destination_location cas:task_driver cas:task_driverOpinions cas:task_id cas:task_index cas:task_pets cas:task_potentialCommuters cas:task_potentialDriver cas:task_potentiallyAgreedCommuters cas:task_potentiallyAgreedDriver cas:task_priceRange cas:task_rejectedCommuters cas:task_rejectedDriver cas:task_revision cas:task_route cas:task_smoking cas:task_version

used

wasAssociatedWith

vargen:computing_negotiation wasGeneratedBy

var:receiving_task

cas:Task cas:Task var:rp_agreedCommuters var:rp_agreedDriver var:rp_comments var:rp_commuterOpinions var:rp_commuters var:rp_currency var:rp_depDateTimeWindowHigh var:rp_depDateTimeWindowLow var:rp_departure var:rp_desDateTimeWindowHigh var:rp_desDateTimeWindowHighLow var:rp_destination var:rp_driver var:rp_driverOpinions var:rp_id var:rp_index var:rp_pets var:rp_potentialCommuters var:rp_potentialDriver var:rp_potentiallyAgreedCommuters var:rp_potentiallyAgreedDriver var:rp_priceRange var:rp_rejectedCommuters var:rp_rejectedDriver var:rp_revision var:rp_route var:rp_smoking var:rp_version

wasInformedBy

prov:label prov:type tmpl:endTime tmpl:startTime

cas:ComputingNegotiation cas:ComputingNegotiation var:computing_negotiation_end var:computing_negotiation_start

prov:label cas:ReceivingTask prov:type cas:ReceivingTask

vargen:b

Figure 2.5: Template for generating compositions for ride matches after a negotiation oďŹ&#x20AC;er.

22

Task Negotiation Template Variable var:negotiation_manager

Type cas:NegotiationManager

vargen:computing_negotiation

cas:ComputingNegotiaton

var:task

cas:Task

var:new_task

cas:Task

var:old_task

cas:Task

var:task_negotiation

cas:Task

var:receiving_task

cas:ReceivingTask

var:rp_version

cas:task_version

var:rp_id

cas:task_id

var:rp_comments

cas:task_comments

var:rp_route

cas:task_route

var:rp_priceRange

cas:task_priceRange

23

Description A URI of the negotiation managerâ&#x20AC;&#x2122;s API. For example, https://bitbucket.org/ rovatsos/smartsocietyinternal/wiki/SmartSharing/API.md The URI for the activity that computed the task after the submission of a negotiation task. For example, http://client.ss1.u.hopper.com/ computingNegotiaton/1/.

A URI of a task first version and revision of the task generated by the composition manger.

For example, https://client.ss1.u.hopper.com/ ridePlan/1/v/0.0 .

A URI of a task that was generated by the computing negotiation activity.

For example, https://client.ss1.u.hopper.com/ ridePlan/1/v/0.3 .

A URI of a previous version of the task stored by the negotiation manager.

For example, https://client.ss1.u.hopper.com/ ridePlan/1/v/0.1 .

A URI of the task that was submitted by the user during negotiation, it will have the same URI as the task variable in the template in Section 2.1.1. For example, https://client.ss1.u.hopper.com/ ridePlan/1/v/0.2 .

The activity that handled the submission of a task request.

String representation of the version of the task plan. For example, 1.

String representation of the task plan id. For example 1.

String representation of the comments of the ride plan. For example, Comments for agent with username ...

String representation of the route of the ride plan. For example, Route description for agent with username.

String representation of the price range of the ride plan. For example, 10-20

var:rp_desDateTimeWindowHigh

cas:task_desDateTimeWindowHigh

String representation of the destination’s datetime maximum value route of the ride plan.

For example, 1423778400000 var:rp_desDateTimeWindowLow cas:task_desDateTimeWindowLow String representation of the destination’s datetime minimum value route of the ride plan.

For example, 1423695600000 var:rp_depDateTimeWindowHigh cas:task_depDateTimeWindowHigh String representation of the departure’s datetime maximum value route of the ride plan. For example, 1423778400000 var:rp_depDateTimeWindowLow cas:task_depDateTimeWindowLow String representation of the departure’s datetime minimum value route of the ride plan. For example, 1423695600000 var:rp_destination_location cas:task_destination_location String representation of the ride plan’s destination location. For example "radius":5,"lat":41.90278,"lon":12.49637 var:rp_departure_location cas:task_departure_location String representation of the ride plan’s departure location. For example "radius":5,"lat":41.90278,"lon":12.49637 var:rp_smoking cas:task_smoking String representation of the smoking preference in the ride plan. For example, no. var:rp_pets cas:task_pets String representation of the pet preference in the ride plan. For example, no. var:rp_currency cas:task_currency String representation of the currency used in the ride plan. For example, euro. var:rp_rejectedCommuters cas:task_rejectedCommuters String representation of the ride’s rejected commuters, For example, [] var:rp_agreedCommuters cas:task_agreedCommuters String representation of the ride’s agreed commuters. For example, [] var:rp_potentiallyAgreedCommuters cas:task_potentiallyAgreedCommutersString representation of the ride’s potentially agreed commuters. For example, []. var:rp_rejectedDriver cas:task_rejectedDrivers String representation of the ride’s rejected driver. For example, agent1. var:rp_agreedDriver cas:task_agreedDriver String representation of the ride’s agreed driver. For example, agent1, var:rp_potentiallyAgreedDriver cas:task_potentiallyAgreedDriver String representation of the ride’s potentially agreed driver. For example, None. var:rp_potentiallyDriver cas:task_potentiallyDriver String representation of the ride’s potential driver. For example, agent1 var:rp_commuterOpinions cas:task_commuterOpinions String representation of the commuter opinions.

For example, [http://abacus.imaginary:3000/users/ agent2/opinionsCommuterDrivers/agent1]

24

var:rp_driverOpinions

var:rp_revision var:rp_index

cas:task_driverOpinions

String representation of the driver opinions.

For example, ["http://abacus.imaginary:3000/users/ agent1/opinionsDriverCommuters/agent2"] cas:task_revision String representation of the task requestâ&#x20AC;&#x2122;s revision. For example, 2. cas:task_index String representation of the task requestâ&#x20AC;&#x2122;s index. For example, 29.

Table 2.5: Variables defined in the Task Negotiation template

25

Ride Share Templates and Example Bindings

April 14, 2015

Contents 1 Templates and Bindings 1.1 Basic Template and Binding Example . . .

1.1.1 Template . . . . . . . . . . . . . . .

1.1.2 Binding . . . . . . . . . . . . . . . .

1.2 Namespaces . . . . . . . . . . . . . . . . . .

1.3 Considerations for Namespaces and Prefixes

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2 2 2 2 3 4

2 User Interface 2.1 View Initialisation . . . . . . . . . . . . . . . . . . .

2.1.1 View Initialisation Template . . . . . . . . .

2.1.2 View Initialisation Binding Example . . . . .

2.1.3 cURL Example . . . . . . . . . . . . . . . . .

2.2 Changing View . . . . . . . . . . . . . . . . . . . . .

2.2.1 Changing View Template . . . . . . . . . . .

2.2.2 Changing View Binding Example . . . . . . .

2.2.3 cURL Example . . . . . . . . . . . . . . . . .

2.3 Submitting Request . . . . . . . . . . . . . . . . . .

2.3.1 Submitting Request Template . . . . . . . . .

2.3.2 Submitting Request Binding Example . . . .

2.3.3 cURL Example . . . . . . . . . . . . . . . . .

2.4 View Derivation . . . . . . . . . . . . . . . . . . . .

2.4.1 View Derivation Template . . . . . . . . . . .

2.4.2 Changing View Derivation Binding Example 2.4.3 cURL Example . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

5 5 5 6 7 8 8 9 9 11 11 11 13 14 14 15 15

1

. . . . .

. . . . .

. . . . .

. . . . .

Chapter 1

Templates and Bindings This Chapter introduces how to use PROV Template1 for Ride Sharing scenarios.

1.1

Basic Template and Binding Example

1.1.1

Template

The following template contains two var:composition_manager and var:task, the template is written in the provn format. document prefix ex <http://example.org/> prefix var <http://openprovenance.org/var#> bundle ex:b agent(var:composition_manager) entity(var:task) wasAttributedTo(var:task, var:composition_manager) endBundle endDocument

1.1.2

Binding

The following provenance binding defines variables for var:composition_manager and var:task. The binding is written in turtle2 which will be the format used to submit bindings for ride share. @prefix @prefix @prefix @prefix @prefix @prefix

prov: <http://www.w3.org/ns/prov#> . orchestrator: <http://www.rideshare-orchestrator.com/> . rp: <http://www.rideshare-orchestrator.com/ridePlans/> . tmpl: <http://openprovenance.org/tmpl#> . var: <http://openprovenance.org/var#> . xsd: <http://www.w3.org/2001/XMLSchema#> .

var:composition_manager a prov:Entity ; 1 PROV 2 Turtle

Template: https://provenance.ecs.soton.ac.uk/prov-template/#namespaces http://www.w3.org/TR/turtle/

2

tmpl:value_0 orchestrator:comp . var:task a prov:Entity ; tmpl:value_0 rp:203 ; tmpl:value_1 rp:122 .

The black text will remain the same for all bindings for the example template. The dark red text refers to the namespaces introduced in the bindings which are not present in the template. Specifically, @prefix orchestrator: <http://www.rideshare-orchestrator.com/> . @prefix rp: <http://www.rideshare-orchestrator.com/ridePlans/> .. The namespace’s prefixes are used before the variables. The blue text are the values assigned to the variables defined in the template, comp is assigned to var:composition_manager where the namespace is orchestrator, and 122 and 203 is assigned to var:task where the namespace is rp. It is worth noting that it you can create more than on instance of a variable, which is indicated with green font. This may occur when an activity produces more than one entity, for example a composition activity might generate two plans.

1.2

Namespaces

The namespaces presented in Table 1.1 are used in this document: Prefix cas prov tmpl var xsd rideserver rideservice view orchestrator rr rp reputation feedback op

URI http://smartsociety-project.github.io/cas/# http://www.w3.org/ns/prov# http://openprovenance.org/tmpl# http://openprovenance.org/var# <http://www.w3.org/2001/XMLSchema# http://rideshares.info http://rideshares.info/OpenRideServer-RS/ http://rideshares.info/OpenRideServerRS/view/ http://168.144.202.152:3000/ http://www.rideshareorchestrator.com/rideRequests/ http://www.rideshareorchestrator.com/ridePlans/ https://smartshare.ecs.soton.ac.uk/ https://smartshare.ecs.soton.ac.uk/application/ 1/feedback/ https://smartshare.ecs.soton.ac.uk/rs/ application/1/reputation/

Namespace Description The cas vocabulary.

Prov Provenance templates Provenance variables XSD The UI. The UI’s service.

The UI’s views.

The orchestration peer.

Ride requests.

Ride plans.

The reputation manager.

Feedback reports.

Reputation.

Table 1.1: Namespaces used in the Ride Share demonstrator.

These namespaces are used as examples in the templates and bindings, and the namespaces will need to be altered in the bindings submitted by different components and deployments so that they are correct.

3

1.3

Considerations for Namespaces and Prefixes

1. The URI namespace you choose for your vocabulary should be a fully formed URI. 2. Keep prefixes short and consistent.

For example, this document uses op as a prefix to https://smartshare.ecs.soton.ac.uk/rs/ application/1/reputation/ for conciseness.

However, in deployment we will need to op1 as a prefix to http://smartshare.ecs.soton.ac.uk/rs/application/1/reputation/, and op2 as a prefix to https://smartshare.soton.ac.uk/rs/ application/2/reputation/, to denote the different applications.

4

Chapter 2

User Interface The following scenarios three scenarios are to be recorded by provenance: (1) when a view is changed, (2) when a request is submitted, and (3) when a view is changed and it displays the response of a request.

2.1

View Initialisation

2.1.1

View Initialisation Template

Template shown in Figure 2.1, is a visual representation of the provenance data captured, and Table 2.1 describes the variables used in the template.

View Initialisation Template, see Figure Variable Type var:ui cas:UserInterface var:initialising_view cas:ChangingView var:view

cas:View

2.1 Description A URI for the UI. The activity that initialised the view in the UI. A URI of the first view.

Table 2.1: Variables defined in the View Initialisation template

5

Figure 2.1: Template for the initialisation of the UI.

2.1.2

View Initialisation Binding Example

The following binding example describes the bindings for the variables in the Change View template in rdf turtle. The variable bindings are described in Table 2.2. @prefix @prefix @prefix @prefix @prefix @prefix @prefix

prov: <http://www.w3.org/ns/prov#> . rideserver: <http://rideshares.info/> . rideservice: <http://rideshares.info/OpenRideServer-RS/> . view: <http://rideshares.info/OpenRideServer-RS/view/> . tmpl: <http://openprovenance.org/tmpl#> . var: <http://openprovenance.org/var#> . xsd: <http://www.w3.org/2001/XMLSchema#> .

var:view a prov:Entity ; tmpl:value_0 view:view-1 . var:ui a prov:Entity ; tmpl:value_0 rideserver:ors-1 . var:initialising_view a prov:Entity ; tmpl:value_0 view:viewingHomePage-211 . var:initialising_view_start_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime .

6

var:initialising_view_end_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime .

View Initialisation Bindings Variable var:ui var:view var:initialising_view var:initialising_view_start_time var:initialising_view_end_time

Type rideserver:ors-1 view:view-1 view:viewingHomePage-211 “2014-01-01T09:21:00+02:00” “2014-01-01T09:21:00+02:00”

Table 2.2: Table describing the variables for the change view template

2.1.3

cURL Example

The following cURL statement submits the above binding example to the PROV binding service1 . curl -X POST ‘https://smartshare.ecs.soton.ac.uk/provbindings/application /1/template/change_view/change_view_binding_1/’ --data ’ @prefix prov: < http://www.w3.org/ns/prov#> . @prefix rideserver: <http://rideshares.info /> . @prefix rideservice: <http://rideshares.info/OpenRideServer-RS/> . @prefix view: <http://rideshares.info/OpenRideServer-RS/view/> . @prefix op: <https://smartshare.ecs.soton.ac.uk/rs/application/1/reputation/> . @prefix tmpl: <http://openprovenance.org/tmpl#> .@prefix var: <http:// openprovenance.org/var#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema #> . var:view a prov:Entity ; tmpl:value_0 view:view-1. var:ui a prov: Entity ; tmpl:value_0 rideserver:ors-1 . var:initialising_view_end_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime . var:initialising_view a prov:Entity ; tmpl:value_0 view: viewingHomePage-211 . var:initialising_view_end_time a prov:Entity ; tmpl :2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime .’ --header " Content-Type: text/turtle" -i

1 PROV binding provbindings/

service

https://provenance.ecs.soton.ac.uk/smartsociety/

7

2.2

Changing View

2.2.1

Changing View Template

Template shown in Figure 2.2, is a visual representation of the provenance data captured, and Table 2.3 describes the variables used in the template.

ui

att

view

type: http://smartsociety-project.github.io/cas/#Peer

spe

att

previous_view

type: http://smartsociety-project.github.io/cas/#View

use assoc

type: http://smartsociety-project.github.io/cas/#View

changing_view

att spe der

new_view

gen

type: startTime: endTime:

http://smartsociety-project.github.io/cas/#ChangingView changing_view_start_time changing_view_end_time

type: http://smartsociety-project.github.io/cas/#View

b

Figure 2.2: Template for changing the view on the UI. Change View Template, see Figure 2.2 Variable Type var:ui cas:UserInterface var:changing_view cas:ChangingView var:view

cas:View

var:new_view var:previous_view

cas:View cas:View

Description The UI. The activity that changed the view in the UI. A single general resource for views in a UI. It is used to connect all versions of a resource in the provenance.

The new view.

The previous view.

Table 2.3: Variables defined in the Change View template

8

2.2.2

Changing View Binding Example

The following binding example describes the bindings for the variables in the Change View template in rdf turtle. The variable bindings are described in Table 2.4. @prefix @prefix @prefix @prefix @prefix @prefix @prefix

prov: <http://www.w3.org/ns/prov#> . rideserver: <http://rideshares.info/> . rideservice: <http://rideshares.info/OpenRideServer-RS/> . view: <http://rideshares.info/OpenRideServer-RS/view/> . tmpl: <http://openprovenance.org/tmpl#> . var: <http://openprovenance.org/var#> . xsd: <http://www.w3.org/2001/XMLSchema#> .

var:view a prov:Entity ; tmpl:value_0 view:view-1 . var:new_view a prov:Entity ; tmpl:value_0 view:selectRide_103 . var:previous_view a prov:Entity ; tmpl:value_0 view:reputation_109 . var:ui a prov:Entity ; tmpl:value_0 rideserver:ors-1 . var:changing_view_start_end_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime . var:changing_view a prov:Entity ; tmpl:value_0 view:viewingReputation-211 . var:changing_view_start_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime .

Change View Bindings Variable var:ui var:view var:new_view var:previous_view var:changing_view var:changing_view_start_end_time var:changing_view_start_time

Type rideserver:ors-1 view:view-1 view:selectRide-103 view:reputation-109 view:activeOffersView-211 “2014-01-01T09:21:00+02:00” ˆˆxsd:dateTime “2014-01-01T09:21:00+02:00” ˆˆxsd:dateTime

Table 2.4: Table describing the variables for the change view template

2.2.3

cURL Example

The following cURL statement submits the above binding example to the PROV binding service2 .

2 PROV binding provbindings/

service

https://provenance.ecs.soton.ac.uk/smartsociety/

9

curl -X POST ‘https://smartshare.ecs.soton.ac.uk/provbindings/application /1/template/change_view/change_view_binding_1/’ --data ’ @prefix prov: < http://www.w3.org/ns/prov#> . @prefix rideserver: <http://rideshares.info /> . @prefix rideservice: <http://rideshares.info/OpenRideServer-RS/> . @prefix view: <http://rideshares.info/OpenRideServer-RS/view/> . @prefix op: <https://smartshare.ecs.soton.ac.uk/rs/application/1/reputation/> . @prefix tmpl: <http://openprovenance.org/tmpl#> .@prefix var: <http:// openprovenance.org/var#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema #> . var:view a prov:Entity ; tmpl:value_0 view:view-1 . var:new_view a prov:Entity ; tmpl:value_0 view:selectRide_103 . var:previous_view a prov :Entity ; tmpl:value_0 view:reputation-109 . var:ui a prov:Entity ; tmpl: value_0 rideserver:ors-1 . var:changing_view_end_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime . var: changing_view a prov:Entity ; tmpl:value_0 view:activeOffersView-211 . var:changing_view_start_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01 T09:21:00+02:00"^^xsd:dateTime .’ --header "Content-Type: text/turtle" -i

10

2.3

Submitting Request

2.3.1

Submitting Request Template

Template shown in Figure 2.2, is a visual representation of the provenance template, and Table 2.5 describes the variables used in it.

ui

att

view

type: http://smartsociety-project.github.io/cas/#Peer

assoc use

sending_request

type: http://smartsociety-project.github.io/cas/#View

inf

request

att gen

type: startTime: endTime:

http://smartsociety-project.github.io/cas/#SendingRequest sending_request_start_time sending_request_end_time

assoc

receiving_response

der

type: http://smartsociety-project.github.io/cas/#Request

gen

response

type: startTime: endTime:

http://smartsociety-project.github.io/cas/#RecievingRequest receiving_response_start_time receiving_response_end_time

type: http://smartsociety-project.github.io/cas/#Response

b

Figure 2.3: Template for the submission of data via the UI. It is used when a user performs an action that results in a request or the submission of data via the UI. Submitting Request Template Variable Type var:ui cas:UserInterface var:request cas:Request var:response cas:Response vargen:sendingRequest cas:sendingRequest vargen:receivingResponse cas:receivingResponse var:view

cas:View

Description The User Interface.

The request that was sent via the UI. The response to the request.

The activity that submitted a request.

The activity that receives the requestâ&#x20AC;&#x2122;s response.

The view that the sending_request is associated with.

Table 2.5: Variables defined in the the Submitting Request template

2.3.2

Submitting Request Binding Example

The following binding example describes the bindings for the variables in the Change View template in rdf turtle. The variable bindings are described in 11

Table 2.6. @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix

prov: <http://www.w3.org/ns/prov#> . rideserver: <http://rideshares.info/> . rideservice: <http://rideshares.info/OpenRideServer-RS/> . view: <http://rideshares.info/OpenRideServer-RS/view/> . orchestrator: <http://www.rideshare-orchestrator.com/> . tmpl: <http://openprovenance.org/tmpl#> . var: <http://openprovenance.org/var#> . op: <https://smartshare.ecs.soton.ac.uk/rs/application/1/reputation/> . xsd: <http://www.w3.org/2001/XMLSchema#> .

var:view a prov:Entity ; tmpl:value_0 view:activeOffers-9 . var:response a prov:Entity ; tmpl:value_0 op:response-8 . var:request a prov:Entity ; tmpl:value_0 rideserver:1 . var:ui a prov:Entity ; tmpl:value_0 rideserver:ors-1 . var:sending_request a prov:Entity ; tmpl:value_0 orchestrator:requestingOpinion-112 . var:sending_request_end_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime . var:changing_view a prov:Entity ; tmpl:value_0 view:viewingReputation-125 . var:sending_request_start_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime . var:identity a prov:Entity ; tmpl:value_0 rideservice:id-11 .

Submitting Request Bindings Variable var:view var:response var:request var:ui var:sending_request var:sending_request_end_time var:changing_view var:sending_request_start_time

Type view:activeOffers-9 op:response-8 rideserver:1 rideserver:ors-1 orchestrator:requestingOpinion-112 “2014-01-01T09:21:00+02:00”^^xsd:dateTime view:reputationView-125 “2014-01-01T09:21:00+02:00”^^xsd:dateTime

Table 2.6: Table describing the variables for the Submitting Request template.

12

2.3.3

cURL Example

The following cURL statement submits the above binding example to the PROV binding service3 . curl -X POST ’https://smartshare.ecs.soton.ac.uk/provbindings/application /1/template/submit_request/submit_request_binding_1’ --data ’ @prefix prov: <http://www.w3.org/ns/prov#> . @prefix rideserver: <http:// rideshares.info/> . @prefix rideservice: <http://rideshares.info/ OpenRideServer-RS/> . @prefix view: <http://rideshares.info/ OpenRideServer-RS/view/> . @prefix orchestrator: <http://www.rideshareorchestrator.com/> . @prefix tmpl: <http://openprovenance.org/tmpl#> . @prefix var: <http://openprovenance.org/var#> . @prefix op: <https:// smartshare.ecs.soton.ac.uk/rs/application/1/reputation/> . @prefix xsd: < http://www.w3.org/2001/XMLSchema#> . var:view a prov:Entity ; tmpl: value_0 view:activeOffers-9 . var:response a prov:Entity ; tmpl:value_0 op:response-8 . var:request a prov:Entity ; tmpl:value_0 rideserver:1 . var:ui a prov:Entity ; tmpl:value_0 rideserver:ors-1 . var: sending_request a prov:Entity ; tmpl:value_0 orchestrator: requestingOpinion-112 . var:sending_request_end_time a prov:Entity ; tmpl :2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime . var: changing_view a prov:Entity ; tmpl:value_0 view:viewingReputation-125 . var:sending_request_start_time a prov:Entity ; tmpl:2dvalue_0_0 "2014-01-01T09:21:00+02:00"^^xsd:dateTime . var:identity a prov:Entity ; tmpl:value_0 rideservice:id-11 .’ --header "Content-Type: text/turtle" -i

3 PROV

binding service https://smartshare.ecs.soton.ac.uk/provbindings/

13

2.4

View Derivation

A view derivation occurs when view is derived from information from a request.

2.4.1

View Derivation Template

Template shown in Figure 2.4, is a visual representation of the provenance data captured, and Table 2.7 describes the variables used in the template.

response der

view

type: cas:Response

type: cas:View

b

Figure 2.4: Template for changing the UIâ&#x20AC;&#x2122;s view.

Change View Derivation Template Variable Type Description var:view cas:View A single general resource for views in a UI. It is used to connect all versions of a resource in the provenance. var:response cas:Response The response of a request.

Table 2.7: Variables defined in the Change View Derivation template

14

2.4.2

Changing View Derivation Binding Example

The following binding example describes the bindings for the variables in the Change View template in rdf turtle. The variable bindings are described in Table 2.8. @prefix @prefix @prefix @prefix @prefix @prefix

prov: <http://www.w3.org/ns/prov#> . view: <http://rideshares.info/OpenRideServer-RS/view/> . op: <https://smartshare.ecs.soton.ac.uk/rs/application/1/reputation/> . tmpl: <http://openprovenance.org/tmpl#> . var: <http://openprovenance.org/var#> . xsd: <http://www.w3.org/2001/XMLSchema#> .

var:view a prov:Entity ; tmpl:value_0 view:reputation_109 . var:response a prov:Entity ; tmpl:value_0 op:response-8 .

Changing View Derivation Bindings Variable Type var:view view:reputation-109 var:response op:19 Table 2.8: Table describing the variables for the View Derivation template.

2.4.3

cURL Example

The following cURL statement submits the above binding example to the PROV binding service4 . curl -X POST ’https://smartshare.ecs.soton.ac.uk/provbindings/application /1/template/view_derivation/view_derivation_binding_1/’ --data ’ @prefix prov: <http://www.w3.org/ns/prov#> . @prefix view: <http://rideshares. info/OpenRideServer-RS/view/> . @prefix op: <https://smartshare.ecs.soton .ac.uk/rs/application/1/reputation/> . @prefix tmpl: <http:// openprovenance.org/tmpl#> . @prefix var: <http://openprovenance.org/var#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . var:view a prov: Entity ; tmpl:value_0 view:reputation_109 . var:response a prov:Entity ; tmpl:value_0 op:response-8 .’ --header "Content-Type: text/turtle" -i

4 PROV

binding service https://smartshare.ecs.soton.ac.uk/provbindings/

15

c SmartSociety Consortium 2013-2017

C

Deliverable D2.4

Generating Narratives from Provenance Chains

84 of 105

http://www.smart-society-project.eu

Generating Narratives from Provenance Relationship Chains Heather S. Packer

University of Southampton B32 University Road Southampton, Hampshire, UK

hp3@ecs.soton.ac.uk

ABSTRACT Provenance data is a rich data structured source that has a similar role to narratives, since they can both provide an account of connected events. Consuming prov data can be hard for both technical and non-technical users, because of its potential scale and the complexity of the relationships captured. Explicitly, it can be hard for users to follow and understand the chain of relationships connecting elements together. In this paper, we present an approach that generates narratives explaining chains of relationships and describe its nature with examples from a Ride Share application.

Categories and Subject Descriptors H.4 [Information Systems Applications]: Miscellaneous

General Terms Design,Human Factors, Theory

Keywords Narrative Generation, Provenance, Relationship Chains

1.

INTRODUCTION

The provenance standard (prov) [13] can be used to capture information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness.

Provenance implies a partial ordering between events and the entities it describes. The prov elements typically follow a link data approach, where the elements identifier is a fully formed resolvable URI. The level of detail that provenance can captured makes provenance data very rich, which can support accountability for both users and systems. However, the more detail included in the provenance data, the harder it is for both technical and non-technical users to read. This difficulty increases with the scale of the provenance documents and complexity of the relationships captured. While the relationships between elements are explicitly defined, it

Luc Moreau

University of Southampton B32 University Road Southampton, Hampshire, UK

L.Moreau@ecs.soton.ac.uk can be hard for users to follow and understand the chain of relationships connecting one element to another. The provenance standard recommends offers provenance notation (provn) for human consumption [13]. While provn is more readable than other languages used to express prov, we posit that a narrative better serves this function because they are an effective way to communicate information to humans [9, 6, 10].

Our aim is to enable users to follow and understand the chain of relationships connecting two elements, through narrative. In our approach, we: First transform the provenance data into a weighted graph and use Dijkstraâ&#x20AC;&#x2122;s algorithm to find the shortest path between two prov elements. Using a weighted graph enables us to use different weightings for different relationships, and thus we can prioritise describing relationships in the narrative that are more informative.

For example, a document is attributed to an agent, that document was generated by an activity, and that activity was associated with the agent. When the weightings all have a value of 1 the shortest path between the document and the agent is through the attribution relationship, when the attribution relationship has a value of 3 and the others have a value of 1 then the shortest path describes the documentâ&#x20AC;&#x2122;s generation and association relationships. The additional relationships in the latter example provides details about which activity generated the document. There is however a trade-off between using less and more descriptive paths to generate narratives, concretely the greater number of relationships the longer the narrative will be, which could be excessive especially with long relationship chains; Second, use the relationships that connect two prov elements to construct a narrative using a sentence generator.

The sentence generator randomly selects a string of words from a predefined list, to describe the elements and connecting relationships. In this paper, we use a provenance data recorded from a ride share application to provide examples of narratives generated with our approach.

We describe related work in Section 2, which introduces provenance and narrative summarisation. Following that, in Section 3 we detail the algorithm we use to identify the shortest path between nodes and how we generate sentences using the chain of relationships. We then describe in Section 4 the ride sharing scenario and provenance data, and discuss some queries and their resulting sentences. Finally, we make our conclusions and explore future work in Section 6.

2. BACKGROUND 2.1 Provenance

discourse on an interest topic to a user.

Provenance has varied emerging applications: it may be used to make social computations accountable and transparent [19, 15]; provenance can help determine whether data or users can be trusted [4]; and provenance can be used to ensure reproducibility [11] of computations. prov is a recent set of recommendations of the W3C for representing provenance on the web. prov is a conceptual data model (PROV-DM [13]), which can be mapped and serialized to different technologies. There is an OWL2 ontology for prov (PROV-O [7]), allowing mapping to RDF, an XML schema for provenance [3], and a textual representation for prov (PROV-N [14]). prov:wasDerivedFrom

ew iew v vi y ow ilit fl b a si t n da po s re

pr oc

es s

fl ow

prov:Entity vi ew

prov:used prov:Activity

prov:Agent prov:wasAssociatedWith

prov:actedOnBehalfOf

Figure 1: Three Different Views of the Core of prov.

The figure adopts the prov layout conventions: an entity is represented by a yellow ellipsis, an activity by a blue rectangle, and an agent by an orange pentagon. We note here that the diagram is a “class diagram” illustrating the classes that occur as domain and range of properties. Taken from [12].

2.2

GENERATING EXPLANATIONS ABOUT CONNECTIONS

In order to generate an explanation about how two prov elements are connected, we first identity the chain of relationships connecting them. We then generate a narrative explaining the chained relationships.

3.1

Identifying Connections between Elements and their Attributes

In order to identify whether a element has a connection to another element, we identify whether there is a chain of relationship that connects them. We first use a fragmentation algorithm, which generates a subset of prov statements describing an element from a prov document. The fragmentation algorithm we use is based on [16]’s basic fragmentation algorithm for ontologies to generate a fragment of a concept.

This fragmentation approach allows large prov documents to be queried without suffering from overhead costs associated with scale.

prov:wasAttributedTo

prov:wasGeneratedBy

prov:wasInformedBy

3.

Second, we verify that this fragment references to two elements. Third, we use the Dijkstra’s algorithm [17] to find the shortest path between two prov elements, where for now all relationships connecting the nodes have a value of 1. Then using the shortest path we build a list of dictionaries, where each dictionary contains the name of the two connecting nodes, their relationship type, and the connecting relationship. For example, the following graph contains the triples: a wasDerivedFrom b, b wasDerivedFrom d, a wasDerivedFrom d, and d wasDerivedFrom e. Our approach created the following list describing how element a is connected to e: [{ ‘subject’: ‘a’ ‘subject_type’: ‘entity’, ‘relationship’: ‘wasDerivedFrom’, ‘object’: ‘d’, ‘object_type’: ‘entity’,

Narrative Summarisation

The role of narrative is to provide an account of connected events, which can be organised in a number of different categories. Provenance data has a similar role, it describes entities, activities and agents connected by relationships, and implicitly provides a sequence of their generation, performance and actions, respectively. Narratives are an effective way to communicate information, research has shown that it enables users to make sense of their data [9, 6, 10], and it is equally effective for both communities and individuals [1, 8].

Previously, Semantic Web technologies have been used to generate narratives [18, 5, 2]. In more detail, Tuffield et al. [18] and Jewell et al. [5] describe the OntoMedia ontology, which supports the generation of narratives. The work presented in [18] discuss approaches to generate narratives from a vocabulary, the approaches included are based on character, plot and user modelling. The work presented in [5] describes how OntoMedia is used to annotate the vast collection of heterogeneous media. The work [2] use ontological domain knowledge to select and organise a narrative

}, { ‘object’: ‘d’, ‘object_type’: ‘entity’, ‘relationship’: ‘wasDerivedFrom’, ‘subject’: ‘e’ ‘subject_type’: ‘entity’, }] The pseudocode for this algorithm is described in Algorithm 1.

3.2

Generating Sentences Describing Connected Elements

The narrative we generate is an account of how two elements connect, it has a linear structure of sentences based on the implied order of events recorded in the provenance. In order to generate sentences, we use the list generated by the chaining algorithm (described in the section above). Each

Relationship wasDerivedFrom

Algorithm 1 This algorithm finds a path connecting the prov elements subject element and goal element in a graph, within a max distance, it returns a list of relationships connecting the two elements. Where the functions retrieveFragment returns a set of provenance statements, buildGraph returns a weighted graph given provenance data, and dijkstra returns a list of the shortest path between two elements.

1: procedure GetConnectingRelationships(graph, subject element, goal element, max distance) 2: prov fragment = retrieveFragment(subject element, max distance) 3: if prov fragment.contains(subject element, goal element) then 4: graph = buildGraph(prov segment) 5: shortest path = dijkstra(graph, subject element, goal element) 6: return shortest path 7: else 8: return None

wasAssociatedWith used wasAttributedTo specializationOf wasInformedBy

wasGeneratedBy

Sentence ‘was derived from’ ‘originates from’ ‘was sourced from’ ‘was associated with’ ‘was performed by’ ‘used’ ‘made use of’ ‘was attributed to’ ‘is connected to’ ‘is a specialization of ’ ‘is an instance of’ ‘was informed by’ ‘was initiated because of’ ‘was performed after’ ‘was generated by’ ‘was created by’

Table 2: Sentence parts for relationships Type agent , entity, and activity

item in the list will be used to generate a single sentence, and each sentence is constructed in three parts. The first part of the sentence describes the subject, the second describes the relationship, and the third describes the object.

For example, ‘The a entity’ ‘was derived from’ ‘the entity e’. Each part of the sentence is randomly selected from a list of possible parts given their type or relationship, these are described in Tables 1, 2 and 3.

Type agent

entity

activity

Sentence ‘the {subject}’ ‘the {subject} is a {subject type} ‘the agent {subject}’ ’the {subject}’ ‘the {subject} is a {subject type}, which’ ‘the entity {subject}’ ‘the contents contained in {subject}’ ‘the contents of {subject}’ ’the {subject}’ ‘the {subject} is a {subject type}, which’ ‘the {subject} process’ ‘the activity {subject}’

Table 1: Sentence parts for subject types

4.

RIDE SHARE

Ride Share is an application that enables car sharing for workplace workers, university students and similar large communities. The application allows both drivers and commuters to offer and request rides. These offers and ride requests include details about required travels, timing, locations, capacity, prices, and other details relevant for car sharing. It performs automatic matching of commuters to available cars, by considering origin and destination, routes, capacity and other available information. Incentives are used to influence participant behaviours and maximise the global system goals. Our ultimate motivation in this scenario is to describe how matches for rides and reputation reports are generated, because these types of processes are typically a black box to users. The execution of these processes is documented using prov.

Sentence ‘the {subject}’ ‘the {subject} {subject type}’

Table 3: Sentence parts for object types The following two sections provide examples of sentences generated using our approach over the prov data visualised as a graph in Figure 2. The provenance data in this figure was recorded by the Ride Share’s UI, and shows a user logging in looking at their homepage, their ride offers, profile, reputation and submitting a ride request.

4.1

Ride Sharing Query 1

The first query we performed generates a narrative that connects a UI’s login page to a ride plan, ‘log:8069ee6a051f9ac83b2c647beddd723d’ and ‘rplan:85’, respectively. The following structure was created by the finding the shortest path between the two entities (see Section 3.1). [ {‘object_type’: ‘request’, ‘subject_type’: ‘response’, ‘relationship’: ‘wasDerivedFrom’, ‘object: ‘uuid:1baf0146-1711-4c56-8589-059ab29fcfca’, ‘subject’: ‘rplan:85’} {‘object_type’: ‘request’, ‘subject_type’: ‘my_offer_page’, ‘relationship’: ‘wasDerivedFrom’, ‘object: ‘moff:86b9df09090720c10279567105a499d2’, ‘subject’: ‘uuid:1baf0146-1711-4c56-8589-059ab29fcfca’}, {‘object_type’: ‘my_offer_page’, ‘subject_type’: ‘ride_requests’, ‘relationship’: ‘wasDerivedFrom’, ‘object: ‘rreq:ima1’, ‘subject’: ‘moff:86b9df09090720c10279567105a499d2’}, {‘object_type’: ‘response’, ‘subject_type’: ‘home_page’, ‘relationship’: ‘wasDerivedFrom’, ‘object: ‘uuid:55cf0887-77f7-46ed-9cc3-809fc701574e’, ‘subject’: ‘rreq:ima1’}, {‘object_type’: ‘response’, ‘subject_type’: ‘home_page’,

ap:ima1

prov:type cas:Peer tmpl:order [0] wasAssociatedWith

wasAttributedTo

uuid:2e83bc56-3c84-4218-9138-161f5dac7c55

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

wasAttributedTo

wasAttributedTo

home:b51fa37a247bbdd13202103b87381b16

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

wasAssociatedWith

tmpl:order [0, 0]

used

uuid:cec80eac-669e-4dcb-9a35-d464af6a7263

prov:startTime 2015-04-24T15:30:51+01:00 prov:endTime 2015-04-24T15:30:51+01:00 prov:type cas:SendingRequest tmpl:order [0] wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

wasInformedBy

uuid:c0bd1e6e-91ad-4554-9ae8-3d45ed1f74fc

wasAttributedTo

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:30:51+01:00 prov:endTime 2015-04-24T15:30:51+01:00 prov:type cas:RecievingRequest tmpl:order [0]

tmpl:order [0, 0]

req:884

prov:type cas:Request tmpl:order [0]

wasGeneratedBy

tmpl:order [0, 0]

wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

wasAssociatedWith

tmpl:order [0, 0]

wasDerivedFrom

wasDerivedFrom

tmpl:order [0, 0]

tmpl:order [0, 0]

used

tmpl:order [0, 0]

wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:30:47+01:00 prov:endTime 2015-04-24T15:30:47+01:00 prov:type cas:RecievingRequest tmpl:order [0] wasDerivedFrom

wasGeneratedBy

wasAssociatedWith

uuid:a8fc9af2-3efd-4cb9-8f9a-b63c17bf98c9

used

tmpl:order [0, 0]

wasDerivedFrom

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:Request tmpl:order [0]

wasAttributedTo

specializationOf

wasAttributedTo

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

uuid:5ee62476-522c-4a0e-a626-0751b71e9a19

tmpl:order [0, 0]

ooff:5851a9ba27c9ab44d8000388c733d576

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

used

uuid:633f0b3f-cc66-41b6-8bb0-fdf7cbdfc9b4

used

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

uuid:535c5178-3603-4cf1-819c-4c5f2f423042

prov:startTime 2015-04-24T15:34:33+01:00 prov:endTime 2015-04-24T15:34:33+01:00 prov:type cas:SendingRequest tmpl:order [0] wasAttributedTo wasGeneratedBy

tmpl:order [0, 0]

req:891

tmpl:order [0, 0]

used

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

uuid:5222c2f2-80fc-4d44-9c5a-d664a57bf0d5

prov:startTime 2015-04-24T15:34:12+01:00 prov:endTime 2015-04-24T15:34:12+01:00 prov:type cas:SendingRequest tmpl:order [0]

wasDerivedFrom

wasInformedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

wasInformedBy

wasDerivedFrom

uuid:ec33a6e2-13f3-4644-92c8-155dbcc85e72

wasDerivedFrom

tmpl:order [0, 0]

wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:32:14+01:00 prov:endTime 2015-04-24T15:32:14+01:00 prov:type cas:SendingRequest tmpl:order [0] wasGeneratedBy

wasAttributedTo

req:888

tmpl:order [0, 0]

wasInformedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

uuid:17a10009-dfa9-41a9-84be-03f159bc9aa1

prov:startTime 2015-04-24T15:34:12+01:00 prov:endTime 2015-04-24T15:34:12+01:00 prov:type cas:RecievingRequest tmpl:order [0]

prov:type cas:Request tmpl:order [0]

wasGeneratedBy

res:891

tmpl:order [0, 0]

wasDerivedFrom

tmpl:order [0, 0]

res:888

wasAttributedTo wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

req:886

wasDerivedFrom

tmpl:order [0, 0]

tmpl:order [0, 0]

wasInformedBy

tmpl:order [0, 0]

uuid:baf433a3-2262-467e-a09f-c7e3a27a8820

tmpl:order [0, 0]

prov:type cas:Response tmpl:order [0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:34:38+01:00 prov:endTime 2015-04-24T15:34:38+01:00 prov:type cas:RecievingRequest tmpl:order [0]

prov:type cas:Request tmpl:order [0]

tmpl:order [0, 0]

wasDerivedFrom

tmpl:order [0, 0]

wasGeneratedBy

wasInformedBy

uuid:55cf0887-77f7-46ed-9cc3-809fc701574e

wasAttributedTo

uuid:6f66264a-aab1-4578-a013-1bfea147126b

wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:31:21+01:00 prov:endTime 2015-04-24T15:31:21+01:00 prov:type cas:RecievingRequest tmpl:order [0]

prov:type cas:Request tmpl:order [0]

specializationOf

prov:type cas:Response tmpl:order [0]

wasDerivedFrom

tmpl:order [0, 0]

res:886

prov:type cas:Response tmpl:order [0]

specializationOf

tmpl:order [0, 0]

wasInformedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

uuid:be59b93a-99d3-44e1-a85c-2c726192869a

tmpl:order [0, 0]

tmpl:order [0, 0]

specializationOf

tmpl:order [0, 0]

specializationOf

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:30:47+01:00 prov:endTime 2015-04-24T15:30:47+01:00 prov:type cas:RecievingRequest tmpl:order [0]

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:Response tmpl:order [0] wasDerivedFrom

wasDerivedFrom

wasAttributedTo

prov:type prov:Revision tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

prof:a0e9a98f988583d24281025f2d8dc95e

tmpl:order [0, 0]

specializationOf

tmpl:order [0, 0]

specializationOf

prov:type cas:View tmpl:order [0] wasAssociatedWith

used

avprof:b90fc1e44482cb8816e9c11249a4d646

tmpl:order [0, 0]

specializationOf

tmpl:order [0, 0]

specializationOf

prov:startTime 2015-04-24T15:31:15+01:00 prov:type cas:ChangingView tmpl:order [0] wasDerivedFrom

wasGeneratedBy

wasGeneratedBy

prov:type prov:Revision tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

wasDerivedFrom

wasAttributedTo

wasAttributedTo

wasAttributedTo

eprof:b90fc1e44482cb8816e9c11249a4d646

tmpl:order [0, 0]

specializationOf specializationOf

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0] wasAssociatedWith

tmpl:order [0, 0]

used

used

uuid:25df698b-32eb-4126-b51c-e598ea610feb

tmpl:order [0, 0]

wasGeneratedBy

wasDerivedFrom

wasGeneratedBy

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasInformedBy

tmpl:order [0, 0]

wasGeneratedBy

specializationOf

specializationOf

tmpl:order [0, 0]

specializationOf

specializationOf

specializationOf

specializationOf

prov:startTime 2015-04-24T15:31:18+01:00 prov:endTime 2015-04-24T15:31:18+01:00 prov:type cas:RecievingRequest tmpl:order [0]

wasDerivedFrom

wasGeneratedBy

ima1:profile/v/0.12

specializationOf

wasAssociatedWith

uuid:489bb1ac-920f-4c86-8019-90432a714445

tmpl:order [0, 0]

prov:type cas:Request tmpl:order [0]

wasDerivedFrom

specializationOf

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:31:18+01:00 prov:type cas:ChangingView tmpl:order [0]

wasDerivedFrom

uuid:5a6b85c8-db36-45b1-a777-d11842c1ccdf

tmpl:order [0, 0]

wasAssociatedWith

asprof:05d3e54500a122e6e91d9cefda714897

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:31:18+01:00 prov:endTime 2015-04-24T15:31:18+01:00 prov:type cas:SendingRequest tmpl:order [0]

wasGeneratedBy

wasGeneratedBy

tmpl:order [0, 0]

specializationOf

tmpl:order [0, 0]

specializationOf

specializationOf

specializationOf

prov:type cas:Response tmpl:order [0] wasDerivedFrom

wasDerivedFrom

prov:type prov:Revision tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

prof:05d3e54500a122e6e91d9cefda714897

specializationOf

wasAttributedTo

specializationOf

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0] used

wasAssociatedWith

avhome:df358295a20c037c8d3fc64058fa560a

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:31:32+01:00 prov:type cas:ChangingView tmpl:order [0] wasDerivedFrom

prov:type prov:Revision tmpl:order [0, 0]

wasGeneratedBy

wasAttributedTo

wasAttributedTo

home:77657131bdd26d2fcef97a0773627365

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0] wasAssociatedWith

used

used

avoff:7302bfbe21950a68fa433aec7e9fe513

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

noff:7302bfbe21950a68fa433aec7e9fe513

wasAttributedTo

tmpl:order [0, 0]

wasGeneratedBy

tmpl:order [0, 0]

wasDerivedFrom

tmpl:order [0, 0]

prov:type prov:Revision tmpl:order [0, 0]

wasDerivedFrom wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

used

uuid:ed08d972-13ca-4441-aa7c-7d29eb2e3346

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasDerivedFrom

tmpl:order [0, 0]

prov:type prov:Revision tmpl:order [0, 0]

wasDerivedFrom

moff:ab2a9aefc2d057628453982dc1b3e44a

used

wasAssociatedWith

uuid:64de79f0-73d9-4228-bb72-7ddee643b309

tmpl:order [0, 0]

wasGeneratedBy

wasInformedBy

uuid:b446fd1c-d385-4415-b3c6-90211902f025

tmpl:order [0, 0]

tmpl:order [0, 0]

used

tmpl:order [0, 0]

wasAttributedTo

wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

uuid:e8008c98-ce4c-4707-a8b4-848f25c5e96d

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:33:41+01:00 prov:endTime 2015-04-24T15:33:41+01:00 prov:type cas:RecievingRequest tmpl:order [0]

tmpl:order [0, 0]

req:889

tmpl:order [0, 0]

wasAssociatedWith

wasDerivedFrom

wasAssociatedWith

uuid:6349b96b-8470-42f6-8d84-764c93670503

tmpl:order [0, 0]

wasDerivedFrom

tmpl:order [0, 0]

wasDerivedFrom

prov:type prov:Revision tmpl:order [0, 0]

wasInformedBy

pre_2:5851a9ba27c9ab44d8000388c733d576

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

avooff:e0e8bc4443e84c162e5e2de127557763

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:33:34+01:00 prov:type cas:ChangingView tmpl:order [0] wasAttributedTo

wasGeneratedBy

prov:type prov:Revision tmpl:order [0, 0]

tmpl:order [0, 0]

wasDerivedFrom

wasDerivedFrom

wasDerivedFrom

ooff:f6d65eda9daa4e809c7c7a3b94b892fd

tmpl:order [0, 0]

wasDerivedFrom

prov:type prov:Revision tmpl:order [0, 0]

tmpl:order [0, 0]

wasGeneratedBy

wasAttributedTo

ooff:e0e8bc4443e84c162e5e2de127557763

prov:type cas:View tmpl:order [0] wasAssociatedWith

wasAssociatedWith

uuid:41068ce8-4e0c-4593-bb31-92f055e09bd6

prov:startTime 2015-04-24T15:34:26+01:00 prov:endTime 2015-04-24T15:34:26+01:00 prov:type cas:RecievingRequest tmpl:order [0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:34:45+01:00 prov:type cas:ChangingView tmpl:order [0]

wasAttributedTo

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

used

used

avooff:fa10097cdd2426ced33b2d7c71cdcea8

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:34:49+01:00 prov:type cas:ChangingView tmpl:order [0]

wasAssociatedWith

avoff:86b9df09090720c10279567105a499d2

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:33:40+01:00 prov:type cas:ChangingView tmpl:order [0] wasAttributedTo

tmpl:order [0, 0]

tmpl:order [0, 0]

wasGeneratedBy

wasAttributedTo

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

used

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

res:889

prov:type cas:Response tmpl:order [0]

wasAttributedTo

tmpl:order [0, 0]

wasAssociatedWith

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:33:57+01:00 prov:endTime 2015-04-24T15:33:57+01:00 prov:type cas:RecievingRequest tmpl:order [0] wasDerivedFrom

tmpl:order [0, 0]

wasGeneratedBy

moff:5851a9ba27c9ab44d8000388c733d576

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:32:01+01:00 prov:endTime 2015-04-24T15:32:01+01:00 prov:type cas:RecievingRequest tmpl:order [0]

prov:type cas:Request tmpl:order [0]

wasInformedBy

uuid:d309b9cd-8e47-470f-82de-89a11a4a61fa

prov:type cas:Request tmpl:order [0]

used

prov:startTime 2015-04-24T15:32:01+01:00 prov:type cas:ChangingView tmpl:order [0]

wasInformedBy

tmpl:order [0, 0]

wasAssociatedWith

prov:startTime 2015-04-24T15:34:26+01:00 prov:endTime 2015-04-24T15:34:26+01:00 prov:type cas:SendingRequest tmpl:order [0]

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:Response tmpl:order [0]

wasGeneratedBy

uuid:ea015909-32fc-4421-954b-c6601a287f7e

tmpl:order [0, 0]

wasDerivedFrom

prov:type cas:Request tmpl:order [0]

wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:33:57+01:00 prov:endTime 2015-04-24T15:33:57+01:00 prov:type cas:SendingRequest tmpl:order [0]

wasDerivedFrom

tmpl:order [0, 0]

prov:type cas:Request tmpl:order [0]

wasGeneratedBy

used

avooff:f6d65eda9daa4e809c7c7a3b94b892fd

tmpl:order [0, 0]

wasDerivedFrom

uuid:4d5a5080-772f-4016-aff6-dafdc3eca7ee

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

wasAssociatedWith

wasAttributedTo

wasDerivedFrom

rreq:ima1

prov:startTime 2015-04-24T15:32:01+01:00 prov:endTime 2015-04-24T15:32:01+01:00 prov:type cas:SendingRequest tmpl:order [0]

tmpl:order [0, 0]

wasDerivedFrom

wasAttributedTo

uuid:35e45351-3ede-4213-afcf-f98befe97c59

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

wasAssociatedWith

uuid:78b3fe08-7a46-48df-8d9b-e12eb6872f2d

prov:startTime 2015-04-24T15:33:41+01:00 prov:endTime 2015-04-24T15:33:41+01:00 prov:type cas:SendingRequest tmpl:order [0]

prov:startTime 2015-04-24T15:31:34+01:00 prov:type cas:ChangingView tmpl:order [0]

wasAttributedTo

wasAttributedTo

wasGeneratedBy

wasAttributedTo

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo wasDerivedFrom

noff:fa10097cdd2426ced33b2d7c71cdcea8

wasDerivedFrom

tmpl:order [0, 0]

wasDerivedFrom

prov:type prov:Revision tmpl:order [0, 0]

tmpl:order [0, 0]

wasGeneratedBy

tmpl:order [0, 0]

wasDerivedFrom

wasDerivedFrom

wasDerivedFrom

used

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

wasAttributedTo

wasAttributedTo

tmpl:order [0, 0]

used

tmpl:order [0, 0]

uuid:c05c150c-bcf5-4142-ad2a-3fcca85e69ff

wasAssociatedWith

wasDerivedFrom

wasGeneratedBy

uuid:758ae002-2658-4a44-808d-dae59a085dbd

tmpl:order [0, 0]

prov:type prov:Revision tmpl:order [0, 0]

prov:type cas:Request tmpl:order [0]

wasDerivedFrom

wasGeneratedBy

wasDerivedFrom

moff:66274f46918138ff6c252ab628277cf3

wasAttributedTo

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

prov:type prov:Revision tmpl:order [0, 0]

wasDerivedFrom wasDerivedFrom

ooff:55ace33d9c0fcf213429882b0575378c

prov:type cas:View tmpl:order [0]

wasDerivedFrom

tmpl:order [0, 0]

tmpl:order [0, 0]

wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAssociatedWith

avooff:55ace33d9c0fcf213429882b0575378c

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:35:57+01:00 prov:endTime 2015-04-24T15:35:57+01:00 prov:type cas:SendingRequest tmpl:order [0]

prov:startTime 2015-04-24T15:35:57+01:00 prov:type cas:ChangingView tmpl:order [0]

tmpl:order [0, 0]

wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

used

pre_2:66274f46918138ff6c252ab628277cf3

wasAttributedTo

tmpl:order [0, 0]

prov:type prov:Revision tmpl:order [0, 0]

moff:86b9df09090720c10279567105a499d2

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0] wasAssociatedWith

tmpl:order [0, 0]

wasDerivedFrom

prov:startTime 2015-04-24T15:35:57+01:00 prov:endTime 2015-04-24T15:35:57+01:00 prov:type cas:RecievingRequest tmpl:order [0]

wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:33:56+01:00 prov:endTime 2015-04-24T15:33:56+01:00 prov:type cas:SendingRequest tmpl:order [0]

wasInformedBy

uuid:b0fa698e-c070-42d4-9a2b-bfb90edd3a7d

used

uuid:c2506449-7421-47be-bf0c-2cdd22f20a02

prov:startTime 2015-04-24T15:34:05+01:00 prov:type cas:ChangingView tmpl:order [0]

wasAttributedTo

tmpl:order [0, 0]

tmpl:order [0, 0]

wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

uuid:1baf0146-1711-4c56-8589-059ab29fcfca

wasAssociatedWith

tmpl:order [0, 0]

wasInformedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

wasAttributedTo

uuid:41494c4c-3b12-46b7-bade-007413a0a625

wasAssociatedWith

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:33:56+01:00 prov:endTime 2015-04-24T15:33:56+01:00 prov:type cas:RecievingRequest tmpl:order [0]

prov:type cas:Request tmpl:order [0]

wasGeneratedBy

rreq:ima1/v/0.0

prov:type cas:Response tmpl:order [0]

wasDerivedFrom

tmpl:order [0, 0]

rplan:85

wasGeneratedBy

tmpl:order [0, 0]

prov:type cas:Response tmpl:order [0]

Figure 2: This figure is used for illustrative purposely only, for scalable detail please use this link: https: //provenance.ecs.soton.ac.uk/store/documents/84089/

‘relationship’: ‘wasDerivedFrom’, ‘object: ‘home:b51fa37a247bbdd13202103b87381b16’, ‘subject’: ‘uuid:55cf0887-77f7-46ed-9cc3-809fc701574e’}, {‘object_type’: ‘home_page’, ‘subject_type’: ‘login_page’, ‘relationship’: ‘wasDerivedFrom’, ‘object: ‘log:8069ee6a051f9ac83b2c647beddd723d’, ‘subject’: ‘home:b51fa37a247bbdd13202103b87381b16’},

While our approach generates a linear narrative describing the connection between two prov elements, however lacks a natural flow present in discourse. This lack of flow stems from the repetitive use of connecting sentence phrases, and long identifiers used for prov elements. In order to improve the narrative, we have identified key three areas:

]

The above structure is used to create the following sentence, which are generating using the approach described in Section 3.2: The contents contained in rplan:85 was derived from the uuid:1baf0146-1711-4c56-8589-059ab29fcfca.

The contents of uuid:1baf0146-1711-4c56-8589-059ab29fcfca was sourced from the moff:86b9df09090720c10279567105a499d2.

The moff:86b9df09090720c10279567105a499d2 is a my offer page, and was derived from the rreq:ima1 request.

The contents of rreq:ima1 was derived from uuid:55cf0887-77f7-46ed-9cc3-809fc701574e request. The uuid:55cf0887-77f7-46ed-9cc3-809fc701574e was derived from the home:b51fa37a247bbdd13202103b87381b16. The home page home:b51fa37a247bbdd13202103b87381b16 orginates from the log:8069ee6a051f9ac83b2c647beddd723d login page.

4.2

Ride Sharing Query 2

The second query generates a narrative that connects a UI’s new offers page and a profile page, ‘noff:f9de6bdea5b4c849b884aa44ef6b8700’, and ‘prof:b7f89504e98004d9b60d8785e53c468b’, and produces the following: The noff:f9de6bdea5b4c849b884aa44ef6b8700 new offer page is a specialization of the log:5e0454ca474ccdadc8d2580f58b26581 log offer page. The log:5e0454ca474ccdadc8d2580f58b26581 was derived from the prof:b7f89504e98004d9b60d8785e53c468b profile page.

5.

DISCUSSION

wasAssociatedWith

uuid:511b9e62-c577-4415-8f03-3a48e4b2a509

prov:startTime 2015-04-24T15:32:14+01:00 prov:endTime 2015-04-24T15:32:14+01:00 prov:type cas:RecievingRequest tmpl:order [0]

prov:type cas:Request tmpl:order [0]

wasGeneratedBy

wasAssociatedWith

uuid:f72e6760-2aeb-432e-ae86-b2320dc96b2d

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:34:33+01:00 prov:endTime 2015-04-24T15:34:33+01:00 prov:type cas:RecievingRequest tmpl:order [0]

prov:type cas:Request tmpl:order [0]

prov:type prov:Revision tmpl:order [0, 0]

tmpl:order [0, 0]

wasGeneratedBy

prov:startTime 2015-04-24T15:30:47+01:00 prov:endTime 2015-04-24T15:30:47+01:00 prov:type cas:SendingRequest tmpl:order [0] wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

wasAssociatedWith

tmpl:order [0, 0]

wasGeneratedBy

uuid:7f709a24-5d3f-410c-a1df-f16431699e64

wasAttributedTo wasAttributedTo wasAttributedTo

log:8069ee6a051f9ac83b2c647beddd723d

tmpl:order [0, 0]

wasGeneratedBy

ima1:profile/v/0.11

tmpl:order [0, 0]

prov:type cas:Response tmpl:order [0]

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:31:21+01:00 prov:endTime 2015-04-24T15:31:21+01:00 prov:type cas:SendingRequest tmpl:order [0]

wasInformedBy

uuid:c873bf1b-a91d-4019-a77a-96715ceeb0fc

tmpl:order [0, 0]

prov:type cas:Request tmpl:order [0]

tmpl:order [0, 0]

avprof:a0e9a98f988583d24281025f2d8dc95e

prov:startTime 2015-04-24T15:31:13+01:00 prov:type cas:ChangingView tmpl:order [0]

wasGeneratedBy

uuid:c15dbf37-d52d-4d3e-8098-91ee66c40d16

wasDerivedFrom

res:884

tmpl:order [0, 0]

wasAttributedTo

wasDerivedFrom

tmpl:order [0, 0]

used

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:30:47+01:00 prov:endTime 2015-04-24T15:30:47+01:00 prov:type cas:SendingRequest tmpl:order [0] wasAttributedTo

used

uuid:424c5b05-3934-4b9a-a097-918272ee0f26

wasAttributedTo

tmpl:order [0, 0]

specializationOf

prov:startTime 2015-04-24T15:30:49+01:00 prov:type cas:ChangingView tmpl:order [0]

prov:startTime 2015-04-24T15:34:38+01:00 prov:endTime 2015-04-24T15:34:38+01:00 prov:type cas:SendingRequest tmpl:order [0]

prov:startTime 2015-04-24T15:34:38+01:00 prov:type cas:ChangingView tmpl:order [0]

wasDerivedFrom

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

uuid:d2e722b3-dd4f-43a4-9974-a986b3d6a2e0

tmpl:order [0, 0]

specializationOf

wasAssociatedWith

wasGeneratedBy

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

used

avhome:dde15cfe3509eda7ca3938ec44a7be59

tmpl:order [0, 0]

used

avoff:ab2a9aefc2d057628453982dc1b3e44a

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

wasAttributedTo

tmpl:order [0, 0]

specializationOf

wasAssociatedWith

prov:type cas:View tmpl:order [0]

tmpl:order [0, 0]

tmpl:order [0, 0]

prov:type cas:View tmpl:order [0]

wasGeneratedBy

tmpl:order [0, 0]

wasAttributedTo

home:1ebf642919f7591b4099ce8248629a50

tmpl:order [0, 0]

used

wasAttributedTo

ooff:86b9df09090720c10279567105a499d2

tmpl:order [0, 0]

prov:startTime 2015-04-24T15:30:46+01:00 prov:endTime 2015-04-24T15:30:46+01:00 prov:type cas:ChangingView tmpl:order [0]

tmpl:order [0, 0]

wasAssociatedWith

1. Summarisation: The narrative presented in Section 4.1 illustrates the repetitive sentence structure for prov elements that are connected by the same relationship.

Chains of elements that are connected via the same relation can be shortened using lists. For example: The contents contained in rplan:85 was derived from the following entities: the request uuid:1baf01461711-4c56-8589-059ab29fcfca, the my offer page moff:86b9df09090720c10279567105a499d2, the response rreq:ima1, the request uuid:55cf088777f7-46ed-9cc3-809fc701574e, the home page home:b51fa37a247bbdd13202103b87381b16, and the log:8069ee6a051f9ac83b2c647beddd723d login page.

While this shortens the narrative, it does not improve its readability or the reader’s interest in the subject because there are no descriptions of the identifiers which are non-descriptive. This issue is more prevalent with longer chains of elements connected by the same relationship.

2. Element Path: The shortest path prov elements might not provide the user with most informative narrative.

For example, prov uses a single specialisation relationship to connect two elements, however a longer path could explain who was responsible for its creation or which activities used it. This is highlighted in the narrative presented in Section 4.2.

3. Narrative Generation: The vocabulary used to generate the narratives is limited, using a different approach might be able to expand the vocabulary. Increasing the vocabulary used to describe elements could improve the readability, however there is a trade-off between using a broad vocabulary where the narrative could

wasGeneratedBy

tmpl:order [0, 0]

tmpl:order [0, 0]

become less specific, and a narrow vocabulary where the narrative becomes repetitive.

6.

CONCLUSION

In this paper, we present an approach to generate a narrative describing the connection between two prov elements.

It describes how two prov elements are connected by identifying a chain of relationships connecting them. We then randomly selected terms to describe the subject, its relationship, the element to which it is connected, to form a simple sentence structure. We then discuss areas which could improve readability of the generated narrative.

For future work, we will develop an approach to summarise chains of elements connected by the same relationships to improve readability. We will also investigate whether using different vertex weightings for different relationships could output more interesting narratives. In order to evaluate this work we will deploy a user study which will allow users to query how their data is connected to other entities in the ride share application.

7.

[9]

[10]

[11]

[12] [13]

ACKNOWLEDGMENTS

The research leading to these results has received partially funding from the European Community’s Seventh Framework Program (FP7/2007-2013) under grant agreement n.

600854 Smart Society: hybrid and diversity-aware collective adaptive systems: where people meet machines to build smarter societies http://www.smart-society-project.eu/.

8.

[8]

REFERENCES

[1] O. Ferret, B. Grau, and N. Masson. Thematic segmentation of texts: two methods for two kinds of texts. In Proceedings of the 36th Annual Meeting of the Association for Computational Linguistics and 17th International Conference on Computational Linguistics-Volume 1, pages 392–396. Association for Computational Linguistics, 1998.

[2] J. Geurts, S. Bocconi, J. Van Ossenbruggen, and L. Hardman. Towards ontology-driven discourse: From semantic graphs to multimedia presentations. Springer, 2003.

[3] H. Hua, C. Tilmes, S. Zednik (eds.), and L. Moreau.

PROV-XML: The PROV XML Schema. W3C Working Group Note NOTE-prov-xml-20130430, World Wide Web Consortium, Apr. 2013.

[4] T. D. Huynh. Trust and reputation in open multi-agent systems. June 2006.

[5] M. O. Jewell, K. F. Lawrence, M. M. Tuffield, A. Prugel-Bennett, D. E. Millard, M. S. Nixon, N. R. Shadbolt, et al. Ontomedia: An ontology for the representation of heterogeneous media. In In Proceeding of SIGIR workshop on Mutlimedia Information Retrieval. ACM SIGIR, 2005.

[6] A. Kuchinsky, C. Pering, M. L. Creech, D. Freeze, B. Serra, and J. Gwizdka. Fotofile: a consumer multimedia organization and retrieval system. In Proceedings of the SIGCHI conference on Human Factors in Computing Systems, pages 496–503. ACM, 1999.

[7] T. Lebo, S. Sahoo, D. McGuinness (eds.), K. Behajjame, J. Cheney, D. Corsar, D. Garijo,

[14]

[15]

[16]

[17]

[18] [19]

S. Soiland-Reyes, S. Zednik, and J. Zhao. PROV-O: The PROV Ontology. W3C Recommendation REC-prov-o-20130430, World Wide Web Consortium, Oct. 2013.

C. L´evi-Strauss. Structural anthropology. Basic Books, 2008.

O. Mallett and R. Wapshott. The challenges of identity work: Developing ricoeurian narrative identity in organisations. ephemera, page 271, 2011.

Y. Matsuo and M. Ishizuka. Keyword extraction from a single document using word co-occurrence statistical information. International Journal on Artificial Intelligence Tools, 13(01):157–169, 2004.

L. Moreau. Provenance-based reproducibility in the semantic web. Web Semantics: Science Services and Agents on the World Wide Web, 9(2):202–221, July 2011.

L. Moreau and P. Groth. Provenance: An Introduction to PROV. Morgan and Claypool, September 2013.

L. Moreau, P. Missier (eds.), K. Belhajjame, R. B’Far, J. Cheney, S. Coppens, S. Cresswell, Y. Gil, P. Groth, G. Klyne, T. Lebo, J. McCusker, S. Miles, J. Myers, S. Sahoo, and C. Tilmes. PROV-DM: The PROV Data Model. W3C Recommendation REC-prov-dm-20130430, World Wide Web Consortium, Oct. 2013.

L. Moreau, P. Missier (eds.), J. Cheney, and S. Soiland-Reyes. PROV-N: The Provenance Notation.

W3C Recommendation REC-prov-n-20130430, World Wide Web Consortium, Oct. 2013.

H. S. Packer, L. Dr˘ agan, and L. Moreau. An auditable reputation service for collective adaptive systems. In Social Collective Intelligence, pages 159–184. Springer, 2014.

J. Seidenberg and A. Rector. Web ontology segmentation: analysis, classification and use. In Proceedings of the 15th international conference on World Wide Web, pages 13–22. ACM, 2006.

S. Skiena. Dijkstra’s algorithm. Implementing Discrete Mathematics: Combinatorics and Graph Theory with Mathematica, Reading, MA: Addison-Wesley, pages 225–227, 1990.

M. M. Tuffield, D. E. Millard, and N. R. Shadbolt.

Ontological approaches to modelling narrative. 2006.

D. J. Weitzner, H. Abelson, T. Berners-Lee, J. Feigenbaum, J. Hendler, and G. J. Sussman.

Information accountability. Communications of the ACM, 51(6):82–87, 2008.

c SmartSociety Consortium 2013-2017

D

Deliverable D2.4

PROV-Template Evaluation

In this section, we focus on evaluating Hypothesis 1, where we aim to show that prov template reduces overhead networking costs. In order to evaluate this, we investigated the sizes of provenance templates, bindings and expansions for the SmartShare application in three different languages used to express provenance. In our investigation, we found that there are three factors which influenced their size: (1) language used to express it; (2) characteristics of a template; and (3) types of data expressed in the bindings.

The first factor, the choice of language, has the highest variance in terms of size for the templates, bindings, and expansions because of the syntax used in each language. Figure 9a is a box and whiskers plot which shows the average size of the provenance templates, bindings, and expansions used in the SmartShare application, and shows that the rank in size order is JSON, provn and TTL 5 . For each language the general trend is the same, the templates are the largest, then the expansions, and the smallest is the bindings. The templates are the largest because of the extra syntax required to markup the variables, this markup is not required for the bindings or expansions. On average the size of bindings is approximately 20% smaller than expansion, while the template is approximately over 50% larger than the binding. The average numbers of triples in the templates, bindings, and expansions, also follow this trend (see Figure 9b). In more detail, Figure 9a shows that the templates, bindings and their expansion for the SmartShare application have a wide range of sizes. This is because some of the templates are more complex and require more statements than others (thus supporting Requirement 6 in Section 1). A template that models more complex interactions often requires more binding variables, which in turn increase the number of variables expressed in the expansions. A developerâ&#x20AC;&#x2122;s chosen language to express provenance with, may not only factor in its size implications but its ease of authoring and reading. Provenance expressed in TTL has shorter statements than provn and JSON, and therefore may be viewed as the most readable language. JSON is particularly verbose and can be difficult for humans to understand.

The second factor, characteristics of the template such as the number of prov elements and the number of extra attributes described also affect the size of the provenance. Figures 9b and 10 show the size of the provenance in bytes and triples for a two-person ride. These figures show that the bindings for the submitting request, negotiation and negotiation accept, templates are typically larger (except for the submit request in JSON and the 5

Turtle: https://www.w3.org/TR/turtle/

90 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

number of triples). They are typically larger because these templates detail ride requests and plans which have many extra attributes. These extra attributes were stored in the templates so that the effects and privacy issues can be explored in CASs.

c SmartSociety Consortium 2013-2017

91 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

(a) Average size of the provenance collected by the SmartShare application in JSON, TTL and provn

(b) Average Number of Triples for Templates, Bindings and their Expansion Normalised in TTL

Figure 9: Average size and number of triples for a two-person ride.

92 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

(a) Average Size of Templates, Bindings and their Expansion Normalised in JSON

(b) Average Size of Templates, Bindings and their Expansion Normalised in TTL

Figure 10: Average size of templates, bindings, and expansions for a two-person ride.

c SmartSociety Consortium 2013-2017

93 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

(c) Average Size of Templates, Bindings and their Expansion Normalised in provn

Figure 10: Average size of templates, bindings, and expansions for a two-person ride.

The third factor, the types of data expressed in the bindings, affects the size of the provenance. The size of the bindings and expansions are also affected by the number of multiple values per variable in the template. A template and a binding with multiple values are expanded using a Cartesian product to produce all possible instantiations of the template. Only three of the templates submit multiple values, orch composition, orch negotiation accept and orch negotiation final, and bindings for these templates are larger than the other bindings. The bindings that submitted multiple values from the sample we collected only contained a maximum of 3 multiple variables, therefore the expansions are relatively small. However, the number of multiple values will increase when the SmartShare application generates more ride plan combinations.

In Table 3, we show the average number of bytes used for a two-person ride in an expansion, its corresponding bindings, and the difference between them, for one, ten, and fifty two-person rides. A CAS that does not use prov template would send the same size provenance document as the expansion, in contrast, a CAS that implements prov template would send the same number of bytes as the bindings. The difference between using prov template and prov as the number of rides increases stays the same for each language irrespective of the number of rides (see Column % Difference in Table 3).

On average using prov template reduces the number of bytes sent by 26.75% 45.03% 94 of 105

http://www.smart-society-project.eu

c SmartSociety Consortium 2013-2017

Deliverable D2.4

42.96% for TTL, provn, and JSON, respectively.

Expansion size (bytes)

Binding size (bytes)

1, 2 Person Ride (TTL) 1, 2 Person Ride (PROVN) 1, 2 Person Ride (JSON) 10, 2 Person Ride (TTL) 10, 2 Person Ride (PROVN) 10, 2 Person Ride (JSON)

253,197 226,712 387,605 2,531,970 2,267,120 3,876,050

50, 2 Person Ride (TTL) 50, 2 Person Ride (PROVN) 50, 2 Person Ride (JSON)

12,659,850 11,335,600 19,380,250

Scenario

% Difference

193,444 143,380 250,493 1,934,440 1,433,800 2,504,930

Difference between Binding, and Expansion 59,753 83,332 137,112 59,7530 83,3320 137,1120

9,672,200 7,129,000 12,524,650

2,987,650 4,206,600 6,855,600

26.7566% 45.0331% 42.9752%

26.7566% 45.0331% 42.9752% 26.7566% 45.0331% 42.9752%

Table 3: Table showing the total number of bytes in 1, 10 and 50 two-person rides.

E

URI Narrative Evaluation

In this section, we present our approach and results obtained when evaluating the legibility of URIs used in Provenance (see Hypothesis 4) ,and the generation of sentences using our application-independent provenance explanation system compared against a direct translation of a triple (see Hypothesis 5). In order to develop an approach for an application-generic provenance explanation system, we pre-evaluated prov documents from the University of Southampton Provenance Store, in which we analysed how URIs were used. From these documents we extracted the URIs denoting all the prov resources to use as our corpus of prov URIs. Using this corpus, we were able to develop a regular expression that allowed us to split each URI into its linguistic tokens this is not as trivial a task as might be expected, as there are a number of approaches people use to separate tokens, with CamelCase and snake case as just two examples. The expression we settled upon was which was able to correctly tokenise over 96% of the URIs. The regular expression we used was: [0-9a-fA-F]10,—(?:Mc—Mac)?[A-Z][a-z]+—[A-Z]+s?(?![a-z])—[a-z]+—[0-9]+ This expression is able to distinguish tokens that fall into the following categories: 1. Hexadecimal numbers of at least 10 characters (this limit was introduced to prevent splitting English words like ’feedback’, which is comprised mainly of the characters ’a’ to ’f’); c SmartSociety Consortium 2013-2017

95 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

2. Words beginning with a capital letter, including those with common Scottish name prefixes; 3. Acronyms and their plurals; 4. Lower case words; and 5. Decimal numbers.

Having developed a technique to tokenise URIs, it became necessary to understand the linguistic role played by each of the tokens. We used an off-the-shelf part-of-speech (POS) tagger to tag the URI tokens. Specifically, we used the maximum entropy POS tagger [4] trained on the Penn Treebank corpus [5], which comes as the default tagger of the NLTK python library. It was initially unclear whether or not this would work particularly well, as the POS tagger had naturally been trained on standard English texts, and there was no guarantee that it would work with the much shorter, less grammatically correct URI tokens. However, the performance of the POS tagger was surprisingly good, with it being able to identify the correct specific tag (singular proper noun, present-tense 3rd person verb, superlative adjective, etc) 62.7% of the time, and the correct class of tag (whether the token was a noun, verb, adjective, modifier, or a number) 92.3% of the time. This level of performance indicated that it would be possible to build generation rules using at least the classes of tags, if not the specific tags. However, even this was likely to significantly improve the quality of the language produced.

Using the knowledge that we gained from the earlier parts of this investigation, we were able to build a template-based explanation generation system that generated pairs of sentences from prov graphs. Each pair consisted of a sentence where the linguistic information in URIs was exploited, and another where the linguistic information was not exploited. These pairs of sentences were generated from exactly the same RDF triples, so formally should have contained exactly the same information.

The data used to generate these sentence pairs came from a number of applications that use the provenance store, including a number of RideShare related graphs. Examples of sentences generated from RideShare related graphs include the following pairs of sentences, where the sentence exploiting the linguistic information in the URI appears first in each pair. Example 3 shows that not all URIs were exploited perfectly.

1. (a) Reputation manager generated opinion 1.

96 of 105

http://www.smart-society-project.eu

c SmartSociety Consortium 2013-2017

Deliverable D2.4

(b) ’/rs/reputation manager’

generated

’/rs/opinion/1/’

by

’/reputation-

api/#generate opinion 1’.

2. (a) Rm posted application 1. (b) ’/rm’ generated ’/#application/1/’ by ’/reputatinapi/#post 123’.

3. (a) 2 agent posted ride requests 1. (b) ’/rideshare/#/users/agent2’

generated

’/rideshare/#/rideRequests/1’

by

’/rideshare/#post ride request 100339’.

In order to ascertain the relative quality of the sentences generated by the system, we conducted a human evaluation. In this study, participants were asked to rate each sentence across a number of dimensions taken from [6]: grammatical correctness, fluency, and ease of understanding. With 15 participants, the results of our experiment show that the system that exploits the linguistic information in URIs performs significantly better across all three dimensions, but most prominently in the perceived fluency (see Figure 11 for the graphs of the aggregated participants’ responses).

c SmartSociety Consortium 2013-2017

97 of 105

c SmartSociety Consortium 2013-2017

How would you rate each sentence in terms of how easily you can understand it?

URIs exploited URIs unexploited

120 100

Number of ratings

Deliverable D2.4

80 60 40 20 0

1

2

3

Rating

4

5

6

(a) Comprehension Results

90 80

How would you rate each sentence in terms of fluency?

URIs exploited URIs unexploited

Number of ratings

70 60 50 40 30 20 10 0

1

2

3

Rating

4

5

6

(b) Fluency Results

Figure 11: Aggregated participantsâ&#x20AC;&#x2122; responses

98 of 105

http://www.smart-society-project.eu

c SmartSociety Consortium 2013-2017

Deliverable D2.4

100

How would you rate each sentence in terms of the grammatical correctness?

URIs exploited URIs unexploited

Number of ratings

80 60 40 20 0

1

2

3

Rating

4

5

6

(c) Grammar Results

Figure 11: Aggregated participants’ responses

Additionally, when asked “Which sentence do you think is the better explanation?”, participants answered saying that they preferred the sentence exploiting the linguistic information in the URI a majority of the time (56.4%). On the other hand, the sentence with the URIs unexploited was preferred only 29.3% of the time, with participants saying that neither was the better explanation 14.2% of the time. This gives us a clear indication that explanations generated by exploiting the linguistic information informally encoded in URIs perform better than explanations generated using previously existing techniques.

At present, our system is only capable of generating single sentence explanations.

However, many of the provenance graphs we might wish to communicate with a user are considerably larger than can be reasonably transformed into a single sentence. Consequently, we are now investigating the possibility of generating longer, multi-sentential explanations from larger prov graphs, as well as from prov graph summaries. We are exploring the potential role of various narrative theories to the application of structuring these longer texts, with a goal of generating more engaging texts than can be achieved with more conventional, graph-metric-based approaches. c SmartSociety Consortium 2013-2017

99 of 105

c SmartSociety Consortium 2013-2017

F

Deliverable D2.4

A Narrative of an Example PROV Summary

The provenance generated by two users organising a ride and leaving feedback can be seen in Figure 12, and is summarised in Figure 13. From the summary there is clear division between the entities and activities associated with the three types of agents, the reputation manager rs 27, orchestrator IMAGINARY-ABACAS 36 and the mobile application username 52. The summary enables users to overview the patterns in provenance which can show the frequency that activities and entities in relation to others.

The provenance summary describing the reputation manager’s actions (see Figure 14) shows that it, rs 27, received: 1. Requests (uuid 13) for information about a subject, which generated two types of responses response 17 and response 43. In more detail, response 17 returns an empty response because no feedback has been left the subject queried and hence that response is not derived from any feedback or reputation reports. The response 43 responses are from an API call, these responses are comprised of versioned responses to the calls, where the (https%3A%2F%Fpilot1-pm.smart-societyproject.eu%2Fusers%2Fuser 32) is the root version and (https%3A%2F%Fpilot1pm.smart-society-project.eu%2Fusers%2Fuser 8) are subsequent versions. The request generated the response 17 responses; 2. Feedback about a subject (receiving feedback 33), which triggered a (computing reputation 42) activity that generated feedback reports (application 41) and reputation reports (reputation 46) The request generated the response 10 responses.

The summary provenance describing the orchestrator’s actions (see Figure 15) shows that it, IMAGINARY-ABACAS 36, receives requests for rides, and stores them generating rideRequests 34. It also generates ridePlans and new versions of rideRequests shown as rideRequests 31. These ride requests and plans in rideRequests 31 are negotiated over using the f95667c8-8911-4f9f-84fa-d830ca71a7a 50 activity. After each negotiation new versions of the ride plans are generated (see v 37, v 30 and v 53). The ride plans v 30 and v 53 are used in responses that are displayed in the GUI username 52.

The summary provenance that describes the SmartShare mobile application’s actions (see Figure 16) shows that a users (username 52), log in to the application and the pages that they navigated. The users view two types of home page entities 100 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

(270f811e67b0437b1577caec9b504395 47 and 4a7d97a20e726c711cac434702cd100b 26), this shows that a driver and commuter logged in. The username 52 agents made requests to the reputation manager and orchestrator, and used the responses on the applicationâ&#x20AC;&#x2122;s page. This summary shows that the users viewed the page showing their old ride offers (oldOffers 25) before submitting their feedback, this is indicated in the summary with the use of a double weighted edge between oldOffers 25 and T 11.

c SmartSociety Consortium 2013-2017

101 of 105

type: cas:ChangingView

f154347368eeeae8bc6bdfcd34d0c32d

a271bb31-f67d-4624-8755-081fdf43e216

type: cas:Request

type: cas:SendingRequest

type: cas:ReceivingRequest

type: cas:ChangingView

type: cas:View

f154347368eeeae8bc6bdfcd34d0c32d

type: cas:Response

user_570a90bfbf8c7eab5dc5d4e26832d5b1/v/0

type: cas:ChangingView

type: cas:View

7a32156ce6fbc55e2fdb207948de2392

7a32156ce6fbc55e2fdb207948de2392

type: cas:View

type: cas:View

type: cas:Response

user_570a90bfbf8c7eab5dc5d4e26832d5b1

270f811e67b0437b1577caec9b504395

type: cas:View

9cb249c4f9eb2fa381bef42906bcd7cd

type: cas:ChangingView

type: cas:View

81e0da7793e6e4dc84e102aea75850a3

81e0da7793e6e4dc84e102aea75850a3

type: cas:ChangingView

4cab1c48921a39c33d2c3e2afdee8df4

4cab1c48921a39c33d2c3e2afdee8df4

9cb249c4f9eb2fa381bef42906bcd7cd

92c66994-ad68-4727-aeac-b2f01b857d38

d8ac6297-b627-413d-a35e-9f44fe9bf13a

type: cas:ReceivingRequest

7a9c21d9-4eca-44e2-86b5-ce93a79ad950

type: cas:View

type: cas:ChangingView

type: cas:Request

type: cas:SendingRequest

type: cas:SendingRequest

102 of 105 type: cas:Response

21dd4288-8b03-4089-b9cc-3b052398dd0c

type: cas:ReceivingRequest

5257f375-7a0c-478d-a057-4204ca58ef6a

f8774341-62ba-4d94-8760-821eb723ce28

type: cas:SendingRequest

type: cas:ReceivingRequest

ac5d0190-f72a-48ec-9357-eaf367a738f8

type: cas:ReceivingRequest

996941e6-1492-4eaa-9372-23905445d5c3

65b89625-ef94-4f0d-ab02-a56f92689594

type: cas:Request

6

ce8f6db0-5fd9-4875-a107-c9e878b22ef2

2f637441-bd62-45c4-b18c-a85a594e403f

da6643bce9489104da951aec30a71dbd

type: cas:SendingRequest

454b0af7-f327-460a-8fa4-22b05f54b2ab

e8a1cceefd0f2a94d08e9960d44235a3

type: cas:Response

type: cas:Response

type: cas:ReceivingRequest

aae69bff-43f1-4d78-90f0-18cfc1899419

type: cas:Request

type: cas:ChangingView

7

type: cas:ReceivingRequest

96fec054-a73d-4182-b4ae-1e7665f004f9

482/v/1

type: cas:ReceivingRequest

type: cas:Response

34514d6e-d195-4330-abba-ebc796eaccd4

type: cas:Request

c61456f8-6730-4bdb-84e9-3683a263e603

type: cas:RideRequest

type: cas:ReceivingRequest

type: cas:Response

457/v/3

type: cas:Response

profile/v/0.0

5fb159dc-ffe3-46b4-b622-9860788d7360

4342

type: cas:View

type: cas:Request

d2f0d50f-32a2-410a-82e6-9ce7d469ffb5

type: cas:ReceivingRequest

4343

type: cas:RideRequest

483/v/1

type: cas:Response

type: cas:Response

type: cas:SendingRequest

type: cas:ChangingView

970aac82c4d4e223fefa7975271ae968

type: cas:Response

type: cas:Response

ff7158f1-3387-43ca-8625-4608f8dfee4b

type: cas:ReceivingRequest

9

type: cas:Request

type: cas:ChangingView

6b99a51c7f6206d478c4fa6f0e0b4140

type: cas:Response

1e1dff55-a502-48e1-8f8f-d3d79129cbbd

type: cas:Response

6cdf7066-e58d-4691-a580-9fffab5345df

type: cas:SendingRequest

type: cas:ReceivingRequest

type: cas:ReceivingRequest

51357ebc07e3a968d635ca7400a28133

type: cas:SendingRequest

10

type: cas:ChangingView

type: cas:View

type: cas:Response

ea8ce63a-1857-40c5-92a7-ac0ec878e3f8

62991b16-949c-4d84-9e0b-77f38f64f914

2e1874dfe2780629991619c42f0660e7

2e1874dfe2780629991619c42f0660e7

type: cas:ChangingView

f025b612b58e2951078514df93cad031

type: cas:Request

type: cas:ReceivingRequest

cf97f90f-67cf-4667-ac0d-8fb094042ee8

type: cas:View

f025b612b58e2951078514df93cad031

ed63d356-2e03-403f-b58f-8592581719ac

type: cas:ReceivingRequest

f621c4a9-c92e-4286-b01d-f9779acd8d0c

type: cas:SendingRequest

b33ef712-110b-4120-a7d3-fe0172b872b8

type: cas:Request

4345

user_b5f3729e5418905ad2b21ce186b1c01d

type: cas:View

type: cas:SendingRequest

type: cas:View

type: cas:View

type: cas:View

type: cas:ReceivingRequest

c0ac5dc2-d7ba-4b51-8518-d915a35728f0

type: cas:SendingRequest

type: cas:ChangingView

7c65bc1b-a3d2-434c-aec0-279ae4386ecd

type: cas:View

7db2b71b867d00210c4b7dc38e48f4cb

type: cas:Response

fa364757-877c-4152-bb4a-30468f57e8cf

9

7db2b71b867d00210c4b7dc38e48f4cb

type: cas:Request

type: cas:ChangingView

b9c675876da87f3a88416aa2442b6155

fred

type: cas:Peer

21886e75-7f2c-4ce0-bced-c2264d90d0ac

type: cas:ChangingView

7c296a36-24c1-4c57-9d5e-4a4040d26dc2

type: cas:ChangingView

f4d630d180d17c5a1ed1423c6b413e23

f4d630d180d17c5a1ed1423c6b413e23

b9c675876da87f3a88416aa2442b6155

4339

type: cas:Request

97c337dd74b2440372f2ced7d6b1cd27

970aac82c4d4e223fefa7975271ae968

type: cas:View

64f635a4-cb5f-4595-98c3-3afbde253816

type: cas:ChangingView

c699d453e5a73bb208934f9a36bfca5b

type: cas:Response

type: cas:View

337b3339d5ebdb545127c8bd2e4a26d0

type: cas:SendingRequest

439080a5-858a-463b-95d4-13a8170474f4

75c7b1f3-698d-4f87-bd0b-36340c582005

type: cas:Request

6b99a51c7f6206d478c4fa6f0e0b4140

4346

type: cas:ReceivingRequest

type: cas:Request

type: cas:View

6b99a51c7f6206d478c4fa6f0e0b4140

71c1ae76-b361-4ef1-959a-a44abf51df9a

8f9a37ee-ebae-4ff9-bc15-78a7c685fc4e

type: cas:SendingRequest

type: cas:View

type: cas:ChangingView

type: cas:ReceivingRequest

ad56d851-f41d-4aca-97f1-4e28f2696dcc

51357ebc07e3a968d635ca7400a28133

250eac2e-f36d-4c02-9a81-df0329f125ed

type: cas:ChangingView

type: cas:View

b12506b733c3808980f30156873d837d

b12506b733c3808980f30156873d837d

type: cas:Request

cb5f3651-0926-4bbb-91d4-663ef3fb7547

type: cas:SendingRequest

d344af4a-f272-4afc-8779-09ac67e4c380

type: cas:SendingRequest

2c7037ec-68a0-4b49-a649-a49fe4e83ca9

type: cas:ChangingView

6442960f-a813-4dd5-bc2a-08faa377308d

95a103be-47d0-4b8c-b81c-0ef4687f545d

337b3339d5ebdb545127c8bd2e4a26d0

type: cas:ReceivingRequest

cf8d63bb-bd02-4239-894d-1cd65d5e400e

type: cas:ReceivingRequest

3231b444-c408-499e-b7df-80c87ed3ff29

type: cas:SendingRequest

c8fdb505-c247-4302-b239-5617c5b658d5

8

type: cas:View

user_b5f3729e5418905ad2b21ce186b1c01d

type: cas:Peer

337b3339d5ebdb545127c8bd2e4a26d0

type: cas:Request

type: cas:ChangingView

80e8856c-efe0-48a0-b28f-e61d4bc0100d

type: cas:Request

42366f24-f763-4279-a921-665810953934

6

c236a8f6-b313-41e8-b338-714c7a369e2c

type: cas:SendingRequest

type: cas:ReceivingRequest

754820a8-0192-46de-a741-bf164bbd7b05

type: cas:Request

type: cas:ChangingView

213cdaff-8bcb-4303-ae37-7e9cfc09e8a3

type: cas:SendingRequest

57c4b6b6-2f86-4ea2-a873-6f04dc45db2c

301fa486-21b5-451c-96f1-10dc5971c714

type: cas:ChangingView

7cdf7ade-b2dd-4fe9-b131-bcc6c375321c

user_b5f3729e5418905ad2b21ce186b1c01d/v/0

ff5ca73b851baf7b020da98e46c11e8e

4632ffc069749512ffffb317a3f54f24

type: cas:View

ff5ca73b851baf7b020da98e46c11e8e

type: cas:View

4632ffc069749512ffffb317a3f54f24

type: cas:ChangingView

6ea564cdf5ddf69ffa2c46c79ce6e40a

2feaf511-4246-416e-bb40-f91c8d3646c4

type: cas:ChangingView

type: cas:View

6ea564cdf5ddf69ffa2c46c79ce6e40a

c874fc0b-ec45-4cad-8990-16860ed5f445

type: cas:Request

type: cas:RideRequest

458/v/3

type: cas:RideRequest

type: cas:SendingRequest

87be9218-6bbf-420d-af4e-89012fbec7a5

type: cas:Request

4340

b9c675876da87f3a88416aa2442b6155

type: cas:Request

type: cas:SendingRequest

be607081-ba21-4b9c-8957-75b7193dab51

type: cas:SendingRequest

2bc4281d-88c8-4970-a0e7-482f815bba42

type: cas:View

c5babd205f28577158dc37262f106677

c5babd205f28577158dc37262f106677

type: cas:SendingRequest

1f9ba53d-a955-461e-9d11-f80c6f36a1ca

ad7c93dd-8a37-4121-9a5a-03c78a0b6733

5def59a5-4cee-46c4-bd0c-d9cd4548609d

type: cas:ChangingView

type: cas:View

a1a24cfc941985da1559abec0582ce1f

type: cas:SendingRequest

81844741-2d58-428a-bd18-ff6a59ddd9d0

type: cas:View

type: cas:ReceivingRequest

d8e292af-073c-4425-b024-996e7a628df9

7217eaa0-7faf-4275-adcd-5fc6789e966d

type: cas:ReceivingRequest

type: cas:Request

022a72af-1665-49c3-96ca-21d6de7c8579

type: cas:ChangingView

66a6a89fda8adc109674b33f35e17fab

4a7d97a20e726e711eac434702ed100b

5e8a35f5-710e-47e0-b82f-95bd10bd85a2

user_570a90bfbf8c7eab5dc5d4e26832d5b1/profile/v/0.0

9c236151-a563-464d-9fca-7e47085b0903

type: cas:ReceivingRequest

44f94403-7891-41d7-a344-29f574c335de

type: cas:SendingRequest

86f1dde4-2458-4ab6-b546-971faa487a46

type: cas:SendingRequest

c18be18a-fbeb-4207-930d-cd9ece87de5e

user_570a90bfbf8c7eab5dc5d4e26832d5b1

type: cas:Response

a8c7e094-8b22-4221-8e6f-414dc9eedf89

type: cas:SendingRequest

type: cas:Response

51663649-a9cf-498f-88c4-4adf8aa4a559.ttl

type: cas:Response

fa91b625-3f2a-4b04-aa48-ec39e6c3b2ca

10

type: cas:ReceivingRequest

type: http2011:201

type: cas:SendingRequest

type: cas:ReceivingRequest

c877352c-4c8d-47ca-8fbf-d7417f315e8e

a8d495d1-9628-4cab-b039-6a401cfdc78f

be05ae85-f9ee-47f4-9cdc-a99174db4758

4340

type: cas:ComputingResponse

type: cas:Request

type: cas:ReceivingRequest

2be98902-6663-4c4f-967d-9634f2527258

fe1a52f1-bb6d-46ed-b842-99c7e7b4f7c7

user_b5f3729e5418905ad2b21ce186b1c01d

type: cas:Request

type: cas:Response

type: type: task_request_index: task_request_rideQualityThreshold: task_request_agreedRidePlan: task_request_route: task_request_version: task_request_desDateTimeWindowLow: task_request_capacity: task_request_departure_location: task_request_desDateTimeWindowHigh: task_request_depDateTimeWindowLow: task_request_revision: task_request_destination_location: task_request_smoking: task_request_pets: task_request_depDateTimeWindowHigh: task_request_priceBound: task_request_driverAgreedRidePlans: task_request_id: task_request_mode: task_request_user: task_request_comments: task_request_currency: task_request_invalidRidePlans: task_request_potentialRidePlans: task_request_manageBy:

7c8de64b-879c-4c2c-ae3c-165de29856fc

type: cas:SendingResponse

4342

type: cas:Request

rideRequests/558/v/3

type: cas:RideRequest

cas:TaskRequest cas:InvalidTaskRequest 558 0 https://pilot1-api.smart-society-project.eu/ridePlans/278 Route description for agent with username ...

3 2015-11-26T17:08:00+00:00 1 Augsburg, Germany 2015-11-26T17:08:00+00:00 2015-11-26T17:08:00+00:00 3 Gilan, Iran No No 2015-11-26T17:08:00+00:00 1 null 56572e9d5b14b5aa00f6b86d driver pre_2:user_b5f3729e5418905ad2b21ce186b1c01d Comments for agent with username ...

Euro null null

4346

type: cas:Response

rideRequests/558

type: cas:RideRequest

type: cas:ComputingResponse

Route description for agent with username ...

2 2015-11-26T17:08:00+00:00 1 Augsburg, Germany 2015-11-26T17:08:00+00:00 2015-11-26T17:08:00+00:00 2 Gilan, Iran No No 2015-11-26T17:08:00+00:00 1 https://pilot1-api.smart-society-project.eu/ridePlans/278 56572e9d5b14b5aa00f6b86d driver pre_2:user_b5f3729e5418905ad2b21ce186b1c01d Comments for agent with username ...

Euro null null

type: cas:RideRequest

cas:SendingResponse uuid:fb43f9b4-0f43-4bf0-8ccc-5c12f0814001 uuid:8134864c-5784-4734-8a18-c61de98d9471

type: cas:Task

type: startTime: endTime:

type: http2011:201

ridePlans/278/v/1 type: cas:ComputingNegotiation

f95667e8-8911-4f9f-84fa-d83f0ca71a7a

type: type: task_request_desDateTimeWindowHigh: task_request_smoking: task_request_driverAgreedRidePlans: task_request_departure_location: task_request_index: task_request_desDateTimeWindowLow: task_request_rideQualityThreshold: task_request_id: task_request_comments: task_request_user: task_request_mode: task_request_route: task_request_agreedRidePlan: task_request_currency: task_request_destination_location: task_request_version:

type: http2011:201

type: type: task_smoking: task_comments: task_pets: task_currency: task_commuterOpinions: task_agreedCommuters: task_priceRange: task_rejectedCommuters: task_depDateTimeWindowHigh: task_index: task_id: task_version: task_driverOpinions: task_rejectedDriver: task_potentiallyAgreedDriver: task_depDateTimeWindowLow: task_route: task_potentiallyAgreedCommuters: task_potentialDriver: task_desDateTimeWindowHigh: task_revision:

ridePlans/278/v/0

557/v/0

type: cas:ComputingNegotiation

type: cas:Response

ridePlans/278/v/2

cas:TaskRequest 557 0

rideRequests/557

type: cas:TaskRequest

type: task_request_index: task_request_rideQualityThreshold: task_request_agreedRidePlan: task_request_route: task_request_version: task_request_desDateTimeWindowLow: task_request_capacity: task_request_departure_location: task_request_desDateTimeWindowHigh: task_request_depDateTimeWindowLow: task_request_revision: task_request_destination_location: task_request_smoking: task_request_pets: task_request_depDateTimeWindowHigh: task_request_priceBound: task_request_driverAgreedRidePlans: task_request_id: task_request_mode: task_request_user: task_request_comments: task_request_currency: task_request_invalidRidePlans: task_request_potentialRidePlans: task_request_manageBy:

type: type: task_request_index: task_request_rideQualityThreshold: task_request_agreedRidePlan: task_request_route: task_request_version: task_request_desDateTimeWindowLow: task_request_capacity: task_request_departure_location: task_request_desDateTimeWindowHigh: task_request_depDateTimeWindowLow: task_request_revision: task_request_destination_location: task_request_smoking: task_request_pets: task_request_depDateTimeWindowHigh: task_request_priceBound: task_request_driverAgreedRidePlans: task_request_id: task_request_mode: task_request_user: task_request_comments: task_request_currency: task_request_invalidRidePlans: task_request_potentialRidePlans: task_request_manageBy:

type: cas:ReceivingRequest

type: cas:Response

type: cas:FeedbackReport

cas:TaskRequest 557 0

557/v/3

type: cas:RideRequest

Route description for agent with username ...

0 2015-11-26T17:06:00+00:00 1 Augsburg, Germany 2015-11-26T21:06:00+00:00 2015-11-26T17:06:00+00:00 0 Gilan, Iran No No 2015-11-26T21:06:00+00:00 1 null 56572e425b14b5aa00f6b804 commuter pre_2:user_570a90bfbf8c7eab5dc5d4e26832d5b1 Comments for agent with username ...

Euro null null

type: http2011:201

type: cas:RideRequest

type: startTime: endTime:

type: cas:ReceivingFeedback

ebc2f13dc7aeb46cbedb0949e8088d7877a1a7fb3ae40633c285544c

type: startTime: endTime:

cas:SendingResponse uuid:bd4f3aae-0abb-468a-8f15-ba8ff1da48ba uuid:bac40f32-2c2a-4998-a11a-d6439b0acdf9

cas:SendingResponse uuid:02de7097-3a76-48df-ac97-d5a9aab327fd uuid:0438140e-e2d7-4ca3-9909-c61d203367b9

type: cas:Response

type: cas:ComputingReputation

4d802d49-e77b-4b57-9d47-9bdbd7d87ce4

cef4f57c-58db-41c8-b8c2-1e1662b5ef32

c2ae615f-7342-49fb-85a0-064cb6c831fa

type: http2011:201

type: cas:Task

ridePlans/278

type: cas:SendingResponse

1be814fa5d4891fd470c184d1dab6aad634ab48bd2537a2010acd626

type: cas:ComputingResponse

478/

type: cas:OrchestrationPeer

type: cas:Response

type: cas:ReputationReport type: cas:Response type: cas:Request

activity/computing_reputation/ebc2f13dc7aeb46cbedb0949e8088d7877a1a7fb3ae40633c285544c

type: cas:Response

application/6/reputation/1243/

1be814fa5d4891fd470c184d1dab6aad634ab48bd2537a2010acd626

f66ccba9-2aac-4a78-b02b-dbdce4887ca9

type: cas:Response

4343

type: cas:ReceivingRequest

cas:TaskRequest cas:InvalidTaskRequest 557 0 https://pilot1-api.smart-society-project.eu/ridePlans/278 Route description for agent with username ...

3 2015-11-26T17:06:00+00:00 1 Augsburg, Germany 2015-11-26T21:06:00+00:00 2015-11-26T17:06:00+00:00 3 Gilan, Iran No No 2015-11-26T21:06:00+00:00 1 null 56572e425b14b5aa00f6b804 commuter pre_2:fred Comments for agent with username ...

Euro null null

Route description for agent with username ...

2 2015-11-26T17:06:00+00:00 1 Augsburg, Germany 2015-11-26T21:06:00+00:00 2015-11-26T17:06:00+00:00 2 Gilan, Iran No No 2015-11-26T21:06:00+00:00 1 https://pilot1-api.smart-society-project.eu/ridePlans/278 56572e425b14b5aa00f6b804 commuter pre_2:fred Comments for agent with username ...

Euro null null

b86364bf-c561-452c-88cd-d17e6c025953

type: task_request_index: task_request_rideQualityThreshold: task_request_agreedRidePlan: task_request_route: task_request_version: task_request_desDateTimeWindowLow: task_request_capacity: task_request_departure_location: task_request_desDateTimeWindowHigh: task_request_depDateTimeWindowLow: task_request_revision: task_request_destination_location: task_request_smoking: task_request_pets: task_request_depDateTimeWindowHigh: task_request_priceBound: task_request_driverAgreedRidePlans: task_request_id: task_request_mode: task_request_user: task_request_comments: task_request_currency: task_request_invalidRidePlans: task_request_potentialRidePlans: task_request_manageBy:

557/v/2

type: cas:RideRequest

cas:InvalidTask cas:Task 1-1 pre_2:fred https://pilot1-api.smart-society-project.eu/users/ed/opinionsDriverCommuters/fred 278 pre_2:user_b5f3729e5418905ad2b21ce186b1c01d No 56572e9e5b14b5aa00f6b87a pre_2: Route description for agent with username ... pre_17:nil 2015-11-26T17:08:00+00:00 https://pilot1-api.smart-society-project.eu/users/fred/opinionsCommuterDrivers/ed Euro 0 Comments for agent with username ...

0edcc5bf-db95-41bf-9d92-2d747a22568a

type: type: task_priceRange: task_potentiallyAgreedCommuters: task_driverOpinions: task_index: task_potentiallyAgreedDriver: task_smoking: task_id: task_rejectedDriver: task_route: task_agreedCommuters: task_depDateTimeWindowHigh: task_commuterOpinions: task_currency: task_version: task_comments:

Euro Gilan, Iran 1

cas:Task cas:InvalidTask No Comments for agent with username ...

No Euro https://pilot1-api.smart-society-project.eu/users/fred/opinionsCommuterDrivers/ed pre_2:fred 1-1 pre_17:nil 2015-11-26T17:08:00+00:00 278 56572e9e5b14b5aa00f6b87a 1 https://pilot1-api.smart-society-project.eu/users/ed/opinionsDriverCommuters/fred pre_2: pre_2: 2015-11-26T17:08:00+00:00 Route description for agent with username ... pre_17:nil pre_2: 2015-11-26T17:08:00+00:00 2

type: cas:Task

ridePlans/558/v/3

type: cas:GeneratingComposition

cas:InvalidTaskRequest cas:TaskRequest 2015-11-26T21:06:00+00:00 No null Augsburg, Germany 557 2015-11-26T17:06:00+00:00 0 56572e425b14b5aa00f6b804 Comments for agent with username ... pre_2:fred commuter Route description for agent with username ...

rideRequests/557/v/1

type: cas:SubmitingTaskRequest

receiving_request_557

user_570a90bfbf8c7eab5dc5d4e26832d5b1

activity/receiving_reputationResource/1be814fa5d4891fd470c184d1dab6aad634ab48bd2537a2010acd626

type: cas:FeedbackReport type: cas:Response

IMAGINARY-ABACAS

type: cas:Response

application/6/reputation/1241/

d39f37e0-b556-4f62-8bbf-25b0a1b927b7

2e1eebbf-bfc3-4a10-a5a4-f76c612804e9

cas:SendingResponse uuid:efb31d06-38cb-499f-aeea-56007a2c91c6 uuid:881bb08a-ea78-42de-ade7-2c3c12e42dd3

1251613d-7639-4e6d-9ced-7a651e2bf0ef

cas:Task cas:InvalidTask No Comments for agent with username ...

No Euro https://pilot1-api.smart-society-project.eu/users/fred/opinionsCommuterDrivers/ed pre_17:nil 1-1 pre_17:nil 2015-11-26T17:08:00+00:00 278 56572e9e5b14b5aa00f6b87a 0 https://pilot1-api.smart-society-project.eu/users/ed/opinionsDriverCommuters/fred pre_2: pre_2: 2015-11-26T17:08:00+00:00 Route description for agent with username ... pre_2:fred pre_2: 2015-11-26T17:08:00+00:00 1

558/v/1

19d8b22a-6cdd-4d13-a01a-8bd362fcff7f

ridePlans/557/v/3

type: type: task_smoking: task_comments: task_pets: task_currency: task_commuterOpinions: task_agreedCommuters: task_priceRange: task_rejectedCommuters: task_depDateTimeWindowHigh: task_index: task_id: task_version: task_driverOpinions: task_rejectedDriver: task_potentiallyAgreedDriver: task_depDateTimeWindowLow: task_route: task_potentiallyAgreedCommuters: task_potentialDriver: task_desDateTimeWindowHigh: task_revision:

2015-11-26T17:08:00+00:00 Euro Gilan, Iran 558 1

cas:InvalidTaskRequest cas:TaskRequest No null Augsburg, Germany 0 Comments for agent with username ...

56572e9d5b14b5aa00f6b86d driver pre_2:user_b5f3729e5418905ad2b21ce186b1c01d Route description for agent with username ...

type: cas:ReputationReport type: cas:Response type: cas:Request

application/6/feedback/477/

776a356953411087b29e28e5aa07b02ae031db9fbbd15fca40540bb9

type: cas:ReceivingFeedback

type: cas:ComputingReputation

activity/computing_reputation/776a356953411087b29e28e5aa07b02ae031db9fbbd15fca40540bb9

application/6/reputation/1240/

type: cas:ReceivingRequest

activity/receiving_reputationResource/7a32b07a1968e11957430a687b97512e89dd72a9d8217fca0d7770fa

e491e7eb-e0f1-4e41-9afd-0b8ad03c78f9

type: startTime: endTime:

type: http2011:201

type: cas:Response

type: type: task_request_smoking: task_request_driverAgreedRidePlans: task_request_departure_location: task_request_rideQualityThreshold: task_request_comments: task_request_id: task_request_mode: task_request_user: task_request_route: task_request_agreedRidePlan: task_request_desDateTimeWindowLow: task_request_currency: task_request_destination_location: task_request_index: task_request_version:

rideRequests/558/v/0

18d5c871-fa4b-4fda-a289-df9d50b135a4

type: cas:SendingResponse

receiving_request_558

type: cas:SubmitingTaskRequest

cas:TaskRequest 558 0

type: cas:Response

278

7a32b07a1968e11957430a687b97512e89dd72a9d8217fca0d7770fa

type: cas:Response type: cas:ReputationReport

7a32b07a1968e11957430a687b97512e89dd72a9d8217fca0d7770fa

Route description for agent with username ...

0 2015-11-26T17:08:00+00:00 1 Augsburg, Germany 2015-11-26T17:08:00+00:00 2015-11-26T17:08:00+00:00 0 Gilan, Iran No No 2015-11-26T17:08:00+00:00 1 null 56572e9d5b14b5aa00f6b86d driver pre_2:user_b5f3729e5418905ad2b21ce186b1c01d Comments for agent with username ...

Euro null null

cas:TaskRequest 558 0

type: http2011:201

fcb81727-1e48-45c8-aadb-71d972a5b685

type: task_request_index: task_request_rideQualityThreshold: task_request_agreedRidePlan: task_request_route: task_request_version: task_request_desDateTimeWindowLow: task_request_capacity: task_request_departure_location: task_request_desDateTimeWindowHigh: task_request_depDateTimeWindowLow: task_request_revision: task_request_destination_location: task_request_smoking: task_request_pets: task_request_depDateTimeWindowHigh: task_request_priceBound: task_request_driverAgreedRidePlans: task_request_id: task_request_mode: task_request_user: task_request_comments: task_request_currency: task_request_invalidRidePlans: task_request_potentialRidePlans: task_request_manageBy:

558/v/2

type: cas:Response

type: cas:Response

type: cas:ReceivingRequest

activity/receiving_subjectInfoByURI/c536c1e9b9c39492e808721458575f7048e728fa8b56ce4f6a820922

type: task_request_index: task_request_rideQualityThreshold: task_request_agreedRidePlan: task_request_route: task_request_version: task_request_desDateTimeWindowLow: task_request_capacity: task_request_departure_location: task_request_desDateTimeWindowHigh: task_request_depDateTimeWindowLow: task_request_revision: task_request_destination_location: task_request_smoking: task_request_pets: task_request_depDateTimeWindowHigh: task_request_priceBound: task_request_driverAgreedRidePlans: task_request_id: task_request_mode: task_request_user: task_request_comments: task_request_currency: task_request_invalidRidePlans: task_request_potentialRidePlans: task_request_manageBy:

type: cas:TaskRequest

type: http2011:201

8599f28d-46ef-48df-9043-579a47518c23

type: cas:Response

response/4342

c536c1e9b9c39492e808721458575f7048e728fa8b56ce4f6a820922

type: cas:ComputingResponse

c536c1e9b9c39492e808721458575f7048e728fa8b56ce4f6a820922

38b66c10-b6b7-4ff1-b0b4-fe0db6a957bd

type: cas:SendingRequest

type: cas:SendingResponse

activity/sending_subjectInfoByURI/edeb9e19f7a2ef6c29b3b3a3ddfaa44452d3816b45d8b6c5d80df126

type: cas:ReceivingRequest

activity/receiving_subjectInfoByURI/edeb9e19f7a2ef6c29b3b3a3ddfaa44452d3816b45d8b6c5d80df126

edeb9e19f7a2ef6c29b3b3a3ddfaa44452d3816b45d8b6c5d80df126

type: cas:Request

type: cas:Response

0721b159-e0a6-44d5-b107-29437560df59

response/4340

type: cas:Response

rs/

type: http2011:201

type: cas:ComputingResponse

type: cas:SendingResponse

type: cas:Response

4341

type: cas:ComputingResponse

type: cas:ReceivingRequest

type: cas:SendingResponse

4341

776a356953411087b29e28e5aa07b02ae031db9fbbd15fca40540bb9

776a356953411087b29e28e5aa07b02ae031db9fbbd15fca40540bb9

type: cas:ReceivingRequest

776a356953411087b29e28e5aa07b02ae031db9fbbd15fca40540bb9

type: cas:Request

activity/receiving_subjectInfoByURI/4800b595c43806426b3b04f2aa5764245acacd1cc0986d345cc38e28

4800b595c43806426b3b04f2aa5764245acacd1cc0986d345cc38e28

type: cas:Response type: cas:ReputationReport

4800b595c43806426b3b04f2aa5764245acacd1cc0986d345cc38e28

type: cas:Request

4345

type: cas:Response

0148f048-4e47-4aed-ab45-4b968d9c1166

type: cas:Response

response/4345

application/6/reputation/1242/

type: cas:Response

1235/

1236/

type: cas:Response

type: cas:Response

3/ type: cas:Response

1/

4339

type: cas:Request

type: cas:Response

application/6/subject/byURI/https%3A%2F%2Fpilot1-pm.smart-society-project.eu%2Fusers%2Fuser_b5f3729e5418905ad2b21ce186b1c01d/v/2/

type: cas:Response

application/6/subject/byURI/https%3A%2F%2Fpilot1-pm.smart-society-project.eu%2Fusers%2Fuser_b5f3729e5418905ad2b21ce186b1c01d/

type: cas:Response

type: http2011:201

response/4339

type: cas:SendingResponse

type: cas:SendingResponse

type: cas:Response

4344

4344

type: cas:Request

type: cas:Response

type: cas:Response

type: cas:ReceivingRequest

1238/

type: cas:ComputingResponse

ebc2f13dc7aeb46cbedb0949e8088d7877a1a7fb3ae40633c285544c

ebc2f13dc7aeb46cbedb0949e8088d7877a1a7fb3ae40633c285544c

ebc2f13dc7aeb46cbedb0949e8088d7877a1a7fb3ae40633c285544c

1237/

007b4e9369d8e3a3674de338fcf45c871a5377088cea8fdb906c3a3f

type: cas:ComputingResponse

activity/sending_subjectInfoByURI/007b4e9369d8e3a3674de338fcf45c871a5377088cea8fdb906c3a3f

type: cas:Response

type: cas:ReceivingRequest

3f04c1e9-bb09-4a10-b9ea-0ab8ea90f7da

type: cas:Response

activity/receiving_subjectInfoByURI/007b4e9369d8e3a3674de338fcf45c871a5377088cea8fdb906c3a3f

type: cas:ReputationPeer

1/ type: cas:Response

type: cas:Response

type: cas:Response

type: cas:Response

3/

application/6/subject/byURI/https%3A%2F%2Fpilot1-pm.smart-society-project.eu%2Fusers%2Fuser_570a90bfbf8c7eab5dc5d4e26832d5b1/

application/6/subject/byURI/https%3A%2F%2Fpilot1-pm.smart-society-project.eu%2Fusers%2Fuser_570a90bfbf8c7eab5dc5d4e26832d5b1/v/2/

type: cas:Response

type: cas:Peer

c SmartSociety Consortium 2013-2017

Deliverable D2.4

Figure 12: The provenance generated for two users organising a ride and leaving feedback.

This figure is used to illustrate the scale of provenance summarised in Figure 13, and hence we do not expect you to read the details.

http://www.smart-society-project.eu

att

c SmartSociety Consortium 2013-2017

gen

assoc

der

spe

der

use

gen att

use

spe

activity_16 (6)

assoc use

der

use

att

gen der

assoc

assoc

assoc

use

use

gen

der

use

uuid_12 (6)

der

der der der gen

der

response_17 (6)

gen der att

request_19 (2)

gen

att

alt der

use assoc

activity_28 (10)

use

request_18 (4)

receiving_submittedFeedback_45 (2)

sending__15 (6)

der altspe

der

rs_27 (1)

response_10 (2)

computing_reputation_42 (2)

reputation_46 (4)

application_41 (7)

gen

receiving_feedback_33 (2)

att

T_1 (9) spe

att

use use

gen der der

der

assoc

uuid_13 (13)

use

response_43 (4)

alt

use

att der

der

https%3A%2F%2Fpilot1-pm.smart-society-project.eu%2Fusers%2Fuser__8att(6)

spe

https%3A%2F%2Fpilot1-pm.smart-society-project.eu%2Fusers%2Fuser__32 (2)

pilot1-_23 (4) der

att

use assoc use use

derspe

der

use gen der der

att spe

der der

der

pilot1-client.smart-society-project.eu_14 (10)

spe

der spe

T_44 (3)

der

der

T_11 (23)

der

spe

spe

gen att pilot1-client.smart-society-project.eu_20 (12) gen

att gen

4a7d97a20e726e711eac434702ed100b_26 (1)

pilot1-client.smart-society-project.eu_7 (22)

spe

270f811e67b0437b1577caec9b504395_47 (1)

use

der

gen

assoc

att

gen

uuid_24 (4)

der

der

uuid_4 (28)

use use assoc

uuid_3 (13)

der

use

username_52 (3)

uuid_9 (4)

assoc

use

att

gen

rideRequests_38 (4)

oldOffers_25 (3)

der der der

uuid_22 (9)

der

att

ridePlans_5 (1)

der

gen

gen

der

att

gen

assoc

der

assoc

use

uuid_6 (2)

use

spe der

der spe

gen

use

gen

der

v_53 (2)

der

der

att der

use use assoc

gen

gen use

derspe

der

rideRequests_21 (8)att

ridePlans_35 (2)

gen

assoc

0edcc5bf-db95-41bf-9d92-2d747a22568a_29 (1)

use

f95667e8-8911-4f9f-84fa-d83f0ca71a7a_50 (1)

7c65bc1b-a3d2-434c-aec0-279ae4386ecd_48 (1)

gen att

gen att

v_37 (1)

v_30 (2)

spe

att

rideRequests_34 (2)

derspe

rideRequests_31 (6)

d39f37e0-b556-4f62-8bbf-25b0a1b927b7_51 (1)

c2ae615f-7342-49fb-85a0-064cb6c831fa_2 (1)

19d8b22a-6cdd-4d13-a01a-8bd362fcff7f_49 (1)

uuid_40 (2)

gen

uuid_39 (4)

assoc

IMAGINARY-ABACAS_36 (1)

assoc

gen

receiving_request_55_54 (2)

Deliverable D2.4 c SmartSociety Consortium 2013-2017

Figure 13: Number of triples in the provenance collected by the SmartShare application

103 of 105

c SmartSociety Consortium 2013-2017

Deliverable D2.4

Figure 14: Close up of the provenance summary for the reputation service

Figure 15: Close up of the provenance summary for the orchestration service

104 of 105

http://www.smart-society-project.eu

Deliverable D2.4

c SmartSociety Consortium 2013-2017

Figure 16: Close up of the provenance summary for the mobile application

c SmartSociety Consortium 2013-2017

105 of 105