SmartSociety Hybrid and Diversity-Aware Collective Adaptive Systems When People Meet Machines to Build a Smarter Society
Grant Agreement No. 600584
Deliverable D2.2 Working Package WP2
Provenance, Trust, Reputation and Big Data Dissemination Level 1 (Confidentiality): Delivery Date in Annex I: Actual Delivery Date Status2 Total Number of pages: Keywords:
1
PU 31/1/2013 December 23, 2014 F 65 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 65
Deliverable D2.2
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable D2.2
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 Provenance, Trust, Reputation and Big Data Luc Moreau, SOTON Lue Moreau, SOTON Simone Fischer-H¨ ubner, KAU 3 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
List of Contributors Partner Acronym UoS UoS
4 of 65
Contributor Heather Packer Luc Moreau
http://www.smart-society-project.eu
Deliverable D2.2
c SmartSociety Consortium 2013-2017
Executive Summary The objectives of this deliverable are to show how models of provenance, trust and reputation can be used at scale within HDA-CASs to support transparency and accountability. Concretely, this report aims to address the following research challenges defined in the DOW: how to model trust, provenance and reputation at scale; and how to promote trust in large scale social computations by improving the transparency and accountability of a system and providing accounts to the users. We address scalability challenges through a provenance templating approach and summarisation techniques; and transparency and accountability challenges by identifying core principles, developing a model for transparency and accountability, and providing reputation and explanation services supporting transparency and accountability in HDA-CASs. The core contribution of the deliverable is presented in journal submission in Appendix A and a vocabulary for accountability in HDA-CASs in Appendix B. The deliverable also presents how we address these challenges in the Ride Share demonstrator.
c SmartSociety Consortium 2013-2017
5 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
Table of Contents 1 Introduction
7
2 Overview of Contributions
8
3 Integration in the RideShare Demonstrator
10
3.1
Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2
Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3
End to End Provenance Integration . . . . . . . . . . . . . . . . . . . . . . . 19
3.4
APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Rideshare Demonstrator and Accountability
27
5 Links with Other Work Packages
31
6 Future Work
32
A Submitted paper: Semantics and Provenance for Accountable Smart City Applications B HDA-CASs Vocabulary
6 of 65
34 56
http://www.smart-society-project.eu
Deliverable D2.2
1
c SmartSociety Consortium 2013-2017
Introduction
SmartSociety’s aim is to provide new insight to design principles, operating principles, and adaptation principles of hybrid and diversity-aware collective adaptive systems (HDACAS). Universally, such systems are a composition of various heterogeneous users, hardware and software components forming a complex socio-technical system. Reputation plays a key part in socio-technical systems because it is used to motivate the use of services and incentivise users to behave in a certain manner. Currently, there is a lack of transparency and accountability for systems maintaining reputation especially in the domain of HDA CASs. It is believed that techniques improving transparency would increase users’ trust. Provenance data collected from complex systems can be large and overwhelming to technical and non-technical users. For transparency and accountability purposes dedicated techniques are required to make sense of provenance information. Within this context, WP2 is concerned with how models of provenance, trust and reputation can be used at scale within HDA-CASs to support transparency and accountability. Concretely, this report aims to address the following research challenges defined in the DOW: 1. How to model trust, provenance and reputation at scale, challenges pertaining to this include: (a) reducing costs of scale for modelling trust and provenance; (b) building a generic abstract model that could in principle apply at any scale; (c) modelling reputation that works effectively on a broad population. 2. How to promote trust in large scale social computations, by addressing how to: (a) improve the transparency and accountability of a system; (b) improve the ‘feel’ of transparency and accountability to users of a system. This deliverable takes the shape of a journal submission in Appendix A and a vocabulary for accountability in HDA-CASs in Appendix B. The rest of the document presents more concrete aspects related to the Ride Share demonstrator and is organised as follows. In Section 2, we provide an overview of our contributions. Then in Section 3, we present how our accountability framework integrates into the Ride Share demonstrator. In Section 4, we discuss how the explanation peer can be used to provide accountability c SmartSociety Consortium 2013-2017
7 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
for the Ride Share demonstrator. Section 5 describes how our work is linked to other work packages. In Section 6, we outline our future work regarding our services, transparency and accountability.
2
Overview of Contributions
In order to address the challenges outlined in Section 1, we have contributed techniques and models that address scalability, accountability and transparency issues. Specifically, we have focused on the following contributions: • Scalability by Template: The templating approach, prov-template, presented in Section 3.1 and Appendix 1, Milestone MS2, allows the expression of commonly used provenance patterns, up front, as a template, whereas the application can simply focus on recording bindings for instantiating a template. This contribution supports research challenge (1a) as it reduces overhead costs of the peers and network, because the peers only send binding information because they reuse provenance patterns defined in templates. • Scalability by Summarisation: The summarisation techniques presented in Section 3.3 and Appendix 2, Milestone MS2, aggregates provenance types to provide support for graph analysis. It converts provenance paths up to some length k to attributes, referred to as provenance types, and by grouping nodes that have the same provenance types. The summary also includes numeric values representing the frequency of nodes and edges in the original graph. Through a complexity analysis, a quantitative evaluation, and an informal discussion show that this technique is tractable; with small values of k, it can produce useful summaries and can help detect outliers. This contribution supports research challenge (1b), because it offers an abstract technique to model and analyse provenance. • Accountability Principles: Accountability principles are defined in Milestone MS3. Specifically, Milestone MS3 Section 2 defines transparency and accountability use cases for HDA-CASs, and Section 3 describes terms for transparency and accountability for HDA-CASs. This contribution supports challenge (2) by outlining how transparency and accountability can be supported by large scale HDA-CASs. • Accountability as a Service: Accountability as a Service, there are several core functionalities required to make HDA-CASs applications accountable, including: 8 of 65
http://www.smart-society-project.eu
Deliverable D2.2
c SmartSociety Consortium 2013-2017
tracking an application’s actions and decisions; managing feedback about all its components; calculating their reputation; and, providing explanations for all aspects of the system. These accountability functionalities are non-trivial and require substantial design and implementation efforts. Therefore, we have designed a framework to support these functionalities (presented in detail in Appendix A Section 4), which includes the following components:
– Reputation Manager presented in Appendix A Section 4.2 manages feedback reports about a subject entity, generates reputation reports using feedback reports, provides access to its resources via a REST API, and generates provenance data recording interactions with the service and the generation of reputation reports. The Reputation Manager addresses challenge (1c) because it provides a generic service which can be used by HDA-CASs. It also addresses challenge (2a) because it records the provenance about its use and how reputation is generated. – Explanation Peer presented in Appendix A Section 4.3 provides explanations about a provenance element recorded in provenance document using the types defined in the model for accountability and prov d-m. Concretely, prov d-m is the conceptual data model that forms a basis for the W3C provenance (prov) family of specifications. The explanation service also provides a REST API to access its resources. It addresses challenge (2b) because this peer improves the ‘feel’ of transparency and accountability to users.
• Model for Accountability: The model is presented in Appendix A, Section 3, Appendix B and WP6-MS4 describes the vocabulary used to define types used in HDA-CASs. Concretely, the vocabulary focuses on describing three components: (1) agents within a HDA-CASs application, including users, peers, and collectives and their properties; (2) activities; and, (3) entities describing plans, tasks and messages. The vocabulary’s namespace is http://smartsociety-project.github.io/cas/. This model supports challenges (2b) because the model defines types that can be exploited by the explanation peer which can improve users’ understanding of HDACASs. c SmartSociety Consortium 2013-2017
9 of 65
c SmartSociety Consortium 2013-2017
3
Deliverable D2.2
Integration in the RideShare Demonstrator
The Ride Share demonstrator provides a suitable application for integrating the accountability framework, this is because of its social context. It relies on user’s reputation and their reputation is only trusted if they are transparent to its users. A good reputation is the incentive for users to provide good quality services. User accountability is usually a by product of a reputation system and transparency.
3.1
Templates
In order to enable the ride sharing demonstrator to submit binding information, we designed provenance templates (see Section 3.1 and Appendix 1, Milestone MS2) for the various interactions and process performed by the Ride Share peers, with feedback from WP5 and 6. The UI, and orchestrator and reputation managers all submit bindings using the templates described in Table 3.1. Peer Orchestration
Reputation
UI
Template Name post ride request template composition template negotiation template submit feedback template generate reputation template api call template change view template submit request template
Figure 1 3 5 7 9 11 13 15
Table 2 4 6 8 10 12 14 16
Table 1: Summary table of templates.
10 of 65
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable D2.2
var:ui
prov:type cas:UserInterface tmpl:label var:username wasAttributedTo
var:orchestration_manager
wasAssociatedWith
var:posting_task_request wasGeneratedBy
prov:type cas:CompositionManager
wasAssociatedWith
wasAttributedTo
var:submitting_task_request wasAssociatedWith
var:sending_response
wasInformedBy
prov:type dct:hasPart dct:hasPart tmpl:endTime tmpl:startTime
wasInformedBy
var:temp_task_request
wasAssociatedWith
used
var:storing_task wasAssociatedWith
cas:SubmittingTaskRequest var:composing_tasks var:storing_task var:submitting_task_request_end var:submitting_task_request_start
prov:type cas:PostingTaskRequest tmpl:endTime var:post_task_end tmpl:startTime var:post_task_start
prov:type cas:TaskRequest
wasGeneratedBy
var:composing_tasks
wasDerivedFrom
var:task_request
prov:type cas:StoringTask tmpl:endTime var:storing_task_end tmpl:startTime var:storing_task_start
wasGeneratedBy
prov:type cas:SendingResponse tmpl:endTime var:sending_response_end tmpl:startTime var:sending_response_start
var:acknowledgement
prov:type cas:ComposingTasks tmpl:endTime var:composing_tasks_end tmpl:startTime var:composing_tasks_start
prov:type cas:TaskRequest
prov:type cas:Acknowledgement
var:b
Figure 1: Template for posting ride requests. It describes when the orchestration peer receives a ride request and credentials of the submitter. If the post is authorised then the ride request is stored, and it is used to generate ride compositions. Warning: The graphical version of templates are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at post ride request template. Post Ride Request Template, see Figure 1 Variable Type var:ui cas:UserInterface var:orchestration manager cas:OrchestrationManager var:temp task request cas:TaskRequest var:task request var:storing task var:posting task request var:submitting task request
cas:TaskRequest cas:StoringTask cas:PostingTaskRequest cas:SubmittingTaskRequest
var:sending response var:acknowledgement
cas:SendingResponse cas:Acknowledgement
var:composing tasks
cas:ComposingTasks
Description The User Interface. The orchestration manager. An un-stored task request submitted by the UI. A task request. The activity that stored a task. The activity that posted a task request. The activity that handled the submission of a task request. The activity that sent a response. The acknowledgement that was sent after the submitting task request activity. The activity that generated the valid tasks.
Figure 2: Table describing the variables in for the post ride request template
c SmartSociety Consortium 2013-2017
11 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
var:ui
var:composition_manager
wasAttributedTo
prov:type cas:UserInterface tmpl:label var:username
wasAttributedTo
var:task_request
prov:type cas:CompositionManager
wasAssociatedWith
var:composing_tasks
prov:type cas:TaskRequest
wasDerivedFrom
wasAttributedTo
var:task
wasAssociatedWith
var:sending_response
used
prov:type cas:Task
wasDerivedFrom
var:opinion_report
prov:type dct:hasPart dct:hasPart tmpl:endTime tmpl:startTime
cas:ComposingTasks var:authenticate var:generating_composition var:composing_tasks_end var:composing_tasks_start
wasGeneratedBy
var:acknowledgement
wasAttributedTo
prov:type cas:SendingResponse tmpl:endTime var:sending_response_end tmpl:startTime var:sending_response_start
wasGeneratedBy
var:parent_task_request used
prov:type cas:ReputationReport
wasInformedBy
prov:type cas:Acknowledgement
used
wasAssociatedWith
var:generating_composition
prov:type cas:TaskRequest
wasInformedBy
prov:type cas:GeneratingComposition tmpl:endTime var:generating_composition_end tmpl:startTime var:generating_composition_start
wasGeneratedBy
wasAssociatedWith
var:requesting_opinion
var:invalid_task
prov:type cas:RequestingOpinion tmpl:endTime var:requesting_opinion_end tmpl:startTime var:requesting_opinion_start
prov:type cas:Task
var:b
Figure 3: Template for generating compositions for ride matches, which describes the generation of ride plans.Warning: The graphical version of templates are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at composition template . Task Composition Template, see Figure 3 Variable Type var:ui cas:UserInterface var:composition manager cas:CompositionManager var:generating composition cas:GeneratingComposition var:task request cas:TaskRequest var:task cas:Task var:parent task request cas:TaskRequest var:invalid task cas:Task var:opinion report cas:ReputationReport var:requesting opinion cas:RequestingOpinion var:composing tasks var:sending response var:acknowledgement
cas:ComposingTasks cas:SendingResponse cas:Acknowledgement
Description The User Interface. The composition manager. The activity that computes tasks. A task request. A task. A parent task request. An invalid task. An opinion report. The activity that requested an opinion report from the var:reputation manager. The activity that computed tasks. The activity that sent a response. The acknowledgement that was after a sending response.
Figure 4: Table describing the variables for the task composition template 12 of 65
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable D2.2
var:ui
var:negotiation_manager wasAttributedTo
prov:type cas:UserInterface tmpl:label var:username
wasAttributedTo
var:task_request
used
wasAssociatedWith
var:computing_composition
prov:type cas:TaskRequest
wasDerivedFrom wasGeneratedBy
prov:type cas:computingComposition tmpl:endTime var:computing_composition_end tmpl:startTime var:computing_composition_start
wasAttributedTo
var:parent_task_request
prov:type cas:NegotiationManager
var:task
used
prov:type cas:TaskRequest
wasDerivedFrom wasGeneratedBy
var:invalid_task
used
var:opinion_report wasAttributedTo
prov:type cas:ReputationReport
wasInformedBy
wasAssociatedWith
var:requesting_opinion
var:sending_response
wasAssociatedWith
var:composing_tasks wasAssociatedWith
prov:type dct:hasPart dct:hasPart tmpl:endTime tmpl:startTime
wasInformedBy
cas:ComposingTasks var:authenticate var:computing_composition var:composing_tasks_end var:composing_tasks_start
wasGeneratedBy
prov:type cas:Task
prov:type cas:Task
prov:type cas:RequestingOpinion tmpl:endTime var:requesting_opinion_end tmpl:startTime var:requesting_opinion_start
prov:type cas:SendingResponse tmpl:endTime var:sending_response_end tmpl:startTime var:sending_response_start
var:acknowledgement
prov:type cas:Acknowledgement
var:b
Figure 5: Template for computing tasks after a negotiation offer. It describes the generation of ride plans after a user posts a negotiation offer about a ride plan. The generation of ride plans uses submitted offer and ride requests to generate potential rides. Warning: The graphical version of templates are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at negotiation template . Post Negotiation Template, see Figure 5 Variable Type var:ui cas:UserInterface var:negotiation manager cas:NegotiationManager var:generating composition cas:ComputingComposition var:task request cas:TaskRequest var:task cas:Task var:parent task request cas:TaskRequest var:invalid task cas:Task var:opinion report cas:ReputationReport var:requesting opinion cas:RequestingOpinion var:negotiating tasks
cas:NegotiatingTasks
var:sending response var:acknowledgement
cas:SendingResponse cas:Acknowledgement
Description The User Interface. The negotiation manager. The activity that computed valid tasks. A task request. A task. A parent task request. An invalid task. An opinion report. The activity that requests an opinion report from the var:reputation manager. The activity that handles a task submitted for negotiation. An activity that sent a response. The acknowledgement that was after a sending response.
Figure 6: Table describing the variables for the post negotiation template
c SmartSociety Consortium 2013-2017
13 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
var:ui wasAttributedTo
prov:type cas:UserInterface tmpl:label cas:UserInterface tmpl:label var:username
var:reputation_manager
var:temp_feedback
used
prov:type cas:ReputationManager tmpl:label cas:ReputationManager wasAttributedTo
prov:type cas:FeedbackReport tmpl:label cas:FeedbackReport
wasAssociatedWith
var:feedback
var:submitting_feedback wasInformedBy
var:storing_feedback
wasDerivedFrom
wasAssociatedWith
prov:type tmpl:endTime tmpl:label tmpl:startTime
cas:SubmittingFeedback var:submitting_feedback_end cas:SubmittingFeedback var:submitting_feedback_start
wasGeneratedBy
prov:type tmpl:endTime tmpl:label tmpl:startTime
cas:StoringFeedback var:submitting_feedback_end cas:StoringFeedback var:storing_feedback_start
prov:type cas:FeedbackReport tmpl:label cas:FeedbackReport
var:b
Figure 7: Template for the submission of feedback reports. It describes the processes and entities used when the reputation manager receives a feedback report. The feedback report is stored, and it is used to generate reputation reports about a subject. Warning: The graphical version of templates are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at submit feedback template. Post Feedback Template, see Figure 7 Variable Type var:ui cas:UserInterface var:reputation manager cas:ReputationManager var:temp feedback cas:FeedbackReport var:feedback
cas:FeedbackReport
var:submitting feedback
cas:SubmittingFeedback
var:storing feedback
cas:StoringFeedback
Description The User Interface. The reputation manager. An un-stored feedback report, to be stored by the reputation manager. The feedback report, stored by the reputation manager. The activity that handled the submission of a feedback report. The activity that stored a feedback report.
Figure 8: Table describing the variables for the post feedback template
14 of 65
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable D2.2
var:reputation_manager
prov:type cas:ReputationManager tmpl:label cas:ReputationManager
var:feedback_report
wasAttributedTo
prov:type cas:FeedbackReport tmpl:label cas:FeedbackReport
used
wasAssociatedWith
var:computing_reputation
wasDerivedFrom
var:storing_feedback wasInformedBy
prov:type tmpl:endTime tmpl:label tmpl:startTime
cas:StoringFeedback var:storing_feedback_end cas:StoreFeedback var:storing_feedback_start
wasGeneratedBy
var:reputation_report
prov:type tmpl:endTime tmpl:label tmpl:startTime
cas:computingReputation var:computing_reputation_end cas:ComputingReputation var:computing_reputation_start
prov:type cas:ReputationReport tmpl:label cas:ReputationReport
var:b
Figure 9: Template for generating reputation reports. It describes the generation of reputation reports. The generation of reputation reports uses submitted feedback reports to generate reputation reports. This template is also used when opinion reports are computed, because opinion reports are a specialisation of reputation reports. Warning: The graphical version of templates are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at generate reputation template. Generate Reputation Template, see Figure 9 Variable Type var:reputation manager cas:ReputationManager var:feedback report cas:FeedbackReport var:reputation report var:generating reputation
cas:ReputationReport cas:ComputingReputation
var:storing feedback
cas:StoringFeedback
Description The reputation manager. The feedback report, used for generating a reputation report. The reputation report that was computed. The activity that computed the reputation report. The activity that stored a feedback report.
Figure 10: Table describing the variables for the generate reputation template
c SmartSociety Consortium 2013-2017
15 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
var:ui wasAttributedTo
prov:type cas:UserInterface tmpl:label cas:UserInterface tmpl:label var:username
var:reputation_manager
var:request
wasAttributedTo
used
prov:type cas:ReputationManager tmpl:label cas:ReputationManager
var:reputation_record wasAttributedTo
wasAssociatedWith
prov:type cas:Record tmpl:label cas:Record
var:response
var:sending_request
wasInformedBy
prov:type cas:SendingRequest tmpl:endTime var:sending_request_end tmpl:label cas:SendRequest
var:computing_response
wasDerivedFrom
prov:type cas:Request tmpl:label cas:Request
wasAssociatedWith
wasGeneratedBy
prov:type tmpl:endTime tmpl:label tmpl:startTime
cas:computingResponse var:computing_response_end cas:computingResponse var:computing_response_start
prov:type cas:Response tmpl:label cas:Response
var:b
Figure 11: Template for generating compositions for ride matches. Bindings for this template are generated when the reputation manager receives a request, with one exception, when a feedback request is posted. When such a call is received by the reputation manager it retrieves the request information and sends it to the requester. Warning: The graphical version of templates are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at api call template. Api Call Template, see Variable var:ui var:reputation manager var:request
Figure 11 Type cas:UserInterface cas:ReputationManager cas:Request
var:response
cas:Response
var:sending request
cas:SendingRequest
var:generating response var:reputation record
cas:ComputingResponse cas:Record
Description The User Interface. The reputation manager. The request that was submitted to the reputation manager. The response that was computed by the reputation manager. The activity that submitted the request to the reputation manager. The activity that computed the response. A record held by the reputation manager, it is used to generate the response.
Figure 12: Table describing the variables for the api call template
16 of 65
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable D2.2
var:ui
prov:type cas:UserInterface tmpl:label var:username wasAttributedTo
wasAssociatedWith
var:changing_view wasGeneratedBy
var:view
prov:type cas:ChangingView tmpl:endTime var:changing_view_start_end_time tmpl:startTime var:changing_view_start_time
prov:type cas:View
var:b
Figure 13: Template for changing the view on the UI, bindings for this template are generated when the user changes a view. Warning: The graphical version of templates are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at change view template. Change View Template, see Figure 13 Variable Type Description var:ui cas:UserInterface The UI. var:changing view cas:ChangingView The actctivity that changed the view in the UI. var:view cas:View The view that was changed in the UI.
Figure 14: Table describing the variables for the change view template
c SmartSociety Consortium 2013-2017
17 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
var:ui wasAttributedTo wasAttributedTo
prov:type cas:UserInterface tmpl:label var:username
var:view
var:request used
prov:type cas:View
wasAttributedTo
prov:type cas:Request
used
var:identity wasAssociatedWith
var:sending_request
used
prov:type cas:Identity
prov:type cas:SendingRequest tmpl:endTime var:sending_request_end_time tmpl:startTime var:sending_request_start_time
var:b
Figure 15: 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. Warning: The graphical version of templates are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at submit request template. Submit Data Template, see Figure 15 Variable Type Description ui cas:UserInterface The User Interface. identity cas:Identity The identity that was used to submit a request. request cas:Request The request that was sent via the UI. sendingRequest cas:sendingRequest The activity that submitted a request. var:view cas:View The view that the sending request is associated with.
Figure 16: Table describing the variables for the submit data template
18 of 65
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable D2.2
3.2
Vocabulary
In addition to the vocabulary defined for HDA-CAS applications (see Appendix A, Section 3), we have defined subtypes defining Ride Share specific agents and activities (see Figure 17 and Appendix B (http://smartsociety-project.github.io/cas/)). These additional subtypes enables the explanation peer to provide individualised descriptions of Ride Share agents and activities.
3.3
End to End Provenance Integration
In this section, we show the provenance that is generated when a task request is submitted, a task negotiation, and the generation of reputation when a feedback report is submitted. The namespaces used by the Ride Share demonstrator are presented and described in Table 2. Prefix
URI
cas
http://smartsocietyproject.github.io/cas/# file:/tmp/tmpdMwCmX/168.144.152.202/ file:/tmp/tmpdMwCmX/168.144.152.202/ OpenRideServer-RS/ file:/tmp/tmpdMwCmX/168.144.152.202/ OpenRideServer-RS/view/ http://168.144.202.152:3000/ http://168.144.202.152:3000/rideRequests/ http://168.144.202.152:3000/ridePlans/ http://pat.ecs.soton.ac.uk/
ui openride view orchestrator request plans reputation feedback usr
http://pat.ecs.soton.ac.uk/application/ 1/feedback/ http://pat.ecs.soton.ac.uk/rs/subject/ byURI/
Namespace Description The cas vocabulary. The UI. The UI’s service. The UI’s views. The orchestration peer. Ride requests. Ride plans. The reputation manager. Feedback reports. The users described by the reputation manager.
Table 2: Namespaces used in the Ride Share demonstrator. The provenance graph presented in Figure 19 shows the provenance generated from the UI and orchestration peer when two users submit a ride request. When a user submits a ride request via the UI, it submits provenance bindings for any changes of view in the UI and the submission of the request, using the templates in Figures 13 and 15, respectively. c SmartSociety Consortium 2013-2017
19 of 65
20 of 65
cas:UserInterface
cas:IncentiveManager
cas:CompositionManager
cas:NegotiationManager
cas:OrchestrationManager
cas:ReputationManager
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
c SmartSociety Consortium 2013-2017 Deliverable D2.2
Figure 17: CAS Vocabulary for the Ride Share demonstrator. The yellow nodes denote prov d-m terms, the pink nodes with black text are core CAS are defined in Appendix A, Section 3, 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 presented in Appendix A, Section 3.
http://www.smart-society-project.eu
Deliverable D2.2
c SmartSociety Consortium 2013-2017
Figure 20 shows that ido submitted a request, and these submissions are authenticated using their Ride Share identities. When a ride request is submitted via the UI, the ride manager peer stores the request and then attempts to generate plans for potential rides (see Figure 21). This interaction causes the rideshareapp to generate provenance bindings for the post task template and the composition template (see Figures 1 and 3, respectively). During the composition generation the rideshareapp requests opinion reports from the reputation service. The reputation manager then retrieves opinion reports about the subjects of the potential ride (see Figure 22) and generates the provenance bindings for the get provenance items template (see Figure 11). The provenance graph presented in Figure 24 shows the provenance generated when a user submits a negotiation offer on a potential ride plan. When a user submits an offer via the UI, the UI submits provenance bindings for the changing of view in the UI and the submission of the request, using the templates in Figures 13 and 15, respectively. Figure 25 shows that the user ido submits an offer offer:t1 where the rideservice, authenticates the user with the activity authenticatingIdentity-3 using their Ride Share identity identity-1. The ride service then generates ride plan:3 which was derived from ride plan:1, rideplan:2 and rideplan:1a. The ride manager peer submits provenance bindings for the negotiation template shown in Figure 5. The provenance graph presented in Figure 24 shows the provenance generated when a user submits feedback for a ride.
When a user an submits the feedback reputa-
tion:application/1/feedback/0/ via the UI, the UI submits provenance bindings for the changing of view in the UI and the submission of the feedback, using the templates in Figures fig:changeview and fig:uisubmit, respectively. The reputation manager then generates a reputation and opinion reports reputation:application/1/reputation/1/ and reputation:application/1/opinion/1/, respectively, which are based on the feedback submitted reputation:application/1/feedback/0/. In this case, the reputation report is consumed by users and contains aggregate values from feedback reports about a subject, and opinion report is consumed by another peer and contains one aggregate value representing one user’s opinion about another user. The reputation manager submits the provenance bindings for the generate reputation template shown in Figure 9. c SmartSociety Consortium 2013-2017
21 of 65
wasAssociatedWith
wasAssociatedWith
prov:type cas:OrchestratorManager
wasAttributedTo
wasAssociatedWith
prov:type cas:Acknowledgement
wasInformedBy
wasInformedBy
prov:type cas:Identity
orchestrator:identity-0
wasAssociatedWith
wasAssociatedWith
wasAttributedTo
prov:type cas:SubmitingTask dct:hasPart orchestrator:storingTask-1
wasAttributedTo
wasAssociatedWith
used
prov:type cas:Task
prov:type cas:Acknowledgement
orchestrator:acknowledgement-1
wasGeneratedBy
orchestrator:sendingResponse-1
wasAssociatedWith wasInformedBy
orchestrator:submittingTask-1
prov:type cas:ComposingTasks dct:hasPart orchestrator:generatingComposition-1
orchestrator:composingTasks-1
prov:type cas:SendingResponse
prov:type cas:SubmitingTask dct:hasPart orchestrator:composingTasks-1 dct:hasPart orchestrator:storingTask-2
orchestrator:acknowledgement-2
wasGeneratedBy
orchestrator:sendingResponse-2
wasAttributedTo
orchestrator:submittingTask-2
wasAssociatedWith
orchestrator:rsa
used
wasDerivedFrom
used
wasGeneratedBy
used
wasDerivedFrom
prov:type cas:SendingRequest
opinions:requestingOpinion-1
wasInformedBy
orchestrator:generatingComposition-1
prov:type cas:Task
wasDerivedFrom
used
prov:type cas:StoringTask
orchestrator:ridePlans/1
wasDerivedFrom
wasGeneratedBy
wasAttributedTo
wasAttributedTo
used
wasAttributedTo
used
prov:type cas:ReputationReport
used
opinions:2
wasInformedBy
wasAssociatedWith
wasAssociatedWith
wasGeneratedBy
opinions:1
wasAttributedTo
prov:type cas:GeneratingResponse
reputation:rs
prov:type cas:TaskRequest
wasDerivedFrom
prov:type cas:Response
wasDerivedFrom
reputation:response-1
wasGeneratedBy
prov:type cas:ReputationReport
prov:type cas:ReputationManager
prov:type cas:View
prov:type cas:ChangingView
wasAttributedTo
used
wasGeneratedBy
ui:OpenRideServer-RS/view-1
wasAttributedTo
prov:type cas:SendingTaskRequest
reputation:generatingResponse-1
prov:type cas:GeneratingComposition
wasGeneratedBy
used
prov:type cas:TaskRequest
orchestrator:rideRequests/2
wasGeneratedBy
used
wasAssociatedWith
ui:OpenRideServer-RS/submittingRequestView-1
wasAttributedTo
ui:OpenRideServer-RS/submittingRequestButton-1
used
orchestrator:rideRequests/t1
wasAttributedTo
orchestrator:storingTask-2
wasAssociatedWith
orchestrator:identity-1
prov:type cas:Identity
wasAttributedTo
wasGeneratedBy
orchestrator:rideRequests/1
wasGeneratedBy
prov:type cas:TaskRequest
orchestrator:ridePlans/0
prov:type cas:SendingResponse
prov:type cas:StoringTask
orchestrator:storingTask-1
wasAttributedTo
prov:type cas:PostingTaskRequest
wasAssociatedWith
wasAssociatedWith
ui:PostingTaskRequest-1
prov:label 'usr:ido' prov:label usr:ido prov:type cas:UserInterface
ui:OpenRideServer-RS-1
prov:type cas:Task
orchestrator:rideRequests/t2
wasDerivedFrom
wasAttributedTo
wasAttributedTo
wasAssociatedWith
prov:type cas:Identity
used
prov:type cas:PostingTaskRequest
wasGeneratedBy
ui:PostingTaskRequest-2
wasAttributedTo
wasAssociatedWith
prov:type cas:SendingTaskRequest
wasAssociatedWith
prov:type cas:View
ui:OpenRideServer-RS/view-2
wasGeneratedBy
ui:OpenRideServer-RS/submittingRequestView-2
wasAttributedTo
ui:OpenRideServer-RS/submittingRequestButton-2
used
orchestrator:identity-2
wasAttributedTo
prov:label usr:avi prov:type cas:UserInterface
ui:OpenRideServer-RS-2
prov:type cas:ChangingView
c SmartSociety Consortium 2013-2017 Deliverable D2.2
Figure 18: The provenance data recorded from the submission of a ride request. Warning: The graphical version of the provenance traces are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic at generate rides. 22 of 65 version, which can be rescaled, which is accessible http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
wasAssociatedWith
wasAssociatedWith
prov:type cas:OrchestratorManager
wasAttributedTo
wasAssociatedWith
prov:type cas:Acknowledgement
wasInformedBy
wasInformedBy
prov:type cas:Identity
orchestrator:identity-0
wasAssociatedWith
wasAssociatedWith
wasAttributedTo
prov:type cas:SubmitingTask dct:hasPart orchestrator:storingTask-1
wasAttributedTo
wasAssociatedWith
used
prov:type cas:Task
prov:type cas:Acknowledgement
orchestrator:acknowledgement-1
wasGeneratedBy
orchestrator:sendingResponse-1
wasAssociatedWith wasInformedBy
orchestrator:submittingTask-1
prov:type cas:ComposingTasks dct:hasPart orchestrator:generatingComposition-1
orchestrator:composingTasks-1
prov:type cas:SendingResponse
prov:type cas:SubmitingTask dct:hasPart orchestrator:composingTasks-1 dct:hasPart orchestrator:storingTask-2
orchestrator:acknowledgement-2
wasGeneratedBy
orchestrator:sendingResponse-2
wasAttributedTo
orchestrator:submittingTask-2
wasAssociatedWith
orchestrator:rsa
wasAttributedTo
used
wasDerivedFrom
used
prov:type cas:SendingRequest
opinions:requestingOpinion-1
wasInformedBy
orchestrator:generatingComposition-1
used
wasDerivedFrom
wasGeneratedBy
orchestrator:ridePlans/1
prov:type cas:Task
wasDerivedFrom
used
prov:type cas:StoringTask
prov:type cas:Identity
wasDerivedFrom
orchestrator:rideRequests/1
wasGeneratedBy
prov:type cas:TaskRequest
orchestrator:ridePlans/0
prov:type cas:SendingResponse
prov:type cas:StoringTask
wasGeneratedBy
wasAttributedTo
wasAttributedTo
used
wasAttributedTo
used
prov:type cas:ReputationReport
used
opinions:2
wasInformedBy
wasAssociatedWith
wasAssociatedWith
wasGeneratedBy
opinions:1
wasAttributedTo
prov:type cas:GeneratingResponse
reputation:rs
prov:type cas:TaskRequest
wasDerivedFrom
prov:type cas:Response
wasDerivedFrom
reputation:response-1
wasGeneratedBy
prov:type cas:ReputationReport
prov:type cas:ReputationManager
prov:type cas:ChangingView
prov:type cas:View
wasAttributedTo
used
wasGeneratedBy
ui:OpenRideServer-RS/view-1
wasAttributedTo
prov:type cas:SendingTaskRequest
reputation:generatingResponse-1
prov:type cas:GeneratingComposition
wasGeneratedBy
used
prov:type cas:TaskRequest
orchestrator:rideRequests/2
wasGeneratedBy
used
wasAssociatedWith
ui:OpenRideServer-RS/submittingRequestView-1
wasAttributedTo
ui:OpenRideServer-RS/submittingRequestButton-1
used
orchestrator:rideRequests/t1
wasAttributedTo
orchestrator:storingTask-2
wasAssociatedWith
orchestrator:identity-1
wasGeneratedBy
wasAttributedTo
prov:type cas:PostingTaskRequest
wasAssociatedWith
orchestrator:storingTask-1
wasAssociatedWith
ui:PostingTaskRequest-1
prov:label 'usr:ido' prov:label usr:ido prov:type cas:UserInterface
ui:OpenRideServer-RS-1
prov:type cas:Task
orchestrator:rideRequests/t2
wasDerivedFrom
wasAttributedTo
wasAttributedTo
wasAssociatedWith
prov:type cas:Identity
used
prov:type cas:PostingTaskRequest
wasGeneratedBy
ui:PostingTaskRequest-2
wasAttributedTo
wasAssociatedWith
prov:type cas:SendingTaskRequest
wasAssociatedWith
prov:type cas:View
ui:OpenRideServer-RS/view-2
wasGeneratedBy
ui:OpenRideServer-RS/submittingRequestView-2
wasAttributedTo
ui:OpenRideServer-RS/submittingRequestButton-2
used
orchestrator:identity-2
wasAttributedTo
prov:label usr:avi prov:type cas:UserInterface
ui:OpenRideServer-RS-2
prov:type cas:ChangingView
Deliverable D2.2 c SmartSociety Consortium 2013-2017
Figure 19: The provenance data recorded from the submission of a ride request with overlays showing different templates. Where, blue is the change view template, pink is the submit request template, orange is the post task template, grey is the composition and green is the api call template.
23 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
Figure 20: Close up of the provenance graph in Figure 19 showing the change of view and submission of a ride request.
Figure 21: Close up of the provenance graph in Figure 19 showing storing of a ride request.
Figure 22: Close up of the provenance graph in Figure 19 showing the retrieval of opinions via the reputation manager. 24 of 65
http://www.smart-society-project.eu
prov:type cas:ComposingTasks dct:hasPart negotiation:generatingComposition-2 dct:hasPart negotiation:generatingInvalidTasks-2
negotiation:composingTasks-2
wasAssociatedWith
wasAttributedTo
prov:type cas:Acknowledgement
negotiation:response-3
wasGeneratedBy
negotiation:sendingResponse-3
wasInformedBy
wasAttributedTo
prov:type cas:Task
prov:type cas:GeneratingInvalidTasks
prov:type cas:Task
negotiation:ridePlans/4
wasGeneratedBy
used
wasDerivedFrom
used
used
used
prov:label usr:avi prov:type cas:UserInterface
wasAttributedTo
wasInformedBy prov:type cas:GeneratingComposition
negotiation:generatingComposition-2
wasDerivedFrom
wasGeneratedBy
prov:type cas:Task
negotiation:ridePlans/3
wasDerivedFrom
wasAssociatedWith
prov:type cas:TaskRequest
negotiation:rideRequests/2
wasAttributedTo
ui:OpenRideServer-RS-2 wasAttributedTo
used
wasInformedBy
wasDerivedFrom
wasAttributedTo
wasDerivedFrom
negotiation:submittingOpinion-2
wasAssociatedWith
negotiation:ridePlans/2
wasDerivedFrom
prov:type cas:TaskRequest
negotiation:rideRequests/1
wasAttributedTo
negotiation:generatingInvalidTasks-2
wasAssociatedWith
prov:type cas:Task
negotiation:ridePlans/1
wasDerivedFrom
wasAttributedTo
wasAssociatedWith
prov:type cas:SendingResponse
prov:type cas:NegotiatingTasks dct:hasPart negotiation:generatingComposition-2 dct:hasPart negotiation:generatingInvalidTasks-2 dct:hasPart negotiation:storingTask-2
prov:type cas:SubmittingRequest
wasAssociatedWith
negotiation:negotiatingTasks-1
wasAssociatedWith
prov:type cas:NegotiationManager
negotiation:rsa
used
prov:type cas:ReputationReport
reputation:application/1/opinionOf/1/aboutSubject/24
wasAssociatedWith
negotiation:rideRequests/3
used
prov:type cas:ReputationReport
reputation:application/1/opinionOf/1/aboutSubject/23 wasInformedBy
prov:type cas:TaskRequest
prov:type cas:StoringTask
used wasAssociatedWith
ui:OpenRideServer-RS-1
wasDerivedFrom
prov:type cas:ChangingView
prov:type cas:View
ui:OpenRideServer-RS/view-3
wasGeneratedBy
prov:type cas:Task
wasAttributedTo
negotiation:oers/t1 used
used
negotiation:authenticate-1
wasAttributedTo
prov:type cas:SendingRequest
prov:type cas:Identity
wasAssociatedWith
prov:label usr:ido prov:type cas:UserInterface
ui:OpenRideServer-RS/view/submittingTaskNegotiation-1
wasDerivedFrom wasAttributedTo wasAttributedTo
ui:OpenRideServer-RS/view/activeOersView-1
wasAttributedTo
prov:type cas:Task
negotiation:ridePlans/1a
negotiation:storingTask-2
wasGeneratedBy
Deliverable D2.2 c SmartSociety Consortium 2013-2017
Figure 23: The provenance data recorded from the submission of a negotiation offer. Warning: The graphical version the provenance traces are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can2013-2017 be rescaled, which is accessible negotiation. c SmartSociety Consortium 25 of 65
26 of 65
wasAssociatedWith
prov:type cas:ComposingTasks dct:hasPart negotiation:generatingComposition-2 dct:hasPart negotiation:generatingInvalidTasks-2
negotiation:composingTasks-2
wasAttributedTo
prov:type cas:Acknowledgement
negotiation:response-3
wasGeneratedBy
negotiation:sendingResponse-3
wasAttributedTo
prov:type cas:Task
prov:type cas:GeneratingInvalidTasks
prov:type cas:Task
negotiation:ridePlans/4
wasGeneratedBy
used
wasDerivedFrom
used
used
used
prov:label usr:avi prov:type cas:UserInterface
wasAttributedTo
wasInformedBy prov:type cas:GeneratingComposition
negotiation:generatingComposition-2
wasDerivedFrom
wasGeneratedBy
prov:type cas:Task
negotiation:ridePlans/3
wasDerivedFrom
wasAssociatedWith
prov:type cas:TaskRequest
negotiation:rideRequests/2
wasAttributedTo
ui:OpenRideServer-RS-2 wasAttributedTo
used
wasInformedBy
wasDerivedFrom
wasAttributedTo
wasDerivedFrom
negotiation:submittingOpinion-2
wasAssociatedWith
negotiation:ridePlans/2
wasDerivedFrom
prov:type cas:TaskRequest
negotiation:rideRequests/1
wasAttributedTo
negotiation:generatingInvalidTasks-2
wasAssociatedWith
prov:type cas:Task
negotiation:ridePlans/1
wasDerivedFrom
wasAttributedTo
wasAssociatedWith
prov:type cas:SendingResponse
prov:type cas:NegotiatingTasks dct:hasPart negotiation:generatingComposition-2 dct:hasPart negotiation:generatingInvalidTasks-2 dct:hasPart negotiation:storingTask-2
wasInformedBy
prov:type cas:SubmittingRequest
wasAssociatedWith
wasAssociatedWith
negotiation:negotiatingTasks-1
prov:type cas:NegotiationManager
negotiation:rsa
used
prov:type cas:ReputationReport
reputation:application/1/opinionOf/1/aboutSubject/24
wasAssociatedWith
negotiation:rideRequests/3
used
prov:type cas:ReputationReport
reputation:application/1/opinionOf/1/aboutSubject/23 wasInformedBy
prov:type cas:TaskRequest
prov:type cas:StoringTask
negotiation:storingTask-2
wasGeneratedBy
used wasAssociatedWith
ui:OpenRideServer-RS-1
wasDerivedFrom
prov:type cas:ChangingView
prov:type cas:View
ui:OpenRideServer-RS/view-3
wasGeneratedBy
prov:type cas:Task
wasAttributedTo
negotiation:o ers/t1 used
used
negotiation:authenticate-1
wasAttributedTo
prov:type cas:SendingRequest
prov:type cas:Identity
wasAssociatedWith
prov:label usr:ido prov:type cas:UserInterface
ui:OpenRideServer-RS/view/submittingTaskNegotiation-1
wasDerivedFrom wasAttributedTo wasAttributedTo
ui:OpenRideServer-RS/view/activeO ersView-1
wasAttributedTo
prov:type cas:Task
negotiation:ridePlans/1a
c SmartSociety Consortium 2013-2017 Deliverable D2.2
Figure 24: The provenance data recorded from the submission of a negotiation offer with overlays showing different templates. Where, blue is the change view template, pink is the submit request template, and red is the api call template.
http://www.smart-society-project.eu
Deliverable D2.2
c SmartSociety Consortium 2013-2017
Figure 25: Close up of the provenance graph in Figure 24 showing submission of a negotiation offer.
3.4
APIs
The APIs for the reputation and explanation peers are described in Tables 3 and 4. These APIs support access to the services’ resources for the Ride Share demonstrator and other applications. The supported API calls were designed with feedback from WP5 and 6, so that they supported their requirements for the demonstrator.
4
Rideshare Demonstrator and Accountability
The explanation peer is designed to provide transparency and accountability for users of HDA-CASs. It provides a narrative about a single provenance element (either an entity, activity or agent) in either a provenance document held by ProvStore or a set of provenance documents related to a specific application. It uses sentence templates to explain the provenance data about a subject (see Appendix A, Sections 4.3 and 5.3). Concretely, it can be used to explain a subject in provenance data generated by the Ride Share demonstrator (for more details see Appendix A, Section 4.3). For example, the subject plan:1 can be explained from the provenance data presented in Section 3.3, with the following explanation: The ride plan plan:1 was generated by the orchestrator:composition-1 activity. It details the attributes of a ride including its date and time, the origin and destination, and its potential participants and their roles. It was derived c SmartSociety Consortium 2013-2017
27 of 65
wasAssociatedWith
prov:type cas:ReputationReport
wasDerivedFrom
wasGeneratedBy
prov:type cas:ReputationReport
prov:type cas:FeedbackReport
reputation:application/1/reputation/1/
wasDerivedFrom
prov:type cas:GeneratingReputation
reputation:application/1/opinion/1/
wasGeneratedBy
wasInformedBy
wasAttributedTo
used
wasAssociatedWith
prov:type cas:GeneratingReputation
wasAssociatedWith
prov:type cas:ChangingView
wasGeneratedBy
ui:OpenRideServer-RS/view/submittingFeedbackView-1
wasAttributedTo
ui:OpenRideServer-RS/view-4
prov:type cas:FeedbackReport
ui:OpenRideServer-RS/feedback/t1
reputation:generating_reputation-1
wasDerivedFrom
prov:type cas:SubmitingFeedback
wasInformedBy
prov:type cas:StoringFeedback
wasGeneratedBy
feedback:0/
wasAttributedTo
wasAssociatedWith
wasAttributedTo
ui:OpenRideServer-RS/view/submittingFeedbackButton-1
used
orchestrator:authenticate-1
reputation:storing_feedback-1
wasAssociatedWith
prov:type cas:identity
prov:label usr:ido prov:type cas:Peer
wasAttributedTo
wasInformedBy
reputation:generating_opinion-1
wasAttributedTo
prov:type cas:ReputationPeer
reputation:reputation_peer
ui:OpenRideServer-RS-1
c SmartSociety Consortium 2013-2017 Deliverable D2.2
Figure 26: The provenance data recorded from a submitting feedback. Warning: The graphical version of provenance traces are included in the deliverable for illustrative purposes only. Given the size of the graph, the reader is expected to use the electronic version, which can be rescaled, which is accessible at generate reputation. 28 of 65 http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017 wasAssociatedWith
wasInformedBy
wasAttributedTo
used
wasAssociatedWith
prov:type cas:GeneratingReputation
wasAssociatedWith
prov:type cas:ChangingView
wasGeneratedBy
ui:OpenRideServer-RS/view/submittingFeedbackView-1
wasAttributedTo
ui:OpenRideServer-RS/view-4
prov:type cas:FeedbackReport
ui:OpenRideServer-RS/feedback/t1
reputation:generating_reputation-1
wasGeneratedBy
prov:type cas:ReputationReport
wasDerivedFrom
prov:type cas:ReputationReport
prov:type cas:FeedbackReport
prov:type cas:StoringFeedback
wasDerivedFrom
prov:type cas:SubmitingFeedback
wasInformedBy
reputation:application/1/reputation/1/
wasDerivedFrom
prov:type cas:GeneratingReputation
feedback:0/
wasGeneratedBy
wasAssociatedWith
ui:OpenRideServer-RS/view/submittingFeedbackButton-1
reputation:application/1/opinion/1/
wasGeneratedBy
wasAssociatedWith
prov:type cas:identity
used
orchestrator:authenticate-1
reputation:storing_feedback-1 wasAttributedTo
wasAttributedTo
wasInformedBy
reputation:generating_opinion-1
wasAttributedTo
prov:type cas:ReputationPeer
reputation:reputation_peer
prov:label usr:ido prov:type cas:Peer
ui:OpenRideServer-RS-1 wasAttributedTo
Deliverable D2.2 c SmartSociety Consortium 2013-2017
Figure 27: The provenance data recorded from a submitting feedback with overlays showing different templates. Where, blue is the change view template, pink is the submit request template, and red is the submit feedback template, and yellow is the negotiation template.
29 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
Reputation Manager URI /subject/byURI/:subject uri/
/application/:app/subject/:subject/ /application/:app/subject/:subject/feedback/
/application/:app/feedback/ /application/:app/feedback/:feedback/ /application/:app/subject/:subject/reputation/ /application/:app/reputation/:reputation/ /application/:app/opinion/:opinion/ /application/:app/opinions/
Description A collection resources held by the reputation manager that reference a subject, including of feedback and reputation reports. A collection of subjects associated with an application. A collection of feedback report resources associated with a subject resource. A feedback report to the feedback report collection. A feedback report resource with a specific id. A collection of reputation reports about a subject resource. A reputation report with a specific id. An opinion report with a specific id. A collection of opinion reports about subject resources.
Table 3: API calls for the reputation manager
Reputation Manager URI /application/:app/subject/:subject
Description A narrative resource about a subject with respect to an application.
Table 4: API calls for the explanation peer
30 of 65
http://www.smart-society-project.eu
Deliverable D2.2
c SmartSociety Consortium 2013-2017
from the ride requests with the ids 1 and 2. The ride request request:1 was submitted by usr:ido. It includes information about a requested rides date and time, the origin and destination, and the role played by the usr:ido. The ride request request:2 was submitted by usr:avi and it was generated by view:submitRequestButton-2. It includes information about a requested rides date and time, the origin and destination, and the role played by the usr:avi and it was generated by view:submitRequestButton. The compute composition activity orchestrator:composition-1 was performed by orchestrator:rsa, it generates potential ride matches between current ride requests and matches on a requests origin, destination and time. The following ride requests with the ids 1 and 2 were matched using this activity.
5
Links with Other Work Packages
WP2 has been influential and influenced by other work packages in Smart Society. Predominantly, WP2 has links to WP 4, 5 and 6 because they hinge on the development of the Ride Share demonstrator, but we have also collaborated with them over modelling HDA-CAS, and privacy and provenance. Concretely, WP2 has collaborated with: 1. WP1, 4, 5 and 6 on the Ride Share demonstrator, which we met weekly to discuss the following Ride Share issues: architecture, implementation, integration and user studies. We collaborated with WP6 to design the orchestrator peer templates (see Section 3.1). WP5 and 6 have also influenced design decisions about the reputation’s API and the data structures it returns. For example, WP6 required helper methods for return a set of opinions, and the data returned by the application/:app/bySubject/:sub call to support UI calls. We collaborated with WP5 and 6 with the integration of provenance into the UI and the orchestrator peer through the use of provenance templates and bindings, respectively. 2. WP6 to design a model for accountability, at a face-to-face meeting held in Southampton. Initially we focused on modelling the Ride Share demonstrator, including peers, ride requests, and ride tasks, and then we broadened it and included orchestration and Smart Society concepts for different HDA-CASs. Specifically, we discussed what is peer is and its constituents, how to model a collective and the role they can play in social computations, and how tasks are model and what information they contain. c SmartSociety Consortium 2013-2017
31 of 65
c SmartSociety Consortium 2013-2017
Deliverable D2.2
3. WP4 through discussion during the project meeting in Oxford, about the vocabulary described in WP4-MS8. There are concepts that align with WP4’s vocabulary and the accountability vocabulary. It is not currently used in the Ride Share demonstrator, however in the future the concepts in the provenance templates which align will be marked up with WP4’s formal model. Concretely, WP4’s formal model will be expressed as attributes of a provenance type. For example, a prov:Agent Joe has the attributes prov:type=‘sscore:Person’, sscore:gender=‘sscore:Male’, sscore:dob =“1972-05-30T09:30:10.5”, where sscore is the namespace for the smart society core ontology. 4. WP1 and 4 through discussions on privacy, primarily these discussion were held in Stockholm between UoS and KAU. Where we presented prov d-m and the reputation manager. We discussed how to hide the presence of a participant with anonymisation or pseudonymisation. We planned to work on aligning privacy and provenance, investigate how the explanation peer can be used interactively to support access control to address privacy issues, and also explain access control with the context and the effect of how smart society applications controlled data.
6
Future Work
There are a number of critical issues to be investigated to develop successful HDA CASs. We now discuss future work and their associated research challenges: 1. Investigate how the model of accountability can better support transparency and accountability. We will continue to refine the cas vocabulary, so that it defines and reflects the concepts used with SmartSociety, so that it can support the recording of provenance data for social computations. We will continue to collaborate with work packages 1, 4, 5 and 6. We will develop the explanation service so that it leverages the model for accountability and describes access control and privacy policies. 2. Investigate how to allow users to explore provenance data while supporting anonymity and pseudonymity for both privacy and transparency. We will add access control to address privacy issues, and explain with the context of provenance descriptions how it uses them in the ride share application. 3. Design and perform a user study to investigate the effectiveness of the reputation and explanation peers, with an HDA CAS. In more detail, we will investigate the 32 of 65
http://www.smart-society-project.eu
Deliverable D2.2
c SmartSociety Consortium 2013-2017
quality of explanations for reputation reports, how they were used to make decisions, and if they changed a users decision process. 4. Our contribution to scalability is our summarisation technique (see Section 3.3 and Appendix 2, Milestone MS2), the template mechanism (see Section 3.1 and Appendix 1, Milestone MS2), and the deployment of the template mechanism in Ride Share. As far as costing of scalability is concerned, the goal is to adopt simple data size metrics (e.g. size of provenance graph), and evaluate the performance of summarisation, templates, and explanations with respect to the data generated by the Ride Share deployment. As Ride Share will not generate data before the fourth quarter, we were not able to present and evaluate the summarisation techniques for the Ride Share demonstrator.
c SmartSociety Consortium 2013-2017
33 of 65
c SmartSociety Consortium 2013-2017
A
Deliverable D2.2
Submitted paper: Semantics and Provenance for Accountable Smart City Applications
34 of 65
http://www.smart-society-project.eu
1
Undefined 1 (2009) 1–5 IOS Press
Semantics and Provenance for Accountable Smart City Applications Editor(s): Name Surname, University, Country Solicited review(s): Name Surname, University, Country Open review(s): Name Surname, University, Country
Heather S. Packer, a Dimitris Diochnos, b Michael Rovatsos, b Ya’akov Gal, c and Luc Moreau a Electronics and Computer Science, University of Southampton, Southampton, SO17 1BJ, UK E-mail: {hp3, L.Moreau}@ecs.soton.ac.uk b School of Informatics, The University of Edinburgh, 33 Buccleuch Place, Edinburgh, EH8 9JS, UK E-mail: {D.Diochnos, mrovatso}@ed.ac.uk c Department of Information Systems Engineering, Ben-Gurion University of the Negev, Be’er Sheva, Israel E-mail: kobig@bgu.ac.il a
Abstract. The recent media focus on Smart City services, particularly ride sharing, that provide ordinary users with the ability to advertise their resources has highlighted society’s need for transparent and accountable systems. Current systems offer little transparency behind their processes that claim to provide accountability to and for their users. To address such a concern, some applications provide a static, textual description of the automated algorithms used, with a view to promote transparency. However, this is not sufficient to inform users exactly how information is derived. These descriptions can be enhanced by explaining the actual execution of the algorithm, the data it operated on, and the parameters it was configured with. Such descriptions about a system’s execution and its information flow can be expressed using PROV, a standardised provenance data model. However, given its generic and domain-agnostic nature, PROV only provides limited information about the relationship between provenance elements. Combined with semantic information, a PROV instance becomes a rich resource, which can be exploited to provide users with understandable accounts of automated processes, thereby promoting transparency and accountability. Thus, this paper contributes, a vocabulary for Smart City resource sharing applications, an architecture for accountable systems, and a set of use cases that demonstrate and quantify how the semantics enrich an account in a ride share scenario. Keywords: Provenance, Semantic, Accountability, Transparency, Ride Share
1. Introduction A Smart City1 is an emerging conceptual view of a city that promotes the use of information and communication technologies to engage with citizens to develop social capital and intellectual capital, to make better use of hard infrastructure, to reduce usage of environmental capital, and to support smart growth. In this context, a class of promising online applications seek to enable citizens to share services in smart 1 http://en.wikipedia.org/wiki/Smart_city
cities. This class of applications, which is referred to as smart sharing, are varied and include sharing2 care sharing (Uber, Blablacar, Lyft), bus routes (Chariot), parking space (JustPark), spare rooms (airbnb), and cleaning services (HomeJoy). Smart sharing services allow citizens to benefit from customised and financially advantageous offerings, potentially reducing environment impact. 2 Uber: www.uber.com/, Blablacar: www.blablacar.com, Lyft: www.lyft.com, Chariot (chariotsf.com), JustPark: www.justpark.com, airbnb: www.airbnb.co.uk, and Homejoy: www.homejoy.com
c 2009 – IOS Press and the authors. All rights reserved 0000-0000/09/$00.00
2
Smart sharing services are not just online platforms since they mediate access to real people and physical resources.3 It is recognized that smart sharing services have inherent entry barriers [22], because they “rely on customers and hosts overcoming their fear of strangers.”4 Thus, smart sharing services attempt to belay their users’ fears through a variety of techniques, including screening processes, security measures, reputation systems5 , and incentive mechanisms. For instance, due to heavy media attention, some ride share applications have been banned in various locations around the world because they “do not enough to protect their passengers from unlicensed drivers.”6 . In response, they further provided driver screening, insurance, feedback and reputation systems7 Two strong characteristics are now commonly supported by smart share services: transparency and user accountability. Transparency is operating in such a way that when a shared resource is offered to a user, it is required that all details of the resource are exposed to its potential consumers so that they can make informed decision as to whether to use the resource or not. By making users accountable for their actions (or the quality of their resources), it is believed that users are less likely to make mistakes or take actions that may affect the quality of the service. User accountability is usually a by product of a reputation system and transparency, which act as an incentive mechanism [3] for users to provide good quality services. Generally companies offering smart sharing services rely on automated processes, from matching users to services, to “algorithms that identify suspicious behavior.”8 Automated processes can seem like a black box to users. Typically, these service-oriented systems rely on feedback from users, which may be viewed by other users or to compute reputation recom3 http://www.nytimes.com/2014/10/19/upshot/ when-uber-lyft-and-airbnb-meet-the-real-world. html?_r=2&abt=0002&abg=1. 4 http://www.bbc.co.uk/news/ magazine-21339891 5 http://blog.uber.com/uberpopfactsbxl 6 The Guardian Uber taxi service banned in Berlin on safety grounds http://www. theguardian.com/technology/2014/aug/14/ uber-taxi-service-banned-berlin-safety-grounds 7 http://blog.uber.com/uberpopfactsbxl, https://www.lyft.com/safety, and http://www. blablacar.com/trust-safety-insurance 8 http://www.nytimes.com/2014/10/19/upshot/ when-uber-lyft-and-airbnb-meet-the-real-world. html?_r=1&abt=0002&abg=1
mendations. Some applications may provide a static description of the algorithm used to compute reputation in order to be transparent. However, this is not sufficient to inform users exactly how a reputation measure is derived. Thus, in other words, there is still a lack of accountability and transparency about the processes used by smart share applications: have due processes been followed, has screening been applied, how are resources matched to consumer’s preferences, how is reputation computed, and how does feedback affect reputation? These issues have been reported in a number of news articles.9 It is important that not just users are held accountable for their action but the systems are too. There are two reasons for this: (1) transparent and accountable systems increase a user’s understanding of its processes, and therefore can increase the user’s trust of the system; and (2) accessible accounts enable user’s to feel that their actions can be monitoring, thus incentivising them to conduct themselves in a respectable manner. Weitzner et al. [26] advocate new governance and frameworks to hold people accountable for the misuse of data, and suggest that provenance [19] can help towards this aim. Specifically, provenance [20] is a record that describes the people, institutions, entities, and activities involved in producing, influencing, or delivering a piece of data or a thing. PROV [20] is a W3C standard for provenance, which provides a domain-agnostic information about the relationship between provenance elements, which can be a PROV entity, activity or agent. However, combined with semantics, PROV becomes a rich resource which can be exploited to provide users understandable accounts of automated processes, promoting transparency and accountability of smart sharing services themselves. Provenance data can be hard for both expert and non-expert users to understand because of its technical content, and its potential scale and complexity. However, PROV [20] provenance, given its well-defined nature, is well suited to construct narratives. The role of narratives is to provide an account of connected events, which can be organised in a number of different categories [2]. Textual narratives can be used to improve 9 http://www.bbc.co.uk/news/ technology-29740296 http://edition.cnn. com/2011/TRAVEL/08/01/online.rental. horror.stories/index.html http:// nymag.com/daily/intelligencer/2014/09/ silicon-valleys-contract-worker-problem.html
3
transparency because they explain who performed processes and their inputs and outputs. This paper posits that using semantics to enrich PROV D - M [20] to automatically generate sentences using templates, improves PROV’s supports both systems transparency and accountability. It presents a framework for accountability, which is comprised of services, one of which is a provenance enabled reputation service, and an explanation service which provides a narrative of a provenance subject. This work is the first to use provenance, semantics, and narratives, to provide an account of how documents, data, and information are used, modified, and created by both users and services. Extant state-of-the-art frameworks tend to focus on logging this information, but do not present it in an easy to understand format to users. Presenting information in an accessible format allows all types of users to audit and become aware of their actions within a system. This paper argues that the role of provenance and its semantic markup is critical in building accountable Smart City applications. Specifically, this paper contributes towards the state-of-the-art: 1. A vocabulary specifically designed to support the markup of provenance to support accountability. It describes services, activities, and entities within a Smart City application. 2. A framework that supports accountability as a service, and includes the following components: (1) The reputation service, a PROV-enabled reputation system that uses the Smart City vocabulary to markup its provenance; (2) The explanation service, which provides a narrative on the provenance of a give piece of information using the terms defined in the Smart City application vocabulary. 3. Provenance explanation examples that demonstrate the benefits of using semantics to provide an account of provenance. The remainder of this paper is organised as follows. Section 2 describes the background literature on accountable frameworks for distributed services and narrative for accountability. Section 3 then presents a vocabulary for Smart City applications. Following that, Section 4 describes an accountable framework and how it uses the vocabulary. Then, Section 5 presents a ride sharing scenario using the framework and vocabularies. Succeeding that, Section 6 details examples from the ride sharing scenario and narrative examples. Finally Section 7 provides conclusions.
2. Background Work There have been a variety of frameworks proposed to support accountability in online services and systems.Huang et al. [13] present PlanetFlow a network auditing service designed specifically for PlanetLab, which is a geographically distributed platform designed to support the deployment and evaluation of planetary-scale network services. It provides permanent accountability for all traffic generated by PlanetLab services, in accordance with common Internet practice and terms of the PlanetLab Acceptable Use Policy. Their auditing service collects IP packets which are then stored in a database and they further provide an interface for querying the database. Due to the large scale of PlanetLab they encountered problems, such as filesystem corruption, database corruption, process termination, bugs, and race conditions caused by system load. This system only logs the flow data, whereas this paper proposes marking up provenance data with additional semantics and presenting an account of data elements in a narrative form so it can be easily digested by end users. Accountability in distributed systems is proposed by Yumerefendi et al. [28] as a general design goal for dependable network systems. They present an accountability framework which preserves digitally signed records of actions and internal states of a services. Their framework detects tampering and verifies the consistency of actions and behaviour, thus proving the responsibility for actions and states. In contrast, the framework presented in this paper focuses on describing an accessible account to users which may or may not expose tampering or consistencies of behaviour. Similarly, Chun et al. [5] describes a layered architecture for addressing the end-to-end trust management and accountability problems in federated systems. They leverage trust relationships for accountability, along with authentication and anomaly detection, and use third party services for monitoring lower level system resources. Weitzner et al. [27] present the Policy Aware Web infrastructure, which supports transparent and accountable data for use on the World Wide Web. They also describe elements of a new legal and regulatory regime aimed to support privacy through provable accountability to usage rules, instead of merely enforcing data access restrictions. A described example infrastructure has a proof generator which “constructs proofs that critical transitions and adverse uses of personal information are justified by facts and permissible
4
under applicable rules.” They identify considerations for legal rules for accountable systems, including “(1) what degree of transparency rights should those subject to data mining have, (2) what will be the mechanism for the correction of data found to be incorrect, and (3) will there be legal recourse in the event agencies rely on incorrect information after the error has been pointed out by the subject”. This work highlights the need for users to be able to understand which information held is about them and how it is used. Provenance data can be used for accountability [11, 19], provided that users can rely on the provenance record and authenticate its sources so that it can be used to assign credit or blame. Halpin [12] argues that provenance information can be used as the foundation for a model of privacy and trust in the context of the Semantic Web. Ruth et al. [24] discuss the use of provenance in a layered architecture for accountability in cloud computing. However, because of the limits of cloud computing, provenance techniques such as audit trails were not possible because it was not feasible to store all the versions of the resources referenced in the provenance records. Existing work on building accountability into electronic commerce protocols bears some similarity accountability in Smart City applications. For example, Crispo et al. and Kailar et al. [7,15] describe frameworks for analysing accountability in communication protocols; [6] discusses the delegation of trust with full accountability for electronic commerce applications. The models presented in this work influence the vocabulary for accountable Smart City applications . Similarly, [23] introduces social computations, which aligns with the social component of Smart City applications. They introduce an abstract model for social computation, and relevant terms. These models and terms influence the proposed Smart City vocabulary. Narratives are potentially the most accessible way to communicate information, they provide an account of connected events, which can be organised in a number of different categories. Research has shown that it is how users make sense of their own information [4,16,18], and it is effective to communicate with communities and individuals [8,17]. It is well suited to describing provenance data because of the well defined PROV . Previously, Semantic Web technologies have been used to generate narratives [25,14,10]. In more detail, Tuffield et al. [25] and Jewell et al. [14] describe the OntoMedia ontology, which supports the generation of narratives. The work presented in [25] discuss ap-
proaches to generate narratives from a vocabulary, the approaches included are based on character, plot and user modelling. While, the work presented in [14] describes how OntoMedia is used to annotate the vast collection of heterogeneous media. The work [10] use ontological domain knowledge to select and organise a narrative discourse on an interest topic to a user.
3. Smart City Vocabulary A vocabulary to describe Smart City actors, activities and entities is required to provide types to provenance elements, so that the types can be exploited by other services. The type information allows services to apply their own constraints, facilitating the leverage the information in the provenance. The class of Smart Share applications envisaged for the Smart City involve agents, humans or otherwise, having capabilities they wish to offer as a service to other agents, typically humans those having specific requirements, in terms of baby-sitters, car space, or rides. For instance, the agents have been abstract using the notions of peers. Resolving a Smart Share problem involves the use of an orchestrator responsible for matching tasks to peers and scheduling their execution, resulting in the desired allocations of baby-sitters to families, or assignments of car spaces to drivers. To become accountable, a Smart City application needs to be able to describes how this allocation of tasks and their scheduling are achieved, and hence, it requires a vocabulary that involves notions of peers, capabilities, tasks. Services shared via Smart City applications rely on reputation to set them apart from on another. Reputation is created by word of mouth or feedback from consumers of the service, and can be viewed by the community of a Smart City application. Reputation can also be provided by a set of consumers, a collective which represents a groups’ view on a service. To support services in managing feedback and reputation the vocabulary for Smart City provides notions of reputation reports, feedback reports, collectives, and a reputation peer. Concretely, the Smart City vocabulary focuses on describing three components: (1) agents within a Smart City application, including users, peers, and collectives and their properties; (2) activities; and, (3) entities describing plans, tasks and messages. The namespace used for the vocabulary is http://
5
smartsociety-project.github.io/cas/ and it defines the following terms: – An agent is anything that can perform an activity; alternatively, anything that has capabilities. – A user is a person who is using a SmartSociety system. – A peer is a software agent in a SmartSociety system that represents another agent. – Agents, users, peers all have identities; an unauthenticated user gets an assigned identity. – A collective is an agent that consists of multiple member agents. – An activity is the condition in which things are happening or being done. – A capability is a prospective, though not necessarily planned or agreed, activity. – A task is something that involves capabilities, potentially contributed by several agents. – A plan is a specification for the execution of a task. – A protocol is a collection of plans that involve communications between peers. – A message is a piece of information exchanged between agents. – A messaging action is the constituent of a protocol: it involves information exchange and subsequent action. – A feedback report is a report about a subject that contains a set of value rating categories. For example, "star rating = 4.3". – 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". – A reputation peer is a peer that specialises in storing feedback about subjects and generating reputation about subjects. 4. Accountability as a Service To make an application accountable, several key pieces of functionality need to be available: tracking application’s actions and decisions; providing explanations for all aspects of the system; managing feedback about all its components; and calculating their reputation. Such accountability functionality is non-trivial and requires substantial design and implementation efforts. It is therefore critical to make it reusable, so that
it can easily be deployed in multiple Smart City applications. Therefore, embracing service-oriented architectures [9], the concept of accountability as a service is proposed, which consists of exposing accountabilityrelated functionality into a set of well-defined and reusable APIs (Application Programming Interfaces). Such APIs are intended to be application and domainindependent, and they can be deployed in Smart City application. These APIs can be held peers accountable for their actions; thus, this increases user’s trust and adoption of the system, and it also increase user’s awareness that their actions matter. The role of the accountability service is to provide accounts of actions performed by Smart City application’s peers who are identified, and how entities are created, modified and viewed. It is important that order to support this, the framework has the following requirements: 1. Provide a record of peers, entities, and activities involved in Smart City applications, in particularly pertaining to the generation of automated processes such as reputation generation and matching users to services; 2. Provide a reputation service that manages feedback and reputation; 3. Provide accessible accounts to users to explain automated processes. The framework to support accountability as a service is designed to support the above requirements, and it is comprised of the components (see Figure 1): 1. ProvStore which is a specialised service for storing provenance. It supports the first requirement by storing the provenance records detail the peers, entities and activities in Smart City Applications. 2. A set of peers which submits provenance to ProvStore detailing who performed which activities and where entities are derived from. This component also supports the first requirement, by providing provenance. 3. The reputation peer which stores feedback reports on subjects and computes the reputation reports based on feedback reports. It also submits provenance to ProvStore. This component supports the second requirement by providing a service to manage feedback and reputation. 4. The explanation peer uses provenance from ProvStore to generate a textual explanation of a
6
provenance element. This component supports the third requirement by generating narratives about a provenance subject.
back reports are comprised of key-value pairs describing attributes about a subject, and meta-information about feedback which includes who or what it is about, the authors, and associated events (see Figure 2 for an example). {
Fig. 1. Layered model of the components in the smart cities accountability framework.
The provenance submitted to ProvStore is described using PROV, which uses the PROV-DM conceptual data model. The type of a provenance element is defined using prov:type whose value is from the vocabulary defined in Section 3. These types are used by the explanation peer to provide more detailed information in the textual description of a provenance element. The section is organised as follows, in Sections 4.1, 4.2 and 4.3 introduce ProvStore, Reputation Peer and the Explanation Peer, respectively. 4.1. ProvStore ProvStore is a specialised service for storing PROV. It also enables users to query provenance and generates visualisations allowing users to analyse provenance data. ProvStore’s API10 provides a RESTful web service for the storage and access of provenance documents in various representations. Via the API, any client can manipulate documents contained in the store and explore and retrieve information from them. ProvStore stores documents containing provenance descriptions. A document can contain bundles which may be added via the API. A PROV bundle is mechanism by which provenance of provenance can be expressed. 4.2. The Reputation Peer The reputation peer provides Smart City applications, with a service that manages a subject’s reputation. It stores feedback reports, computes and stores reputation reports. Once the reputation peer receives a feedback report it generates reputation reports. Feed-
}
"feedback_id": 325, "application_id" : 1, "event_id" : 24, "subjects" : {"subject_1": 4}, "authors" : {"author_1": 1}, "feedback": { "category_1": 5, "category_2": 5, .. . }
"category_n": 5
Fig. 2. An Example of a Feedback Report
The reputation report about a subject is derived from all the feedback reports posted to the peer. The categories in which a subject is rated is dependant on the categories are defined in the feedback value about that subject. The reputation peer calculates the average value of a category given a set of feedback reports (see Figure 3). {
}
"reputation_id": 135, "application_id" : 1, "subject" : 4, "feedback": { "average_category_1": 5, "average_category_2": 5, .. . }
"average_category_n": 5
Fig. 3. An Example of a Reputation Report
The provenance submitted by this peer will support the accountability of:
10 ProvStore’s REST API: https://provenance.ecs.soton.ac.uk/store/help/api/
1. Which feedback report was related to which event and who;
7
2. Which feedback reports were used to generate reputation and opinion reports; 3. Who accessed feedback, reputation, and opinion reports; 4. The security and privacy policies used to protect user’s information. The reputation peer’s resources are exposed via a REST API. Specifically, the API allows the submission of feedback reports about a subject or collective of subjects, from an author or collective of authors. 4.3. The Explanation Peer This peer provides a service that provides a narrative about a single provenance element (either an entity, activity or agent) in either a provenance document held by ProvStore or a set of provenance documents related to a specific application. It uses sentence templates to explain the provenance data about a subject. These sentence templates use both the types defined in: the PROV D - M [21]; and, the smart cities vocabulary for provenance (see Section 3). If the provenance data is not marked up with the smart cities vocabulary, the peer by default reverts back to using sentence templates based on the PROV’s types, which are described in Table 1. The templates P4-P13 in Table 1 use the relationship specified in the second column to identify the bindings for the sentence template variables. For example, if a subject is a prov:activity and has an association with a agent then the template p5 is used. It exploits the PROV’s Association relationship and uses the activity as the subject and the agent defined in this relationship to as variable binding to the P5 template, where wasAssociatedWith(subject, peer1) is used to create the sentence “It was associated with agent/s peer-1” where “It” refers to the subject. Otherwise, it overrides these default sentences using the templates in Table 2. These templates differ from the those presented in Table 1 because they can use the semantics in the sentence template to define a path of relationships to connect two provenance elements. For example, the explanation peer given the subject feedback-1 uses the feedback report template in Table 2. First, it identifies the Smart City type as a feedback report using the provenance statement (feedback-1, [prov:type=’provsm:feedback report’]). Second, it identifies generation relationships referring to that entity, where wasGeneratedBy(feedback1, feedback_submission-1, -). Third, it then iden-
tifies which agent was associatedWith the activity, where wasAssociatedWith(feedback_submission1, peer). This chain of relationships is used to identify the bindings for the feedback report’s sentence template, for example the template The {subject} is a feedback report, the feedback was left by the {peer/user/collective}. It was submitted using the {activity}. has the following bindings subject = feedback-1, {peer/user/collective} =peer, and {activity} = feedback_submission-1. If the provenance does not contain the required fields than it reverts back to using the template in Table 1. The Table 2 does not make the provenance paths used to bind the variables explicit because of conciseness, and instead uses the possible variable’s types for the bindings. Specifically, in order to generate a narrative the explanation peer: 1. Identifies the template for the subject by using the type defined either in the PROV or by a Smart City type. If it uses the PROV type then it: (a) Identifies all the provenance elements that are connected to it by provenance relations. (b) Identifies the templates for the provenance elements that connect to the subject using their PROV type. Or if it uses a Smart City type then: (a) Identifies all the provenance elements that are connected to the provenance subject described in the smart cities sentence template about the subject. (b) Identifies the templates from the Smart City templates to described the connect provenance elements. 2. The sentences about the subject and connected provenance elements are strung together to form a paragraph. 4.4. APIs Outline The frameworks adopts a REST approach [1] for accountability as a service. Tables 3 summarises the key resources related to provenance, reputation, and explanations, as well as the REST Method allowed on them. 5. Ride Share Ride Share is an application that enables car sharing for workplace workers, university students and simi-
8 Number
Prov Types
P1 P2 P3
Entity Agent Activity Prov Relations
P4 P5 P6
Alternate Association Attribution
P7 P8 P9 P10 P11
Collections Communication Delegation Derivation Specialisation and Revision
P12 P13
Generation Usage
Sentence template The {subject} is a {provtype} The {subject} is a {provtype} The {subject} is a {provtype} Sentence template It was an alternate of {alternate/s} It was associated with agent/s {agent/s} It was attributed to agent/s {agent/s} It was a member of the {collection/s} collection/s It was informed by {agent/s} It acted on behalf of {agent/s} The {subject} was derived from the entity/ies {entity/ies} The {subject} was a specialisation of the entity {entity}, and is a revision of {entity/ies} It was generated by the activity {activity/ies} It was used by the activity/ies {activity/ies} Table 1
PROV Template Sentences, where items in {} are variables which can be either a single item or a list.
lar large community members living in and around the Smart City. For example, at Ben-Gurion University, there are thousands of students coming from all over the country which has created a vivid car sharing community based on actual and acute travel needs. 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. Ride Share has been chosen because it uses automated algorithms for matching users in rides and generating reputation reports. The execution of these automated algorithms is documented using provenance, which is marked up with the smart cities vocabulary; provenance is exposed to users via the explanation peer. Without recorded provenance, smart cities vocabulary, and explanation peer, these automated process would be a black box to users. The architecture of Ride Share is based on five core components (see Figure 4): a view, ride matching peer, reputation peer, and ProvStore, organised according to the layered architecture of Figure 1. The view provides the user with the graphical components with which to enter their ride requests, and to view and select potential rides. The matching peer provides matches con-
taining drivers and commuters, which the users can select. The reputation peer and ProvStore are described in Section 4.
Fig. 4. Layered Model of Ride Share
5.1. Feedback and Reputation Reports Feedback reports can be submitted by both riders and drivers after a ride has been completed. Table 4 describes the feedback categories supported by Ride Share, in feedback reports. A reputation report is a rating of a user structured according to reputation categories; such reputation categories are defined from the categories comprised in feedback reports submitted about the user. Each reputation category value is calculated by a simple function, averaging the values associated with the corresponding feedback category in feedback reports about the user (see Table 5). At this stage, the focus of this
9
Smart City Type
Prov Type
Sentence template
agent
prov:Agent
The {subject} is an agent within a Smart City framework, that has the capabilities {capabilities}. It performed the following activities {activities}.
user
prov:Agent
The {subject} is a human user that uses the Smart City framework. It has the capabilities {capabilities}. It is identified by {identities}, which is maintained by the framework. It is the member of the collective/s {collectives}. It performed the following activities {activities}.
peer
prov:Agent
The {subject} is a software agent in the Smart City framework. It has the capabilities {capabilities}. It is identified by {identities}, which is maintained by the framework. It is the member of the collective/s {collectives}. It performed the following activities {activities}.
identities
prov:Agent
The {subject} is the identify for the {agent/user/peer} and is maintained by the Smart City framework. It was used to identify the {agent/user/peer} in the following activities {activities}.
collective
prov:Agent
The {subject} is a collective, who has the following members {agents/users/peers}. It is an agent with the Smart City framework, that has the capabilities {capabilities}. It performed the following activities {activities}.
activity
prov:Activity
The {subject} is an {agent/user/peer/collective}.
capability
prov:Entity
The {subject} is a capability, specifically in this context it describes the capability of the {agent/user/peer/collective}.
task
prov:Entity
The {subject} is a task, it describes the capabilities {capabilities} possibly involving the following agents {agents/users/peers/collectives}.
plan
prov:Entity
The {subject} is a plan, it describes the a task that has the capabilities {capabilities} which involves the following agents {agents/users/peers/collectives}.
protocol
prov:Entity
The {subject} is a protocol that describes the a task that has the capabilities {capabilities} which involves communication between the following peers {peers}.
message
prov:Entity
The {subject} is a message that describes the a task that has the capabilities {capabilities} which involves communication between the following peers {peers}.
messaging action
prov:Activity
The {subject} is an activity that sends the message {message} between the following peers {peers}. The peer {peer} was responsible for sending the message to {peer}.
feedback report
prov:Entity
The {subject} is a feedback report, the feedback was left by the {peer/user/collective} about {agent/peer/user/collective/task/plan}. It was submitted using the {activity}.
reputation report
prov:Entity
activity
performed
by
the
The {subject} is a reputation report, it was derived from the feedback reports {feedback reports}. It was generated by the {activity} and was left by the {peer/user/collective}. Table 2 Template Sentences, where items in {} are variables which can be either a single item or a list.
10 Reputation Peer REST Method
URI
Description
GET
/subject/byURI/:subject_uri
Retrieves feedback and reputation reports associated with a subject.
GET
/application/:app/subject/:subject/
GET POST
/application/:app/subject/:subject/feedback/ /application/:app/feedback/
Retrieves the set of subjects associated with an application. This calls returns all feedback id’s about a subject. Save a feedback report.
GET GET GET POST
/application/:app/feedback/:feedback/ /application/:app/subject/:subject/reputation/ /application/:app/reputation/:reputation/ /application/:app/opinions/
Retrieves a feedback report with a specific id. Retrieves the set of reputation reports about a subject. Retrieves a reputation report with a specific id. Retrieves the set of opinion reports about subjects.
/application/:app/subject/:subject
Retrieve a narrative about a subject.
GET
/store/api/v0/documents/
POST
/store/api/v0/documents/
Retrieve a list of documents visible to the authenticated user or public. Save a new document.
Explanation Peer GET Provenance Store
Table 3 API calls for the reputation, explanation and provenance peers Category
Subcategory
Description
Overall Star Rating
-
A five star rating for the ride
Ride
Price Route Timeliness
A five star rating for the price of the ride A five star rating for the route of the ride A five star rating indicating whether the commuter was ready on time
Individual
Reliability Communication Friendliness
A five star rating indicating the reliability of the commuter. A five star rating indicating the communication during the ride. A five star rating indicating the commuter’s friendliness.
Table 4 Categories and Descriptions for User Feedback.
work is to explain to users how their ratings are computed; over time, there will be an investigate into more complex functions to compute reputation category values. 5.2. Ride Share Vocabulary In addition to the vocabulary defined for Smart City applications, the following subtypes for Ride Share are used and the hierarchy of the model is shown in Table 6. This vocabulary focuses on describing the activities in Ride Share. Providing precise typing about these different activities then enables the explanation peer to provide individualised descriptions of Ride Share activities. The namespace used for the vocabulary is http://smartsociety-project. github.io/cas/ and it defines the following terms:
1. A driver is a user that has a role as a driver. 2. A rider is a user that has a role as a rider. 3. ride_feedback_report is a feedback report that pertains to a ride. 4. submitting_feedback is an activity that submits a feedback report to the reputation peer. 5. storing_feedback is an activity used by reputation peer to store a feedback report within it. 6. ride_request is a task that describes a ride request and contains information about a proposed ride including, date and time, origin and destination, and the role of the user submitting the task. 7. A reputation_item is a JSON object that is returned from a GET request to the reputation peer. 8. authenticating_activity is an activity which authenticates a user.
11 Category
Subcategory
Formula
Average Overall Star Rating
-
average(overall_star_rating)
Ride
Average Price Average Route
average(price) average(route)
Average Timeliness
average(timeliness)
Average Reliability Average Communication Average Friendliness
average(reliability) average(communication) average(f riendliness)
Individual
Table 5 Reputation categories and formula for summary driver and commuter reports
9. storing_task is an activity that stores a task locally. 10. computing_composition is an activity that computes a set of valid tasks given constraints or negotiation inputs. 11. computing_task_complement is an activity that identifies which set of tasks that are no longer valid. 12. sending_request is an activity that sends a request to peer. 13. sending_negotiation_response is an entity that contains the response to a negotiation activity. 14. posting_task_request is an activity that posts a task to orchestration peer. 15. changing_view is an activity that changes the view in a UI. 16. composing_activity is an activity that may be comprised of the following activities authenticate, compute_composition and compute_task_ complement. 17. negotiating_activity is an activity which submits a task that may be used to modify another task, it may comprise of an authenticate and storing_task activities. 18. submitting_activity is an activity which submits a task, it may comprise of an authenticate and storing_task activities. 19. computing_reputation is an activity that is run by the reputation peer when a feedback report is submit, it computes a reputation report for all the subjects referred to by the submitted feedback report. 5.3. Sentence Templates for Ride Share The Ride Share vocabulary enables the explanation peer to tailor the sentences it generates, with descriptions of the specific activities in Ride Share. Table
Prov type
Smart City type
Ride Share type
prov:Entity prov:Activity prov:Activity prov:Activity prov:Activity
entity activity activity activity activity
ride_feedback_report submitting_feedback storing_feedback computing_reputation composing_activity
prov:Activity prov:Activity prov:Activity prov:Activity prov:Activity prov:Activity prov:Activity prov:Activity
activity activity activity activity activity activity activity activity
authenticating_activity storing_task computing_task_complement submitting_activity sending_negotiation_response negotiating_activity posting_task_request sending_request
prov:Activity prov:Entity
activity plan
changing_view ride_plan
Table 6 The hierarchy of the Ride Share vocabulary.
7 details the sentence templates exploiting the Ride Share vocabulary, similar to Table 2 it does not make the provenance paths used to bind the variables explicit because of conciseness, and instead uses the possible variable’s types for the bindings. The explanation peer is used to explain the provenance data stored by Ride Share to its users. Specifically, it can describe: 1. The generation of reputation and opinions reports; 2. The generation of ride plans; 3. The negotiation process among users for selecting ride plans.
12 Id
Ride Share type
Sentences
RS1
reputation_report
RS2
submitting_feedback
RS3
storing_feedback
RS4
computing_reputation
RS5
composing_activity
RS6
authenticating_activity
RS7
storing_task
RS8
computing_composition
The {subject} is a reputation report. It was generated by the {computing_reputation} activity and by the {peer}. The submit feedback activity {subject} was performed by the {peer}. This activity submitted the feedback {ride_feedback_report} to the {reputation_peer}. The store feedback activity {subject} was performed by {reputation_peer}. This activity was used to store the feedback {ride_feedback_report} in the {reputation_peer}’s store. The compute reputation activity {subject} was performed by {reputation_peer}.This activity generated the reputation report {reputation_report} for the {user}, and was derived from the following feedback reports {feedback_reports}, it averaged the ratings for each of the categories in the feedback reports. The composition activity {subject} was performed by {peer}. The composition activity is comprised of the following activities {computing_composition}, {computing_task_complement} and {sending_response}, it triggered the activity {sending_response}. The authenticate activity {subject} was performed by {peer}, uses the {peer}’s identity to authenticate it. The store task activity {subject} was performed by {peer}, and it stored the task {task} in its store. The compute composition activity {subject} was performed by {peer}, it generates potential ride matches between current ride requests and matches on a requests origin, destination and time. The following ride requests {tasks} were matched using this activity.
RS9
computing_task_complement
RS10
submitting_activity
RS11
sending_negotiation_response
RS12
negotiating_activity
RS13 RS14
posting_task_request sending_request
RS15
changing_view
RS16
ride_plan
RS17
ride_request
RS18
sending_response
RS19
feedback_report
The compute task complement activity {subject} was performed by {peer}, it generates the complement set to potential ride matches and contains ride plans that are no longer valid or that weren’t feasible based on ride request’s origin, destination and time. The following rides were classified as complementary {task}. The submit activity {subject} was performed by {peer}, it is a composition of activities that include {authenticating_activity}, a {computing_composition} and {storing_task}, it triggered the activity {sending_response}. The sending negotiation response {subject} activity was performed by {peer} and it sent the {task}. The negotiation activity {subject} was performed by {peer}. The negotiation activity is comprised of the following activities {authenticating_activity}, {computing_composition}, {storing_task}, it triggered the activity {sending_response}. The post task request activity {subject} was performed by {peer}. The send request request activity {subject} was performed by {peer}, by a user with the identity {identity} via the {peer}. The change view activity {subject} was performed by {peer}, by a user with the identity {identity} via the {peer}. The ride plan {subject} was generated by the {computing_composition} activity. It details the attributes of a ride including its date and time, the origin and destination, and its potential participants and their roles. It was derived from the ride requests {ride_requests}. It was generated by the {activity}. The ride request {subject} was submitted by {user} and it was generated by {sending_request}. It includes information about a requested rides date and time, the origin and destination, and the role played by the {user}. The sending response task {subject} sends an acknowledgement to the {peer} to say that the {activity} has completed. The feedback report {subject} was generated by the {submitting_feedback} activity. It contains the reputation left by {user}. Table 7
Ride Share Template Sentences, where items in {} are variables which can be either a single item or a list.
13
6. Ride Share Accountability Use Cases This section expands on the three use cases identified in Section 5.3 by providing examples of relevant provenance collected from the different peers within Ride Share. For each use case, the explanation peer to generate two narratives: the first narrative exploits the semantics provided by the Smart City/Smart Share vocabularies, whereas the second narrative simply relies on the domain-agnostic types and relations provided by PROV. Presenting these two narratives demonstrates the benefits of decorating provenance with applicationspecific semantics. 6.1. Accountability for Ride Plans Ride Share generates ride plans when the ride matching peer receives a ride request. The provenance recorded for such ride plans includes descriptions about: which views the user viewed; the submission of the ride request via the UI; the ride matching peer storing and generating ride plans; and the request that the ride matching peer sends the reputation peer for opinion reports. An example of the provenance data collected can be seen in Figure 5. This use case is required to provide systems accountability for the generation of ride plans, therefore the ride plan rideplan:1 is used as the subject. The following narrative was generating using the semantics defined by the Smart City and Ride Share vocabularies: Ride Share Narrative: The ride plan rideplan:1 was generated by the rideshareapp:composition-1 activity. It details the attributes of a ride including its date and time, the origin and destination, and its potential participants and their roles. It was derived from the ride requests with the ids 1 and 2. The ride request riderequest:1 was submitted by usr:ido. It includes information about a requested rides date and time, the origin and destination, and the role played by the usr:ido. The ride request riderequest:2 was submitted by usr:avi and it was generated by view:submitRequestButton. It includes information about a requested rides date and time, the origin and destination, and the role played by the usr:avi and it was generated by view:submitRequestButton. The compute composition activity rideshareapp:composition-1 was performed by rideshareapp:rsa, it generates potential ride matches between current ride requests
and matches on a requests origin, destination and time. The following ride requests with the ids 1 and 2 were matched using this activity. In contrast, the following narrative was generated about the same subject (rideplan:1) using sentence templates relying on the PROV semantics but ignoring the Ride Share types. PROV Narrative: The rideplans:1 is a prov:Entity. Entity rideplans:1 was derived from riderequest with the ids 1 and 2. It was associated with agent/s rideshareapp: rsa. It was generated by the activity rideshareapp:composition-1. The riderequest:1 is a prov:Entity. It was associated with agent/s rideshareapp:rsa. It was generated by the activity view:submitRequestButton. The riderequest:2 is a PROV:entity. It was associated with agent/s rideshareapp:rsa. It was generated by the activity view:submitRequestButton.
In order to compare the two narratives, the sentences about the same provenance elements and relationships from both narratives are presented side by side (see Table 8). The table shows that the Ride Share Narrative provides additional information about activities in the form of summary description (see RS8 in Table 8). In contrast, the PROV Narrative was unable to provide this information, because this information not available via the provenance: the provenance only exposes who performed an active and any inputs or outputs. The narratives also differ when describing who is associated with the generating ride requests. The Ride Share Narrative describes the user submitting a request via an agent (see RS17 in Table 8). In contrast, the PROV Narrative only details the agent (see P5 in Table 8), because it could exploit more data from the provenance because of the specialised sentence templates. In general, the sentences in PROV Narrative lack clarity about the relationships and roles of the provenance elements, while the Ride Share Narrative was able to provide it because of the additional semantics in the Ride Share vocabulary. 6.2. Accountability for Negotiation Processes The negotiation process among users for selecting ride plans requires a potential user agreeing to a particular ride plan. The provenance recorded during a negotiation includes descriptions about: which views the user viewed; the submission of the negotiation offer via the UI; the ride matching peer using the offer to
14
Fig. 5. The provenance data recorded from the submission https://provenance.ecs.soton.ac.uk/store/documents/33414/).
of
a
ride
request
(for
more
details
15
Fig. 6. The provenance data recorded from the submission of https://provenance.ecs.soton.ac.uk/store/documents/33415/)
a
negotiation
offer
(for
more
details
16 Table 7 Id
Sentence
Table 1 Id
Sentence
RS16
The ride plan rideplan:1 was generated by the rideshareapp:composition-1 activity.
P1, P6
The rideplans:1 is a prov:Entity. It was attributed to rideshareapp:composition-1.
RS16
It details the attributes of a ride including its date and time, the origin and destination, and its potential participants and their roles.
-
RS16
It was derived from the ride requests with the ids 1 and 2.
P10
Entity rideplans:1 was derived from riderequest with the ids 1 and 2.
RS17
The ride request riderequest:1 was submitted by usr:ido and it was generated by the view:submitRequestButton.
P1, P5, P12
The riderequest:1 is a prov:Entity. It was associated with agent/s rideshareapp:rsa. It was generated by the activity view:submitRequestButton
RS17
It includes information about a requested rides date and time, the origin and destination, and the role played by the usr:ido.
-
RS17
The ride request riderequest:2 was submitted by usr:avi and it was generated by view:submitRequestButton.
P1, P5, P16
RS17
It includes information about a requested rides date and time, the origin and destination, and the role played by the usr:avi.
-
-
RS8
The compute composition activity rideshareapp:composition-1 was performed by rideshareapp:rsa, it generates potential ride matches between current ride requests and matches on a requests origin, destination and time. The following ride requests with the ids 1 and 2 were matched using this activity. Table 8
-
-
-
-
The riderequest:2 is a prov:Entity. It was associated with agent/s rideshareapp:rsa. It was attributed to view:submitRequestButton.
Comparison Table for Ride Plans Narratives
generate valid and invalid ride plans. An example of the provenance data can be seen in Figure 6. This use case is required to provide systems accountability about how Ride Share handles negotiations and how it uses the negotiation to generate valid and invalid ride plans. Therefore, an explanation of the negotiation rideshareapp:negotiation-1 is used as the explanation subject. The generated sentences are present in Table 9, sentences about the same provenance elements and relationships from both narratives are presented side by side. As in the previous use case the table shows that the Ride Share Narrative provides more detailed information about activities than the PROV Narrative. With the addition of the smart share vocabulary the Ride Share Narrative was aware that the negotiation was a composed of a set of activities, whereas the PROV Narrative could not leverage the provenance for this information because it is not expressed using PROV. Therefore the Ride Share Narrative could describe the set of activities that the PROV Narrative could not.
6.3. Accountability for Reputation Reports Ride Share generates reputation and opinion reports when the reputation peer receives a feedback report. The provenance recorded for the submission of feedback includes descriptions about: which views the user viewed; the submission of the feedback report via the UI; the reputation peer storing and generating reputation and opinion reports. An example of the provenance data can be seen in Figure 7. The generated sentences are present in Table 10, sentences about the same provenance elements and relationships from both narratives are presented side by side. As in the previous two use cases the table shows that the Ride Share Narrative provides more detailed information about activities than the PROV Narrative. 6.4. Analysis The aim of the analysis is to contrast Ride Share Narratives and PROV Narratives, by identifying dis-
17
Table 7 Id RS12
RS18
Sentence
Table 1 Id
Sentence
The negotiation activity rideshareapp:negotiation-1 was performed by rideshareapp:rsa.
P3, P5, P8
The rideshareapp:negotiation-1 is a prov:Activity. It was associated with agent/s rideshareapp:rsa. rideshareapp:negotiation-1 was informed by rideshareapp:sendResponse-2.
-
P2
The sending response rideshareapp:sendResponse-2 sends an acknowledgement to rideserver:OpenRideServer-RS/ to that the rideshareapp:negotiation-1 completed.
task
P3, P5, P12, P8
the say has
The rideshareapp:rsa is a prov:Agent. The rideshareapp:sendResponse2 is a prov:Activity. It was associated with agent/s rideshareapp:rsa. rideshareapp:200 was generated by the activity rideshareapp:sendResponse-2. rideshareapp:sendResponse-2 was informed by rideshareapp:negotiation-1.
RS12
The negotiation activity is comprised of the following activities rideshareapp:authentication-2, rideshareapp:generateComposition-2, rideshareapp:generateTaskComplement-2, and rideshareapp:storeTask-1.
-
-
R6
The authenticate activity rideshareapp:authentication-2 was performed by rideshareapp:rsa, uses the usr:ido’s identity to authenticate it.
-
-
RS8
The compute composition activity rideshareapp:generateComposition-2 was performed by rideshareapp:rsa, it generates potential ride matches between current ride requests and matches on a requests origin, destination and time. The following ride requests riderequest:1 were matched using this activity.
-
-
RS9
The compute task complement activity rideshareapp:generateTaskComplement-2 was performed by rideshareapp:rsa, it generates the complement set to potential ride matches and contains ride plans that are no longer valid or that weren’t feasible based on ride request’s origin, destination and time. The following rides were classified as complementary ride plan:1 and ride plan:2.
-
-
RS7
The store task activity rideshareapp:storeTask-1 was performed by rideshareapp:rsa, and it stored the task rideshareapp:offeres/t1 in its store.
-
-
Table 9 Comparison Table for Negotiation Processes Narratives
18
Fig. 7. The provenance data recorded from a submitting feedback (for more details https://provenance.ecs.soton.ac.uk/store/documents/33416
19 Table 7 Id
Sentence
Sentence
Table 1 Id
RS1
The ride_manager:application/1/reputation/1/ is a reputation report, it was derived from the feedback reports with ids 0, it averaged the ratings for each of the categories in the feedback reports.
P1, P10
The ride_manager:application/1/reputation/1/ is a prov:Entity. It was derived from feedback with the ids 0.
RS1
It was generated by ride_manager:generate_reputation-1 activity and was left by usr:ido.
P5, P12
It was associated with agent/s rideshareapp: rsa. It was generated by the activity ride_manager:generate_reputation-1.
RS4
The compute reputation activity was performed by ride_manager:reputation_peer.This activity generated the reputation report ride_manager:application/1/reputation/1/, and was derived from the feedback reports with ids 1 and 2.
-
RS19
The feedback report ride_manager:application/1/feedback/0/ was generated by the ride_manager:storing_feedback-1 activity. It contains the reputation left by usr:ido
P1, P5 and P12
the
-
The feedback:0 is a prov:Entity. It was associated with agent/s rideshareapp:rsa. It was generated by the activity view:submitFeedbackButton.
Table 10 Comparison Table for Reputation Reports number of generic sentences
number of specialised sentences
number of resources exploited
1: Ride Share Narrative 1: PROV Narrative
0 8
9 0
9 6
2: Ride Share Narrative 2: PROV Narrative
0 7
10 0
13 4
3: ride share narrative 3: PROV narrative
0 7
6 0
7 3
use case
Table 11 Summary statistics for the use case narratives
criminating characteristics of these narratives. To this end, sentences are categorised as either generic or specialised. Generic sentences are generated by making use of PROV concepts only, as per Table 1, whereas specialised sentences are those constructed with knowledge of Ride Share types, as per Table 7. Furthermore, given that the sentence template variables are placeholders for resources to be extracted from the provenance, and quantify the number of resources that each narrative exposes. Table 11 shows that the explanation successfully uses the Smart City vocabulary and that the vocabulary has good coverage of the terms used in the provenance for Ride Share. Specifically, the Ride Share narratives all use specialised sentences, whereas the PROV narratives use generic sentences. Also because of the
specialised semantics for the Ride Share application, the explanation peer was able to expose more of the resources that were relevant to the provenance subject. In more detail, the explanation peer could not identify all the activities that were related to composite activities in the second use case. Therefore, the Ride Share narrative exposed nine more resources than the PROV narrative. In the third use case, the PROV narratives uses more sentences to describe fewer resources, than the Ride Share narrative. This is because the sentence templates leveraged by the semantics in the Smart City vocabulary explicitly define associations between the provenance elements and therefore can explain more resources in fewer sentences.
20
7. Conclusion
8. Acknowledgments
The paper presents a vocabulary for Smart City applications that supports an accountable framework. The framework uses provenance to provide an account about how documents, data, and information in a Smart City application are used, modified, and created by both users and peers. The role of provenance and its semantic markup is critical to build accountable Smart City applications. The framework also provides users with narratives generated to support the transparency of automated processes. Specifically, this paper contributes to the state-of-the-art: A Smart City vocabulary specifically designed to support the markup of provenance to support accountability. The vocabulary is designed to support a board class of applications, however, it is beneficial to expand these terms to include information about how specific types of activities function; A framework that supports transparency and accountability using PROV, including the:
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/.
1. The reputation peer, a provenance enable reputation system that uses the Smart City vocabulary; 2. The explanation peer, which provides a narrative about a specified provenance element using the terms defined in the Smart City application vocabulary. ; and, provenance explanation examples that demonstrate the benefits of using semantics to provide an account of provenance. The uses case discussed in Section 6 show that the explanation generated based on the Smart City vocabulary were able to exploit more data from the provenance, and could provide more specialised sentences describing a provenance subject. This work will be extended in four ways, it will : Firth, investigate how provenance data and the Smart City vocabulary can be extended or used to generate narratives for collectives, and how a narrative can be condensed while identifying commonalities and outliers in collectives. Second, support privacy by using provenance data that has been transformed to obfuscate and remove concepts that refer to sensitive information or are private because of privacy policies. Third, evaluate the explanation service’s narrative via a user study to validate how effect narrative to support decision making processes. Fourth, extend the json used in the serialisations so that they support json-DL.
References [1] Subbu Allamaraju. RESTful Web Services Cookbook. O’Reilly, 2010. [2] Ruth A Berman and Dan Isaac Slobin. Relating events in narrative: A crosslinguistic developmental study. Psychology Press, 2013. [3] Alessandro Bogliolo, Paolo Polidori, Alessandro Aldini, Waldir Moreira, Paulo Mendes, Mursel Yildiz, C Ballester, and J Seigneur. Virtual currency and reputation-based cooperation incentives in user-centric networks. In Wireless Communications and Mobile Computing Conference (IWCMC), 2012 8th International, pages 895–900. IEEE, 2012. [4] Andrew D Brown, Michael Humphreys, and Paul M Gurney. Narrative, identity and change: a case study of laskarina holidays. Journal of organizational change management, 18(4):312–326, 2005. [5] Brent N Chun and Andy Bavier. Decentralized trust management and accountability in federated systems. In System Sciences, 2004. Proceedings of the 37th Annual Hawaii International Conference on, pages 9–pp. IEEE, 2004. [6] Bruno Crispo. Delegation protocols for electronic commerce. In Computers and Communications, 2001. Proceedings. Sixth IEEE Symposium on, pages 674–679. IEEE, 2001. [7] Bruno Crispo and Giancarlo Ruffo. Reasoning about accountability within delegation. In Information and Communications Security, pages 251–260. Springer, 2001. [8] Olivier Ferret. How to thematically segment texts by using lexical cohesion? In Proceedings of the 36th Annual Meeting of the Association for Computational Linguistics and 17th International Conference on Computational Linguistics-Volume 2, pages 1481–1483. Association for Computational Linguistics, 1998. [9] Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. [10] Joost Geurts, Stefano Bocconi, Jacco Van Ossenbruggen, and Lynda Hardman. Towards ontology-driven discourse: From semantic graphs to multimedia presentations. Springer, 2003. [11] Paul Groth, Yolanda Gil, James Cheney, and Simon Miles. Requirements for provenance on the web. International Journal of Digital Curation, 7(1):39–56, 2012. [12] Harry Halpin. Provenance: The missing component of the semantic web for privacy and trust. In Trust and Privacy on the Social and Semantic Web (SPOT2009), workshop of ESWC, 2009.
21 [13] Mark Huang, Andy Bavier, and Larry Peterson. Planetflow: maintaining accountability for network services. ACM SIGOPS Operating Systems Review, 40(1):89–94, 2006. [14] Michael O. Jewell, K. Faith Lawrence, Mischa M. Tuffield, Adam Prugel-Bennett, David E. Millard, Mark S. Nixon, m.c. schraefel, and Nigel R. Shadbolt. Ontomedia: An ontology for the representation of heterogeneous media. In Multimedia Information Retrieval Workshop (MMIR 2005) SIGIR. ACM SIGIR, 2005. Event Dates: 08/05. [15] Rajashekar Kailar. Reasoning about accountability in protocols for electronic commerce. In Security and Privacy, 1995. Proceedings., 1995 IEEE Symposium on, pages 236–250. IEEE, 1995. [16] Allan Kuchinsky, Celine Pering, Michael L Creech, Dennis Freeze, Bill Serra, and Jacek 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. [17] Claude Lévi-Strauss. Structural anthropology. Basic Books, 2008. [18] Yutaka Matsuo and Mitsuru Ishizuka. Keyword extraction from a single document using word co-occurrence statistical information. International Journal on Artificial Intelligence Tools, 13(01):157–169, 2004. [19] Luc Moreau and Paul Groth. Provenance: An introduction to prov. Synthesis Lectures on the Semantic Web: Theory and Technology, 3(4):1–129, 2013. [20] Luc Moreau and Paolo Missier. Prov-dm: The prov data model. 2013. [21] Luc Moreau, Paolo Missier (eds.), Khalid Belhajjame, Reza B’Far, James Cheney, Sam Coppens, Stephen Cresswell, Yolanda Gil, Paul Groth, Graham Klyne, Timothy Lebo, Jim
[22] [23]
[24]
[25]
[26]
[27]
[28]
McCusker, Simon Miles, James Myers, Satya Sahoo, and Curt Tilmes. PROV-DM: The PROV Data Model. W3C Recommendation REC-prov-dm-20130430, World Wide Web Consortium, October 2013. Helen L Partridge. Developing a human perspective to the digital divide in the’smart city’. 2004. Michael Rovatsos. Multiagent systems for social computation. In Proceedings of the 2014 international conference on Autonomous agents and multi-agent systems, pages 1165–1168. International Foundation for Autonomous Agents and Multiagent Systems, 2014. Paul Ruth, Dongyan Xu, Bharat Bhargava, and Fred Regnier. E-notebook middleware for accountability and reputation based trust in distributed data sharing communities. In Trust Management, pages 161–175. Springer, 2004. Mischa M Tuffield, Dave E Millard, and Nigel R Shadbolt. Ontological approaches to modelling narrative. In 2nd AKT DTA Symposium, 2006. Event Dates: January 2006. Daniel J Weitzner, Harold Abelson, Tim Berners-Lee, Joan Feigenbaum, James Hendler, and Gerald Jay Sussman. Information accountability. Communications of the ACM, 51(6):82– 87, 2008. Daniel J Weitzner, Harold Abelson, Tim Berners-Lee, Chris Hanson, James Hendler, Lalana Kagal, Deborah L McGuinness, Gerald Jay Sussman, and K Krasnow Waterman. Transparent accountable data mining: New strategies for privacy protection. 2006. Aydan R Yumerefendi and Jeffrey S Chase. Trust but verify: accountability for network services. In Proceedings of the 11th workshop on ACM SIGOPS European workshop, page 37. ACM, 2004.
c SmartSociety Consortium 2013-2017
B
Deliverable D2.2
HDA-CASs Vocabulary
56 of 65
http://www.smart-society-project.eu
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$