D2.2 - Provenance, Trust, Reputation and Big Data

SmartSociety

Hybrid and Diversity-Aware Collective Adaptive SystemsWhen 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(Confidentiality):1

PU

Delivery Date in Annex I: 31/1/2013Actual Delivery Date December 23, 2014Status2 FTotal Number of pages: 65Keywords: Provenance, Reputation, Accountabil-

ity, Transparency, Scalability, RideShare Application

1PU: Public; RE: Restricted to Group; PP: Restricted to Programme; CO: Consortium Confi-dential as specified in the Grant Agreeement

2F: Final; D: Draft; RD: Revised Draft

c© SmartSociety Consortium 2013-2017 Deliverable D2.2

2 of 65 http://www.smart-society-project.eu

Deliverable D2.2 c© SmartSociety Consortium 2013-2017

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: SmartSociety: Hybrid and Diversity-Aware CollectiveAdaptive Systems: When People Meet Machines toBuild a Smarter Society

Project Acronym: SmartSociety

Grant Agreement Number: 600854

Number and title of work-package:

WP2 Modelling Framework

Document title: Provenance, Trust, Reputation and Big Data

Work-package leader: Luc Moreau, SOTON

Deliverable owner: Lue Moreau, SOTON

Quality Assessor: Simone Fischer-Hubner, KAU

c© SmartSociety Consortium 2013-2017 3 of 65


List of Contributors

Partner Acronym ContributorUoS Heather PackerUoS Luc Moreau



Executive Summary

The objectives of this deliverable are to show how models of provenance, trust and reputa-

tion 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 sum-

marisation techniques; and transparency and accountability challenges by identifying core

principles, developing a model for transparency and accountability, and providing reputa-

tion 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.



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 34

B HDA-CASs Vocabulary 56



1 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 (HDA-

CAS). Universally, such systems are a composition of various heterogeneous users, hard-

ware 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 ser-

vices 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 do-

main of HDA CASs. It is believed that techniques improving transparency would increase

users’ trust. Provenance data collected from complex systems can be large and overwhelm-

ing 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 account-

ability. 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 vocab-

ulary 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 fol-

lows. 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



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 Sec-

tion 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 analy-

sis, 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 ac-

countability 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:



tracking an application’s actions and decisions; managing feedback about all its com-

ponents; calculating their reputation; and, providing explanations for all aspects of

the system. These accountability functionalities are non-trivial and require substan-

tial 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 prove-

nance data recording interactions with the service and the generation of rep-

utation 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 repu-

tation 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 HDA-

CASs.


http://smartsociety-project.github.io/cas/


3 Integration in the RideShare Demonstrator

The Ride Share demonstrator provides a suitable application for integrating the account-

ability 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 de-

signed 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 Template Name Figure Table

Orchestration post ride request template 1 2composition template 3 4negotiation template 5 6

Reputation submit feedback template 7 8generate reputation template 9 10api call template 11 12

UI change view template 13 14submit request template 15 16

Table 1: Summary table of templates.


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

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

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

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

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

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

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

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


var:b

var:posting_task_request

wasAssociatedWith

prov:type cas:PostingTaskRequesttmpl:endTime var:post_task_endtmpl:startTime var:post_task_start

var:composing_tasks

var:submitting_task_request

wasInformedBy wasAssociatedWith

prov:type cas:ComposingTaskstmpl:endTime var:composing_tasks_endtmpl:startTime var:composing_tasks_start

var:sending_response

wasInformedBywasAssociatedWith

prov:type cas:SendingResponsetmpl:endTime var:sending_response_endtmpl:startTime var:sending_response_start

var:storing_task

var:temp_task_request

usedwasAssociatedWith

prov:type cas:StoringTasktmpl:endTime var:storing_task_endtmpl:startTime var:storing_task_start

wasAssociatedWith

prov:type cas:SubmittingTaskRequestdct:hasPart var:composing_tasksdct:hasPart var:storing_tasktmpl:endTime var:submitting_task_request_endtmpl:startTime var:submitting_task_request_start

var:task_request

wasGeneratedBy

var:orchestration_manager

wasAttributedTo

wasDerivedFrom

prov:type cas:TaskRequestvar:acknowledgement

wasGeneratedBy

prov:type cas:Acknowledgement

wasGeneratedBy

var:ui

wasAttributedTo

prov:type cas:TaskRequest

prov:type cas:CompositionManager

prov:type cas:UserInterfacetmpl:label var:username

Figure 1: Template for posting ride requests. It describes when the orchestration peerreceives a ride request and credentials of the submitter. If the post is authorised thenthe ride request is stored, and it is used to generate ride compositions. Warning: Thegraphical 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 canbe rescaled, which is accessible at post ride request template.

Post Ride Request Template, see Figure 1Variable Type Descriptionvar:ui cas:UserInterface The User Interface.var:orchestration manager cas:OrchestrationManager The orchestration manager.var:temp task request cas:TaskRequest An un-stored task request submitted by

the UI.var:task request cas:TaskRequest A task request.var:storing task cas:StoringTask The activity that stored a task.var:posting task request cas:PostingTaskRequest The activity that posted a task request.var:submitting task request cas:SubmittingTaskRequest The activity that handled the submission

of a task request.var:sending response cas:SendingResponse The activity that sent a response.var:acknowledgement cas:Acknowledgement The acknowledgement that was sent after

the submitting task request activity.var:composing tasks cas:ComposingTasks The activity that generated the valid tasks.

Figure 2: Table describing the variables in for the post ride request template


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

http://smartsociety-project.github.io/cas/#UserInterface

http://smartsociety-project.github.io/cas/#OrchestrationManager

http://smartsociety-project.github.io/cas/#TaskRequest


http://smartsociety-project.github.io/cas/#StoringTask

http://smartsociety-project.github.io/cas/#PostingTaskRequest

http://smartsociety-project.github.io/cas/#SubmittingTaskRequest

http://smartsociety-project.github.io/cas/#SendingResponse

http://smartsociety-project.github.io/cas/#Acknowledgement

http://smartsociety-project.github.io/cas/#ComposingTasks


var:b

var:requesting_opinion

var:generating_composition


prov:type cas:RequestingOpiniontmpl:endTime var:requesting_opinion_endtmpl:startTime var:requesting_opinion_start

var:composing_tasks

wasAssociatedWith

prov:type cas:ComposingTasksdct:hasPart var:authenticatedct:hasPart var:generating_compositiontmpl:endTime var:composing_tasks_endtmpl:startTime var:composing_tasks_start




var:parent_task_request

used

var:task_request

used

var:opinion_report

used wasAssociatedWith

prov:type cas:GeneratingCompositiontmpl:endTime var:generating_composition_endtmpl:startTime var:generating_composition_start

var:task

wasGeneratedBy

wasDerivedFrom

prov:type cas:Task

var:composition_manager

wasAttributedTo

wasDerivedFrom


var:invalid_task

wasGeneratedBy

wasAttributedTo

prov:type cas:Task

var:ui

wasAttributedTo wasAttributedTo


var:acknowledgement

wasGeneratedBy


prov:type cas:ReputationReport


prov:type cas:CompositionManager

Figure 3: Template for generating compositions for ride matches, which describes thegeneration of ride plans.Warning: The graphical version of templates are included inthe deliverable for illustrative purposes only. Given the size of the graph, the readeris expected to use the electronic version, which can be rescaled, which is accessible atcomposition template .

Task Composition Template, see Figure 3Variable Type Descriptionvar:ui cas:UserInterface The User Interface.var:composition manager cas:CompositionManager The composition manager.var:generating composition cas:GeneratingComposition The activity that computes tasks.var:task request cas:TaskRequest A task request.var:task cas:Task A task.var:parent task request cas:TaskRequest A parent task request.var:invalid task cas:Task An invalid task.var:opinion report cas:ReputationReport An opinion report.var:requesting opinion cas:RequestingOpinion The activity that requested an opinion re-

port from the var:reputation manager.var:composing tasks cas:ComposingTasks The activity that computed tasks.var:sending response cas:SendingResponse The activity that sent a response.var:acknowledgement cas:Acknowledgement The acknowledgement that was after a

sending response.

Figure 4: Table describing the variables for the task composition template12 of 65 http://www.smart-society-project.eu

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


http://smartsociety-project.github.io/cas/#CompositionManager

http://smartsociety-project.github.io/cas/#GeneratingComposition


http://smartsociety-project.github.io/cas/#Task



http://smartsociety-project.github.io/cas/#ReputationReport

http://smartsociety-project.github.io/cas/#RequestingOpinion

http://smartsociety-project.github.io/cas/#ComposingTasks




var:b

var:requesting_opinion

var:computing_composition


prov:type cas:RequestingOpiniontmpl:endTime var:requesting_opinion_endtmpl:startTime var:requesting_opinion_start

var:composing_tasks

wasAssociatedWith

prov:type cas:ComposingTasksdct:hasPart var:authenticatedct:hasPart var:computing_compositiontmpl:endTime var:composing_tasks_endtmpl:startTime var:composing_tasks_start




var:parent_task_request

used

var:task_request

used

var:opinion_report

usedwasAssociatedWith

prov:type cas:computingCompositiontmpl:endTime var:computing_composition_endtmpl:startTime var:computing_composition_start

var:task

wasGeneratedBy wasDerivedFromwasDerivedFrom

prov:type cas:Task

var:negotiation_manager

wasAttributedTo


var:invalid_task

wasGeneratedBy

wasAttributedTo

prov:type cas:Task

var:ui

wasAttributedTo wasAttributedTo


var:acknowledgement

wasGeneratedBy


prov:type cas:ReputationReport


prov:type cas:NegotiationManager

Figure 5: Template for computing tasks after a negotiation offer. It describes the genera-tion of ride plans after a user posts a negotiation offer about a ride plan. The generationof 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 purposesonly. 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 5Variable Type Descriptionvar:ui cas:UserInterface The User Interface.var:negotiation manager cas:NegotiationManager The negotiation manager.var:generating composition cas:ComputingComposition The activity that computed valid tasks.var:task request cas:TaskRequest A task request.var:task cas:Task A task.var:parent task request cas:TaskRequest A parent task request.var:invalid task cas:Task An invalid task.var:opinion report cas:ReputationReport An opinion report.var:requesting opinion cas:RequestingOpinion The activity that requests an opinion re-

port from the var:reputation manager.var:negotiating tasks cas:NegotiatingTasks The activity that handles a task submitted

for negotiation.var:sending response cas:SendingResponse An activity that sent a response.var:acknowledgement cas:Acknowledgement The acknowledgement that was after a

sending response.

Figure 6: Table describing the variables for the post negotiation template


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


http://smartsociety-project.github.io/cas/#NegotiationManager

http://smartsociety-project.github.io/cas/#ComputingComposition






http://smartsociety-project.github.io/cas/#RequestingOpinion

http://smartsociety-project.github.io/cas/#NegotiatingTasks




var:b

var:submitting_feedback

var:temp_feedback


prov:type cas:SubmittingFeedbacktmpl:endTime var:submitting_feedback_endtmpl:label cas:SubmittingFeedbacktmpl:startTime var:submitting_feedback_start

var:storing_feedback


prov:type cas:StoringFeedbacktmpl:endTime var:submitting_feedback_endtmpl:label cas:StoringFeedbacktmpl:startTime var:storing_feedback_start

var:feedback

wasGeneratedBy

var:reputation_manager

wasAttributedTo

wasDerivedFrom

prov:type cas:FeedbackReporttmpl:label cas:FeedbackReport

var:ui

wasAttributedTo


prov:type cas:UserInterfacetmpl:label cas:UserInterfacetmpl:label var:username

prov:type cas:ReputationManagertmpl:label cas:ReputationManager

Figure 7: Template for the submission of feedback reports. It describes the processesand entities used when the reputation manager receives a feedback report. The feedbackreport 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 purposesonly. 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 7Variable Type Descriptionvar:ui cas:UserInterface The User Interface.var:reputation manager cas:ReputationManager The reputation manager.var:temp feedback cas:FeedbackReport An un-stored feedback report, to be stored

by the reputation manager.var:feedback cas:FeedbackReport The feedback report, stored by the reputa-

tion manager.var:submitting feedback cas:SubmittingFeedback The activity that handled the submission of

a feedback report.var:storing feedback cas:StoringFeedback The activity that stored a feedback report.

Figure 8: Table describing the variables for the post feedback template


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

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

http://smartsociety-project.github.io/cas/#ReputationManager

http://smartsociety-project.github.io/cas/#FeedbackReport


http://smartsociety-project.github.io/cas/#SubmittingFeedback

http://smartsociety-project.github.io/cas/#StoringFeedback


var:b

var:storing_feedback

prov:type cas:StoringFeedbacktmpl:endTime var:storing_feedback_endtmpl:label cas:StoreFeedbacktmpl:startTime var:storing_feedback_start

var:computing_reputation

wasInformedBy

var:feedback_report


prov:type cas:computingReputationtmpl:endTime var:computing_reputation_endtmpl:label cas:ComputingReputationtmpl:startTime var:computing_reputation_start


var:reputation_report

wasGeneratedBy


wasAttributedTo

wasDerivedFrom

prov:type cas:ReputationReporttmpl:label cas:ReputationReport


Figure 9: Template for generating reputation reports. It describes the generation of rep-utation reports. The generation of reputation reports uses submitted feedback reports togenerate reputation reports. This template is also used when opinion reports are com-puted, because opinion reports are a specialisation of reputation reports. Warning: Thegraphical 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 canbe rescaled, which is accessible at generate reputation template.

Generate Reputation Template, see Figure 9Variable Type Descriptionvar:reputation manager cas:ReputationManager The reputation manager.var:feedback report cas:FeedbackReport The feedback report, used for generating a

reputation report.var:reputation report cas:ReputationReport The reputation report that was computed.var:generating reputation cas:ComputingReputation The activity that computed the reputation

report.var:storing feedback cas:StoringFeedback The activity that stored a feedback report.

Figure 10: Table describing the variables for the generate reputation template


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




http://smartsociety-project.github.io/cas/#ComputingReputation

http://smartsociety-project.github.io/cas/#StoringFeedback


var:b

var:sending_request

var:request


prov:type cas:SendingRequesttmpl:endTime var:sending_request_endtmpl:label cas:SendRequest

var:computing_response


prov:type cas:computingResponsetmpl:endTime var:computing_response_endtmpl:label cas:computingResponsetmpl:startTime var:computing_response_start

var:reputation_record


wasAttributedTo

prov:type cas:Recordtmpl:label cas:Record

var:response

wasGeneratedBy

wasAttributedTo

wasDerivedFrom

prov:type cas:Responsetmpl:label cas:Response

var:ui

wasAttributedTo

prov:type cas:Requesttmpl:label cas:Request

prov:type cas:UserInterfacetmpl:label cas:UserInterfacetmpl:label var:username


Figure 11: Template for generating compositions for ride matches. Bindings for this tem-plate 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 man-ager it retrieves the request information and sends it to the requester. Warning: Thegraphical 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 canbe rescaled, which is accessible at api call template.

Api Call Template, see Figure 11Variable Type Descriptionvar:ui cas:UserInterface The User Interface.var:reputation manager cas:ReputationManager The reputation manager.var:request cas:Request The request that was submitted to the rep-

utation manager.var:response cas:Response The response that was computed by the

reputation manager.var:sending request cas:SendingRequest The activity that submitted the request to

the reputation manager.var:generating response cas:ComputingResponse The activity that computed the response.var:reputation record cas:Record 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


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

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


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

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

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

http://smartsociety-project.github.io/cas/#ComputingResponse

http://smartsociety-project.github.io/cas/#Record


var:b

var:changing_view

wasAssociatedWith

prov:type cas:ChangingViewtmpl:endTime var:changing_view_start_end_timetmpl:startTime var:changing_view_start_time

var:view

wasGeneratedBy

var:ui

wasAttributedTo

prov:type cas:View


Figure 13: Template for changing the view on the UI, bindings for this template aregenerated when the user changes a view. Warning: The graphical version of templates areincluded in the deliverable for illustrative purposes only. Given the size of the graph, thereader is expected to use the electronic version, which can be rescaled, which is accessibleat change view template.

Change View Template, see Figure 13Variable Type Descriptionvar: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


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


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

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


var:b

var:sending_request

var:identity

used

var:view

used

var:request


prov:type cas:SendingRequesttmpl:endTime var:sending_request_end_timetmpl:startTime var:sending_request_start_time

var:ui

wasAttributedTo

prov:type cas:Identity

wasAttributedTo

prov:type cas:View

wasAttributedTo

prov:type cas:Request


Figure 15: Template for the submission of data via the UI. It is used when a user performsan action that results in a request or the submission of data via the UI. Warning: Thegraphical 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 canbe rescaled, which is accessible at submit request template.

Submit Data Template, see Figure 15Variable Type Descriptionui cas:UserInterface The User Interface.identity cas:Identity The identity that was used to submit a re-

quest.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 asso-

ciated with.

Figure 16: Table describing the variables for the submit data template


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


http://smartsociety-project.github.io/cas/#Identity

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

http://smartsociety-project.github.io/cas/#sendingRequest

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


3.2 Vocabulary

In addition to the vocabulary defined for HDA-CAS applications (see Appendix A, Sec-

tion 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 Namespace Descrip-tion

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

The cas vocabulary.

ui file:/tmp/tmpdMwCmX/168.144.152.202/ The UI.openride file:/tmp/tmpdMwCmX/168.144.152.202/

OpenRideServer-RS/The UI’s service.

view file:/tmp/tmpdMwCmX/168.144.152.202/OpenRideServer-RS/view/

The UI’s views.

orchestrator http://168.144.202.152:3000/ The orchestration peer.request http://168.144.202.152:3000/rideRequests/ Ride requests.plans http://168.144.202.152:3000/ridePlans/ Ride plans.

reputation http://pat.ecs.soton.ac.uk/ The reputation man-ager.

feedback http://pat.ecs.soton.ac.uk/application/1/feedback/

Feedback reports.

usr http://pat.ecs.soton.ac.uk/rs/subject/byURI/

The users describedby the reputationmanager.

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.


http://smartsociety-project.github.io/cas/


prov:En

tity

cas:Re

cord

cas:Iden

tity

cas:Re

putationRe

port

cas:Feed

backR

eport

cas:Message

cas:Protocol

cas:Plan

cas:Task

cas:Cap

ability

cas:Acknow

ledgem

ent

cas:Call

cas:Re

quest

cas:Re

sponse

cas:API

cas:View

prov:Agen

t

cas:Re

putationMan

ager

cas:OrchestrationMan

ager

cas:CompositionMan

ager

cas:Pe

er

cas:User

cas:Agen

t

cas:Collective

cas:Neg

otiationMan

ager

cas:UserInterface

cas:IncentiveMan

ager

prov:Activity

cas:Su

bmittingFeed

back

cas:Activitycas:StoringFeed

back

cas:Gen

eratingRe

putation

cas:Authen

ticatingIden

tity

cas:StoringTask

cas:ComposingTasks

cas:Neg

otiatingTasks

cas:Po

stingTaskR

equest

cas:SendingRe

sponse

cas:Gen

eratingComposition

cas:Chan

gingView

cas:Su

bmittingRe

quest

cas:SendingRe

squest

Figure 17: CAS Vocabulary for the Ride Share demonstrator. The yellow nodes denoteprov 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 bluenodes denote terms used by the orchestration peer, the green nodes denote terms that areused by the UI, and the pink nodes with white text are terms that are non specific topeers but are not in the core vocabulary presented in Appendix A, Section 3.



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 reputa-

tion: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 feed-

back 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.



orchestrator:sendingResponse-2

orchestrator:submittingTask-2

wasInform

edBy

wasAssociatedWith

prov:typecas:SendingResponse


orchestrator:submittingTask-1

wasInform

edBy

wasAssociatedWith


ui:OpenRideServer-RS/submittingRequestButton-1

orchestrator:rideRequests/t1

used

orchestrator:identity-1

used

wasAssociatedWith

prov:typecas:SendingTaskRequest

ui:PostingTaskRequest-2

wasAssociatedWith

prov:typecas:PostingTaskRequest


wasAssociatedWith


ui:OpenRideServer-RS/submittingRequestButton-2


used


used

wasAssociatedWith


wasAssociatedWith

prov:type

cas:SubmitingTask

dct:hasPartorchestrator:storingTask-1

wasAssociatedWith

prov:type

cas:SubmitingTask

dct:hasPartorchestrator:composingTasks-1


ui:OpenRideServer-RS/submittingRequestView-2

wasAssociatedWith

prov:typecas:ChangingView

ui:OpenRideServer-RS/submittingRequestView-1

wasAssociatedWith


reputation:generatingResponse-1

opinions:requestingOpinion-1

wasInform

edBy

wasAssociatedWith

prov:typecas:GeneratingResponse

orchestrator:generatingComposition-1

opinions:2

used

orchestrator:ridePlans/0

used

opinions:1

used

orchestrator:rideRequests/2

used

used


used

used

wasAssociatedWith

prov:typecas:GeneratingComposition

wasInform

edBy


used

wasAssociatedWith

wasAssociatedWith

prov:typecas:SendingRequest

orchestrator:storingTask-1

used

wasAssociatedWith

prov:typecas:StoringTask

orchestrator:composingTasks-1

wasInform

edBy

wasAssociatedWith

prov:type

cas:ComposingTasks

dct:hasPartorchestrator:generatingComposition-1


used

wasAssociatedWith


ui:OpenRideServer-RS-2

wasAttributedTo

prov:typecas:Identity

orchestrator:acknowledgement-2

wasG

eneratedBy

prov:typecas:Acknowledgement

orchestrator:rsa

wasAttributedTo


wasG

eneratedBy

reputation:rs

wasAttributedTo

prov:typecas:ReputationReport

wasAttributedTo

wasD

erivedFrom

prov:typecas:Task

wasG

eneratedBy

wasAttributedTo


wasG

eneratedBy

wasAttributedTo

wasAttributedTo

prov:typecas:Task

orchestrator:acknowledgement-1

wasG

eneratedBy


wasG

eneratedBy


wasAttributedTo

wasAttributedTo

prov:typecas:TaskRequest

ui:OpenRideServer-RS/view-1

wasG

eneratedBy

wasAttributedTo

prov:typecas:View


wasG

eneratedBy

wasD

erivedFrom

wasD

erivedFrom

prov:typecas:Task

wasG

eneratedBy

wasAttributedTo


wasG

eneratedBy

wasAttributedTo

wasAttributedTo

wasAttributedTo

wasD

erivedFrom


wasG

eneratedBy

wasAttributedTo

wasAttributedTo

wasAttributedTo

wasD

erivedFrom



wasG

eneratedBy

wasAttributedTo

prov:typecas:View

reputation:response-1

wasG

eneratedBy

wasAttributedTo

wasD

erivedFrom

wasD

erivedFrom

prov:typecas:Response

prov:typecas:ReputationManager

prov:typecas:OrchestratorManager

prov:labelusr:avi

prov:typecas:UserInterface

prov:label'usr:ido'

prov:labelusr:ido


Figure 18: The provenance data recorded from the submission of a ride request. Warn-ing: The graphical version of the provenance traces are included in the deliverable forillustrative purposes only. Given the size of the graph, the reader is expected to use theelectronic version, which can be rescaled, which is accessible at generate rides.22 of 65 http://www.smart-society-project.eu

https://provenance.ecs.soton.ac.uk/store/documents/37470/



orchestrator:subm

ittingTask-2

wasInform

edBy

wasAssociatedW

ith



orchestrator:subm

ittingTask-1

wasInform

edBy

wasAssociatedW

ith


ui:O

penRideServer-RS/subm

ittingRequestButton-1


used


used

wasAssociatedW

ith



wasAssociatedW

ith



wasAssociatedW

ith


ui:O


ittingRequestButton-2


used


used

wasAssociatedW

ith


wasAssociatedW

ith

prov:type

cas:SubmitingTask


wasAssociatedW

ith

prov:type

cas:SubmitingTask

dct:hasPartorchestrator:com

posingTasks-1


ui:O


ittingRequestView-2

wasAssociatedW

ith

prov:typecas:ChangingV

iew

ui:O


ittingRequestView-1

wasAssociatedW

ith


iew

reputation:generatingResponse-1

opinions:requestingO

pinion-1

wasInform

edBy

wasAssociatedW

ith

prov:typecas:GeneratingResponse

orchestrator:generatingC

omposition-1

opinions:2

used


used

opinions:1

used


used

used


used

used

wasAssociatedW

ith

prov:typecas:GeneratingC

omposition

wasInform

edBy


used

wasAssociatedW

ith

wasAssociatedW

ith



used

wasAssociatedW

ith


orchestrator:com

posingTasks-1

wasInform

edBy

wasAssociatedW

ith

prov:type

cas:Com

posingTasks

dct:hasPartorchestrator:generatingC

omposition-1


used

wasAssociatedW

ith


ui:O

penRideServer-RS-2

wasAttributedTo


orchestrator:acknow

ledgem

ent-2

wasGeneratedBy

prov:typecas:Acknowledgem

ent

orchestrator:rsa

wasAttributedTo


wasGeneratedBy

reputation:rs

wasAttributedTo


wasAttributedTo

wasDerivedFrom

prov:typecas:Task

wasGeneratedBy

wasAttributedTo


wasGeneratedBy

wasAttributedTo

wasAttributedTo

prov:typecas:Task

orchestrator:acknow

ledgem

ent-1

wasGeneratedBy


ent

wasGeneratedBy

ui:O

penRideServer-RS-1

wasAttributedTo

wasAttributedTo


ui:O

penRideServer-RS/view-1

wasGeneratedBy

wasAttributedTo

prov:typecas:View


wasGeneratedBy

wasDerivedFrom

wasDerivedFrom

prov:typecas:Task

wasGeneratedBy

wasAttributedTo


wasGeneratedBy

wasAttributedTo

wasAttributedTo

wasAttributedTo

wasDerivedFrom


wasGeneratedBy

wasAttributedTo

wasAttributedTo

wasAttributedTo

wasDerivedFrom


ui:O


wasGeneratedBy

wasAttributedTo

prov:typecas:View

reputation:response-1

wasGeneratedBy

wasAttributedTo

wasDerivedFrom

wasDerivedFrom

prov:typecas:Response

prov:typecas:ReputationM

anager

prov:typecas:OrchestratorManager

prov:labelusr:avi


prov:label'usr:ido'

prov:labelusr:ido


Figure 19: The provenance data recorded from the submission of a ride request withoverlays showing different templates. Where, blue is the change view template, pink is thesubmit request template, orange is the post task template, grey is the composition andgreen is the api call template.



Figure 20: Close up of the provenance graph in Figure 19 showing the change of view andsubmission 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 opinionsvia the reputation manager.



negotiation:sendingResponse-3

negotiation:negotiatingTasks-1

wasInform

edBy

wasAssociatedWith


negotiation:submittingOpinion-2

negotiation:generatingComposition-2

wasInform

edBy

wasAssociatedWith

prov:typecas:SubmittingRequest

negotiation:generatingInvalidTasks-2

wasInform

edBy

negotiation:ridePlans/3

used

wasAssociatedWith

wasAssociatedWith

prov:typecas:GeneratingInvalidTasks

ui:OpenRideServer-RS/view/activeOffersView-1

wasAssociatedWith


negotiation:storingTask-2

wasInform

edBy

negotiation:ridePlans/1a

used

reputation:application/1/opinionOf/1/aboutSubject/24

used


used

negotiation:rideRequests/3

used


used


used

wasAssociatedWith

prov:typecas:GeneratingComposition

wasAssociatedWith

prov:type

cas:NegotiatingTasks

dct:hasPartnegotiation:generatingComposition-2

dct:hasPartnegotiation:generatingInvalidTasks-2

dct:hasPartnegotiation:storingTask-2

ui:OpenRideServer-RS/view/submittingTaskNegotiation-1

negotiation:authenticate-1

used

negotiation:offers/t1

used

wasAssociatedWith


negotiation:composingTasks-2

wasAssociatedWith

prov:type

cas:ComposingTasks

dct:hasPartnegotiation:generatingComposition-2


used

wasAssociatedWith



wasG

eneratedBy

negotiation:rsa

wasAttributedTo

wasD

erivedFrom

prov:typecas:Task


wasAttributedTo

wasD

erivedFrom

wasD

erivedFrom

prov:typecas:Task

wasG

eneratedBy

wasAttributedTo

wasD

erivedFrom

wasD

erivedFrom

wasD

erivedFrom prov:typecas:Task


wasAttributedTo


wasAttributedTo

wasAttributedTo

wasD

erivedFrom

prov:typecas:Task

wasG

eneratedBy

prov:typecas:Task



wasG

eneratedBywasAttributedTo

prov:typecas:View



wasAttributedTo

wasD

erivedFrom

wasD

erivedFrom

prov:typecas:Task

wasAttributedTo

wasAttributedTo


wasAttributedTo


wasAttributedTo


wasAttributedTo prov:typecas:TaskRequest

negotiation:response-3

wasG

eneratedBy


prov:typecas:NegotiationManager

prov:labelusr:avi


prov:labelusr:ido


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 forillustrative purposes only. Given the size of the graph, the reader is expected to use theelectronic version, which can be rescaled, which is accessible negotiation.c© SmartSociety Consortium 2013-2017 25 of 65



negotiation:sendingResponse-3

negotiation:negotiatingTasks-1

wasInform

edBy

wasAssociatedW

ith


negotiation:subm

ittingO

pinion-2

negotiation:generatingC

omposition-2

wasInform

edBy

wasAssociatedW

ith

prov:typecas:SubmittingRequest

negotiation:generatingInvalidTasks-2

wasInform

edBy


used

wasAssociatedW

ithwasAssociatedW

ith

prov:typecas:GeneratingInvalidTasks

ui:O

penRideServer-RS/view/activeOffersView-1

wasAssociatedW

ith


iew

negotiation:storingTask-2

wasInform

edBy

negotiation:ridePlans/1a

used


used


used


used


used


used

wasAssociatedW

ith

prov:typecas:GeneratingC

omposition

wasAssociatedW

ith

prov:type

cas:NegotiatingTasks

dct:hasPartnegotiation:generatingC

omposition-2


dct:hasPartnegotiation:storingTask-2

ui:O

penRideServer-RS/view/subm

ittingTaskN

egotiation-1

negotiation:authenticate-1

used

negotiation:offers/t1

used

wasAssociatedW

ith


negotiation:com

posingTasks-2

wasAssociatedW

ith

prov:type

cas:Com

posingTasks

dct:hasPartnegotiation:generatingC

omposition-2


used

wasAssociatedW

ith



wasGeneratedBy

negotiation:rsa

wasAttributedTo

wasDerivedFrom

prov:typecas:Task


wasAttributedTo

wasDerivedFrom

wasDerivedFrom

prov:typecas:Task

wasGeneratedBy

wasAttributedTo

wasDerivedFrom

wasDerivedFrom

wasDerivedFrom

prov:typecas:Task

ui:O

penRideServer-RS-1

wasAttributedTo


wasAttributedTo

wasAttributedTo

wasDerivedFrom

prov:typecas:Task

wasGeneratedBy

prov:typecas:Task


ui:O


wasGeneratedBywasAttributedTo

prov:typecas:View



wasAttributedTo

wasDerivedFrom

wasDerivedFrom

prov:typecas:Task

wasAttributedTo

wasAttributedTo


wasAttributedTo

ui:O

penRideServer-RS-2

wasAttributedTo


wasAttributedTo prov:typecas:TaskRequest

negotiation:response-3

wasGeneratedBy


ent

prov:typecas:NegotiationM

anager

prov:labelusr:avi


prov:labelusr:ido


Figure 24: The provenance data recorded from the submission of a negotiation offer withoverlays showing different templates. Where, blue is the change view template, pink is thesubmit request template, and red is the api call template.



Figure 25: Close up of the provenance graph in Figure 24 showing submission of a nego-tiation 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 ac-

tivity. 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



reputation:reputation_peer

prov:typecas:ReputationPeer


prov:labelusr:ido

prov:typecas:Peer

ui:OpenRideServer-RS/view/submittingFeedbackButton-1

orchestrator:authenticate-1

used

ui:OpenRideServer-RS/feedback/t1

used

wasAssociatedWith

prov:typecas:SubmitingFeedback

ui:OpenRideServer-RS/view/submittingFeedbackView-1

wasAssociatedWith


reputation:generating_opinion-1

reputation:storing_feedback-1

wasInform

edBy

wasAssociatedWith

prov:typecas:GeneratingReputation

wasInform

edBy

wasAssociatedWith

prov:typecas:StoringFeedback

reputation:generating_reputation-1

wasInform

edBy

wasAssociatedWith


wasAttributedTo

prov:typecas:identity


wasAttributedTo

wasG

eneratedBy

reputation:application/1/opinion/1/

wasAttributedTo

wasG

eneratedBy

wasD

erivedFrom


feedback:0/

wasAttributedTo

wasG

eneratedBy

wasD

erivedFrom

prov:typecas:FeedbackReport

wasAttributedTo prov:typecas:FeedbackReport

reputation:application/1/reputation/1/

wasAttributedTo

wasG

eneratedBy

wasD

erivedFrom


Figure 26: The provenance data recorded from a submitting feedback. Warning: Thegraphical version of provenance traces are included in the deliverable for illustrative pur-poses 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



reputation:reputation_peer

prov:typecas:ReputationPeer

ui:O

penRideServer-RS-1

prov:labelusr:ido

prov:typecas:Peer

ui:O


ittingFeedbackB

utton-1

orchestrator:authenticate-1

used

ui:O

penRideServer-RS/feedback/t1

used

wasAssociatedW

ith

prov:typecas:SubmitingFeedback

ui:O


ittingFeedbackV

iew-1

wasAssociatedW

ith


iew

reputation:generating_opinion-1

reputation:storing_feedback-1

wasInform

edBy

wasAssociatedW

ith


wasInform

edBy

wasAssociatedW

ith

prov:typecas:StoringFeedback

reputation:generating_reputation-1

wasInform

edBy

wasAssociatedW

ith


wasAttributedTo

prov:typecas:identity

ui:O


wasAttributedTo

wasGeneratedBy

reputation:application/1/opinion/1/

wasAttributedTo

wasGeneratedBy

wasDerivedFrom


feedback:0/

wasAttributedTo

wasGeneratedBy

wasDerivedFrom

prov:typecas:FeedbackReport

wasAttributedTo pr

ov:typecas:FeedbackReport

reputation:application/1/reputation/1/

wasAttributedTo

wasGeneratedBy

wasDerivedFrom


Figure 27: The provenance data recorded from a submitting feedback with overlays show-ing different templates. Where, blue is the change view template, pink is the submitrequest template, and red is the submit feedback template, and yellow is the negotiationtemplate.



Reputation Manager

URI Description

/subject/byURI/:subject uri/ A collection resources held by thereputation manager that reference asubject, including of feedback andreputation reports.

/application/:app/subject/:subject/ A collection of subjects associatedwith an application.

/application/:app/subject/:subject/feedback/ A collection of feedback report re-sources associated with a subject re-source.

/application/:app/feedback/ A feedback report to the feedbackreport collection.

/application/:app/feedback/:feedback/ A feedback report resource with aspecific id.

/application/:app/subject/:subject/reputation/ A collection of reputation reportsabout a subject resource.

/application/:app/reputation/:reputation/ A reputation report with a specificid.

/application/:app/opinion/:opinion/ An opinion report with a specific id./application/:app/opinions/ A collection of opinion reports

about subject resources.

Table 3: API calls for the reputation manager

Reputation Manager

URI Description

/application/:app/subject/:subject A narrative resource about a subject with re-spect to an application.

Table 4: API calls for the explanation peer



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 orches-

trator: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. Pre-

dominantly, 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 stud-

ies. 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 re-

turn 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 Southamp-

ton. 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.



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 demon-

strator, 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’, ss-

core: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 rep-

utation 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 sup-

port 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



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.



A Submitted paper: Semantics and Provenance for Ac-countable Smart City Applications


Undefined 1 (2009) 1–5 1IOS Press

Semantics and Provenance for AccountableSmart City ApplicationsEditor(s): Name Surname, University, CountrySolicited review(s): Name Surname, University, CountryOpen review(s): Name Surname, University, Country

Heather S. Packer, a Dimitris Diochnos, b Michael Rovatsos, b Ya’akov Gal, c and Luc Moreau a

a Electronics and Computer Science, University of Southampton, Southampton, SO17 1BJ, UKE-mail: {hp3, L.Moreau}@ecs.soton.ac.ukb School of Informatics, The University of Edinburgh, 33 Buccleuch Place, Edinburgh, EH8 9JS, UKE-mail: {D.Diochnos, mrovatso}@ed.ac.ukc Department of Information Systems Engineering, Ben-Gurion University of the Negev, Be’er Sheva, IsraelE-mail: [email protected]

Abstract. The recent media focus on Smart City services, particularly ride sharing, that provide ordinary users with the abilityto advertise their resources has highlighted society’s need for transparent and accountable systems. Current systems offer littletransparency behind their processes that claim to provide accountability to and for their users. To address such a concern, someapplications 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 theactual execution of the algorithm, the data it operated on, and the parameters it was configured with. Such descriptions abouta 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 provenanceelements. Combined with semantic information, a PROV instance becomes a rich resource, which can be exploited to provideusers with understandable accounts of automated processes, thereby promoting transparency and accountability. Thus, this papercontributes, a vocabulary for Smart City resource sharing applications, an architecture for accountable systems, and a set of usecases 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 ofa city that promotes the use of information and com-munication technologies to engage with citizens to de-velop social capital and intellectual capital, to makebetter use of hard infrastructure, to reduce usage ofenvironmental capital, and to support smart growth.In this context, a class of promising online applica-tions seek to enable citizens to share services in smart

1http://en.wikipedia.org/wiki/Smart_city

cities. This class of applications, which is referred toas smart sharing, are varied and include sharing2 caresharing (Uber, Blablacar, Lyft), bus routes (Chariot),parking space (JustPark), spare rooms (airbnb), andcleaning services (HomeJoy). Smart sharing servicesallow citizens to benefit from customised and finan-cially advantageous offerings, potentially reducing en-vironment impact.

2Uber: www.uber.com/, Blablacar: www.blablacar.com,Lyft: www.lyft.com, Chariot (chariotsf.com), JustPark:www.justpark.com, airbnb: www.airbnb.co.uk, andHomejoy: www.homejoy.com

0000-0000/09/$00.00 c© 2009 – IOS Press and the authors. All rights reserved

2

Smart sharing services are not just online platformssince they mediate access to real people and physi-cal resources.3 It is recognized that smart sharing ser-vices have inherent entry barriers [22], because they“rely on customers and hosts overcoming their fearof strangers.”4 Thus, smart sharing services attemptto belay their users’ fears through a variety of tech-niques, including screening processes, security mea-sures, reputation systems5, and incentive mechanisms.For instance, due to heavy media attention, some rideshare applications have been banned in various loca-tions around the world because they “do not enough toprotect their passengers from unlicensed drivers.”6. Inresponse, they further provided driver screening, insur-ance, feedback and reputation systems7

Two strong characteristics are now commonly sup-ported by smart share services: transparency and useraccountability. Transparency is operating in such away that when a shared resource is offered to a user, itis required that all details of the resource are exposedto its potential consumers so that they can make in-formed decision as to whether to use the resource ornot. By making users accountable for their actions (orthe quality of their resources), it is believed that usersare less likely to make mistakes or take actions thatmay affect the quality of the service. User accountabil-ity is usually a by product of a reputation system andtransparency, which act as an incentive mechanism [3]for users to provide good quality services.

Generally companies offering smart sharing ser-vices rely on automated processes, from matchingusers to services, to “algorithms that identify suspi-cious behavior.”8 Automated processes can seem likea black box to users. Typically, these service-orientedsystems rely on feedback from users, which may beviewed by other users or to compute reputation recom-

3http://www.nytimes.com/2014/10/19/upshot/when-uber-lyft-and-airbnb-meet-the-real-world.html?_r=2&abt=0002&abg=1.

4http://www.bbc.co.uk/news/magazine-21339891

5http://blog.uber.com/uberpopfactsbxl6The 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

7http://blog.uber.com/uberpopfactsbxl,https://www.lyft.com/safety, and http://www.blablacar.com/trust-safety-insurance

8http://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 staticdescription of the algorithm used to compute reputa-tion in order to be transparent. However, this is not suf-ficient to inform users exactly how a reputation mea-sure is derived. Thus, in other words, there is still alack of accountability and transparency about the pro-cesses used by smart share applications: have due pro-cesses been followed, has screening been applied, howare resources matched to consumer’s preferences, howis reputation computed, and how does feedback affectreputation? These issues have been reported in a num-ber of news articles.9

It is important that not just users are held account-able for their action but the systems are too. Thereare two reasons for this: (1) transparent and account-able systems increase a user’s understanding of its pro-cesses, and therefore can increase the user’s trust ofthe system; and (2) accessible accounts enable user’sto feel that their actions can be monitoring, thus incen-tivising them to conduct themselves in a respectablemanner. Weitzner et al. [26] advocate new governanceand frameworks to hold people accountable for themisuse of data, and suggest that provenance [19] canhelp towards this aim. Specifically, provenance [20]is a record that describes the people, institutions, en-tities, and activities involved in producing, influenc-ing, or delivering a piece of data or a thing. PROV [20]is a W3C standard for provenance, which providesa domain-agnostic information about the relationshipbetween provenance elements, which can be a PROV

entity, activity or agent. However, combined with se-mantics, PROV becomes a rich resource which can beexploited to provide users understandable accounts ofautomated processes, promoting transparency and ac-countability of smart sharing services themselves.

Provenance data can be hard for both expert andnon-expert users to understand because of its technicalcontent, and its potential scale and complexity. How-ever, PROV [20] provenance, given its well-defined na-ture, is well suited to construct narratives. The role ofnarratives is to provide an account of connected events,which can be organised in a number of different cat-egories [2]. Textual narratives can be used to improve

9http://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 pro-cesses and their inputs and outputs.

This paper posits that using semantics to enrichPROV D-M [20] to automatically generate sentences us-ing templates, improves PROV’s supports both systemstransparency and accountability. It presents a frame-work for accountability, which is comprised of ser-vices, one of which is a provenance enabled reputationservice, and an explanation service which provides anarrative of a provenance subject. This work is the firstto use provenance, semantics, and narratives, to pro-vide an account of how documents, data, and informa-tion are used, modified, and created by both users andservices. Extant state-of-the-art frameworks tend to fo-cus on logging this information, but do not present itin an easy to understand format to users. Presenting in-formation in an accessible format allows all types ofusers to audit and become aware of their actions withina system. This paper argues that the role of provenanceand its semantic markup is critical in building account-able Smart City applications. Specifically, this papercontributes towards the state-of-the-art:

1. A vocabulary specifically designed to support themarkup of provenance to support accountabil-ity. It describes services, activities, and entitieswithin a Smart City application.

2. A framework that supports accountability as aservice, and includes the following components:(1) The reputation service, a PROV-enabled rep-utation system that uses the Smart City vocab-ulary to markup its provenance; (2) The expla-nation service, which provides a narrative on theprovenance of a give piece of information usingthe terms defined in the Smart City applicationvocabulary.

3. Provenance explanation examples that demon-strate the benefits of using semantics to providean account of provenance.

The remainder of this paper is organised as follows.Section 2 describes the background literature on ac-countable frameworks for distributed services and nar-rative for accountability. Section 3 then presents a vo-cabulary for Smart City applications. Following that,Section 4 describes an accountable framework andhow it uses the vocabulary. Then, Section 5 presentsa ride sharing scenario using the framework and vo-cabularies. Succeeding that, Section 6 details examplesfrom the ride sharing scenario and narrative examples.Finally Section 7 provides conclusions.

2. Background Work

There have been a variety of frameworks proposedto support accountability in online services and sys-tems.Huang et al. [13] present PlanetFlow a networkauditing service designed specifically for PlanetLab,which is a geographically distributed platform de-signed to support the deployment and evaluation ofplanetary-scale network services. It provides perma-nent accountability for all traffic generated by Plan-etLab services, in accordance with common Inter-net practice and terms of the PlanetLab AcceptableUse Policy. Their auditing service collects IP packetswhich are then stored in a database and they furtherprovide an interface for querying the database. Due tothe large scale of PlanetLab they encountered prob-lems, such as filesystem corruption, database corrup-tion, process termination, bugs, and race conditionscaused by system load. This system only logs the flowdata, whereas this paper proposes marking up prove-nance data with additional semantics and presenting anaccount of data elements in a narrative form so it canbe easily digested by end users.

Accountability in distributed systems is proposed byYumerefendi et al. [28] as a general design goal for de-pendable network systems. They present an account-ability framework which preserves digitally signedrecords of actions and internal states of a services.Their framework detects tampering and verifies theconsistency of actions and behaviour, thus proving theresponsibility for actions and states. In contrast, theframework presented in this paper focuses on describ-ing an accessible account to users which may or maynot expose tampering or consistencies of behaviour.Similarly, Chun et al. [5] describes a layered archi-tecture for addressing the end-to-end trust manage-ment and accountability problems in federated sys-tems. They leverage trust relationships for accountabil-ity, along with authentication and anomaly detection,and use third party services for monitoring lower levelsystem resources.

Weitzner et al. [27] present the Policy Aware Webinfrastructure, which supports transparent and ac-countable data for use on the World Wide Web. Theyalso describe elements of a new legal and regulatoryregime aimed to support privacy through provable ac-countability to usage rules, instead of merely enforc-ing data access restrictions. A described example in-frastructure has a proof generator which “constructsproofs that critical transitions and adverse uses of per-sonal information are justified by facts and permissible

4

under applicable rules.” They identify considerationsfor legal rules for accountable systems, including “(1)what degree of transparency rights should those sub-ject to data mining have, (2) what will be the mecha-nism for the correction of data found to be incorrect,and (3) will there be legal recourse in the event agen-cies rely on incorrect information after the error hasbeen pointed out by the subject”. This work highlightsthe need for users to be able to understand which in-formation 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 provenancerecord and authenticate its sources so that it can beused to assign credit or blame. Halpin [12] argues thatprovenance information can be used as the founda-tion for a model of privacy and trust in the context ofthe Semantic Web. Ruth et al. [24] discuss the use ofprovenance in a layered architecture for accountabilityin cloud computing. However, because of the limits ofcloud computing, provenance techniques such as audittrails were not possible because it was not feasible tostore all the versions of the resources referenced in theprovenance records.

Existing work on building accountability into elec-tronic commerce protocols bears some similarity ac-countability in Smart City applications. For example,Crispo et al. and Kailar et al. [7,15] describe frame-works for analysing accountability in communicationprotocols; [6] discusses the delegation of trust withfull accountability for electronic commerce applica-tions. The models presented in this work influence thevocabulary for accountable Smart City applications .Similarly, [23] introduces social computations, whichaligns with the social component of Smart City appli-cations. They introduce an abstract model for socialcomputation, and relevant terms. These models andterms influence the proposed Smart City vocabulary.

Narratives are potentially the most accessible wayto communicate information, they provide an accountof connected events, which can be organised in a num-ber of different categories. Research has shown thatit is how users make sense of their own information[4,16,18], and it is effective to communicate with com-munities and individuals [8,17]. It is well suited to de-scribing provenance data because of the well definedPROV.

Previously, Semantic Web technologies have beenused to generate narratives [25,14,10]. In more detail,Tuffield et al. [25] and Jewell et al. [14] describe theOntoMedia ontology, which supports the generationof narratives. The work presented in [25] discuss ap-

proaches to generate narratives from a vocabulary, theapproaches included are based on character, plot anduser modelling. While, the work presented in [14] de-scribes how OntoMedia is used to annotate the vastcollection of heterogeneous media. The work [10] useontological domain knowledge to select and organise anarrative discourse on an interest topic to a user.

3. Smart City Vocabulary

A vocabulary to describe Smart City actors, activi-ties and entities is required to provide types to prove-nance elements, so that the types can be exploited byother services. The type information allows servicesto apply their own constraints, facilitating the leveragethe information in the provenance.

The class of Smart Share applications envisaged forthe Smart City involve agents, humans or otherwise,having capabilities they wish to offer as a service toother agents, typically humans those having specificrequirements, in terms of baby-sitters, car space, orrides. For instance, the agents have been abstract usingthe notions of peers. Resolving a Smart Share prob-lem involves the use of an orchestrator responsible formatching tasks to peers and scheduling their execu-tion, resulting in the desired allocations of baby-sittersto families, or assignments of car spaces to drivers. Tobecome accountable, a Smart City application needs tobe able to describes how this allocation of tasks andtheir scheduling are achieved, and hence, it requires avocabulary that involves notions of peers, capabilities,tasks.

Services shared via Smart City applications rely onreputation to set them apart from on another. Reputa-tion is created by word of mouth or feedback from con-sumers of the service, and can be viewed by the com-munity of a Smart City application. Reputation canalso be provided by a set of consumers, a collectivewhich represents a groups’ view on a service. To sup-port services in managing feedback and reputation thevocabulary for Smart City provides notions of reputa-tion reports, feedback reports, collectives, and a repu-tation peer.

Concretely, the Smart City vocabulary focuses ondescribing three components: (1) agents within aSmart City application, including users, peers, andcollectives 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/ andit 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 SmartSocietysystem.

– A peer is a software agent in a SmartSociety sys-tem that represents another agent.

– Agents, users, peers all have identities; an unau-thenticated user gets an assigned identity.

– A collective is an agent that consists of multiplemember agents.

– An activity is the condition in which things arehappening or being done.

– A capability is a prospective, though not neces-sarily planned or agreed, activity.

– A task is something that involves capabilities, po-tentially contributed by several agents.

– A plan is a specification for the execution of atask.

– A protocol is a collection of plans that involvecommunications between peers.

– A message is a piece of information exchangedbetween agents.

– A messaging action is the constituent of a proto-col: it involves information exchange and subse-quent action.

– A feedback report is a report about a subject thatcontains a set of value rating categories. For ex-ample, "star rating = 4.3".

– A reputation report is a report about a subjectthat contains a set of value rating categories. Forexample, a subject has been rated with a set ofstar ratings, and the average of those star ratingsare "average star rating = 4.3".

– A reputation peer is a peer that specialises instoring feedback about subjects and generatingreputation about subjects.

4. Accountability as a Service

To make an application accountable, several keypieces of functionality need to be available: trackingapplication’s actions and decisions; providing explana-tions for all aspects of the system; managing feedbackabout all its components; and calculating their repu-tation. Such accountability functionality is non-trivialand requires substantial design and implementation ef-forts. It is therefore critical to make it reusable, so that

it can easily be deployed in multiple Smart City appli-cations.

Therefore, embracing service-oriented architec-tures [9], the concept of accountability as a service isproposed, which consists of exposing accountability-related functionality into a set of well-defined andreusable APIs (Application Programming Interfaces).Such APIs are intended to be application and domain-independent, and they can be deployed in Smart Cityapplication. These APIs can be held peers account-able for their actions; thus, this increases user’s trustand adoption of the system, and it also increase user’sawareness that their actions matter.

The role of the accountability service is to provideaccounts of actions performed by Smart City applica-tion’s peers who are identified, and how entities arecreated, modified and viewed. It is important that or-der to support this, the framework has the followingrequirements:

1. Provide a record of peers, entities, and activi-ties involved in Smart City applications, in par-ticularly pertaining to the generation of auto-mated processes such as reputation generationand matching users to services;

2. Provide a reputation service that manages feed-back and reputation;

3. Provide accessible accounts to users to explainautomated processes.

The framework to support accountability as a ser-vice is designed to support the above requirements, andit is comprised of the components (see Figure 1):

1. ProvStore which is a specialised service for stor-ing provenance. It supports the first require-ment by storing the provenance records detail thepeers, entities and activities in Smart City Appli-cations.

2. A set of peers which submits provenance to Prov-Store detailing who performed which activitiesand where entities are derived from. This compo-nent also supports the first requirement, by pro-viding provenance.

3. The reputation peer which stores feedback re-ports on subjects and computes the reputation re-ports based on feedback reports. It also submitsprovenance to ProvStore. This component sup-ports the second requirement by providing a ser-vice to manage feedback and reputation.

4. The explanation peer uses provenance fromProvStore to generate a textual explanation of a

6

provenance element. This component supportsthe third requirement by generating narrativesabout a provenance subject.

Fig. 1. Layered model of the components in the smart cities account-ability framework.

The provenance submitted to ProvStore is describedusing PROV, which uses the PROV-DM conceptual datamodel. The type of a provenance element is defined us-ing prov:type whose value is from the vocabulary de-fined in Section 3. These types are used by the expla-nation peer to provide more detailed information in thetextual description of a provenance element.

The section is organised as follows, in Sections 4.1,4.2 and 4.3 introduce ProvStore, Reputation Peer andthe Explanation Peer, respectively.

4.1. ProvStore

ProvStore is a specialised service for storing PROV.It also enables users to query provenance and gen-erates visualisations allowing users to analyse prove-nance data. ProvStore’s API10 provides a RESTfulweb service for the storage and access of provenancedocuments in various representations. Via the API,any client can manipulate documents contained in thestore and explore and retrieve information from them.ProvStore stores documents containing provenance de-scriptions. A document can contain bundles whichmay be added via the API. A PROV bundle is mecha-nism by which provenance of provenance can be ex-pressed.

4.2. The Reputation Peer

The reputation peer provides Smart City applica-tions, with a service that manages a subject’s reputa-tion. It stores feedback reports, computes and storesreputation reports. Once the reputation peer receives afeedback report it generates reputation reports. Feed-

10ProvStore’s REST API: https://provenance.ecs.soton.ac.uk/store/help/api/

back reports are comprised of key-value pairs describ-ing attributes about a subject, and meta-informationabout feedback which includes who or what it is about,the authors, and associated events (see Figure 2 for anexample).

{"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 fromall the feedback reports posted to the peer. The cat-egories in which a subject is rated is dependant onthe categories are defined in the feedback value aboutthat subject. The reputation peer calculates the averagevalue of a category given a set of feedback reports (seeFigure 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 supportthe accountability of:

1. Which feedback report was related to whichevent and who;

7

2. Which feedback reports were used to generatereputation and opinion reports;

3. Who accessed feedback, reputation, and opinionreports;

4. The security and privacy policies used to protectuser’s information.

The reputation peer’s resources are exposed via aREST API. Specifically, the API allows the submis-sion of feedback reports about a subject or collectiveof subjects, from an author or collective of authors.

4.3. The Explanation Peer

This peer provides a service that provides a narra-tive about a single provenance element (either an en-tity, activity or agent) in either a provenance documentheld by ProvStore or a set of provenance documentsrelated to a specific application.

It uses sentence templates to explain the provenancedata about a subject. These sentence templates useboth the types defined in: the PROV D-M [21]; and, thesmart cities vocabulary for provenance (see Section 3).If the provenance data is not marked up with the smartcities vocabulary, the peer by default reverts back tousing sentence templates based on the PROV’s types,which are described in Table 1.

The templates P4-P13 in Table 1 use the relation-ship specified in the second column to identify thebindings for the sentence template variables. For ex-ample, if a subject is a prov:activity and has an as-sociation with a agent then the template p5 is used.It exploits the PROV’s Association relationship anduses the activity as the subject and the agent de-fined in this relationship to as variable binding to theP5 template, where wasAssociatedWith(subject, peer-1) is used to create the sentence “It was associatedwith agent/s peer-1” where “It” refers to the subject.Otherwise, it overrides these default sentences usingthe templates in Table 2. These templates differ fromthe those presented in Table 1 because they can usethe semantics in the sentence template to define apath of relationships to connect two provenance el-ements. For example, the explanation peer given thesubject feedback-1 uses the feedback report templatein Table 2. First, it identifies the Smart City typeas a feedback report using the provenance statement(feedback-1, [prov:type=’provsm:feedback report’]).Second, it identifies generation relationships refer-ring to that entity, where wasGeneratedBy(feedback-1, feedback_submission-1, -). Third, it then iden-

tifies which agent was associatedWith the activ-ity, where wasAssociatedWith(feedback_submission-1, peer). This chain of relationships is used toidentify the bindings for the feedback report’s sen-tence template, for example the template The {sub-ject} is a feedback report, the feedback was leftby the {peer/user/collective}. It was submitted usingthe {activity}. has the following bindings subject =feedback-1, {peer/user/collective} =peer, and {activ-ity} = feedback_submission-1. If the provenance doesnot contain the required fields than it reverts back tousing the template in Table 1. The Table 2 does notmake the provenance paths used to bind the variablesexplicit because of conciseness, and instead uses thepossible variable’s types for the bindings.

Specifically, in order to generate a narrative the ex-planation peer:

1. Identifies the template for the subject by usingthe type defined either in the PROV or by a SmartCity type. If it uses the PROV type then it:

(a) Identifies all the provenance elements thatare connected to it by provenance relations.

(b) Identifies the templates for the provenanceelements that connect to the subject usingtheir PROV type.

Or if it uses a Smart City type then:

(a) Identifies all the provenance elements thatare connected to the provenance subject de-scribed in the smart cities sentence templateabout the subject.

(b) Identifies the templates from the Smart Citytemplates to described the connect prove-nance elements.

2. The sentences about the subject and connectedprovenance elements are strung together to forma paragraph.

4.4. APIs Outline

The frameworks adopts a REST approach [1] for ac-countability as a service. Tables 3 summarises the keyresources related to provenance, reputation, and expla-nations, as well as the REST Method allowed on them.

5. Ride Share

Ride Share is an application that enables car sharingfor workplace workers, university students and simi-

8

Number Prov Types Sentence templateP1 Entity The {subject} is a {provtype}P2 Agent The {subject} is a {provtype}P3 Activity The {subject} is a {provtype}

Prov Relations Sentence templateP4 Alternate It was an alternate of {alternate/s}P5 Association It was associated with agent/s {agent/s}P6 Attribution It was attributed to agent/s {agent/s}P7 Collections It was a member of the {collection/s} collection/sP8 Communication It was informed by {agent/s}P9 Delegation It acted on behalf of {agent/s}P10 Derivation The {subject} was derived from the entity/ies {entity/ies}P11 Specialisation and Revision The {subject} was a specialisation of the entity {entity}, and is a revi-

sion of {entity/ies}P12 Generation It was generated by the activity {activity/ies}P13 Usage It was used by the activity/ies {activity/ies}

Table 1

PROV Template Sentences, where items in {} are variables whichcan be either a single item or a list.

lar large community members living in and around theSmart City. For example, at Ben-Gurion University,there are thousands of students coming from all overthe country which has created a vivid car sharing com-munity based on actual and acute travel needs. The ap-plication allows both drivers and commuters to offerand request rides. These offers and ride requests in-clude details about required travels, timing, locations,capacity, prices, and other details relevant for car shar-ing. It performs automatic matching of commuters toavailable cars, by considering origin and destination,routes, capacity and other available information. In-centives are used to influence participant behavioursand maximise the global system goals.

Ride Share has been chosen because it uses auto-mated algorithms for matching users in rides and gen-erating reputation reports. The execution of these au-tomated algorithms is documented using provenance,which is marked up with the smart cities vocabulary;provenance is exposed to users via the explanationpeer. Without recorded provenance, smart cities vocab-ulary, and explanation peer, these automated processwould be a black box to users.

The architecture of Ride Share is based on five corecomponents (see Figure 4): a view, ride matching peer,reputation peer, and ProvStore, organised according tothe layered architecture of Figure 1. The view providesthe user with the graphical components with which toenter their ride requests, and to view and select poten-tial rides. The matching peer provides matches con-

taining drivers and commuters, which the users can se-lect. The reputation peer and ProvStore are describedin Section 4.

Fig. 4. Layered Model of Ride Share

5.1. Feedback and Reputation Reports

Feedback reports can be submitted by both ridersand drivers after a ride has been completed. Table 4describes the feedback categories supported by RideShare, in feedback reports.

A reputation report is a rating of a user structuredaccording to reputation categories; such reputation cat-egories are defined from the categories comprised infeedback reports submitted about the user. Each rep-utation category value is calculated by a simple func-tion, averaging the values associated with the corre-sponding feedback category in feedback reports aboutthe 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 thecapabilities {capabilities}. It performed the following activities {activi-ties}.

user prov:Agent The {subject} is a human user that uses the Smart City framework. Ithas the capabilities {capabilities}. It is identified by {identities}, whichis 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 hasthe capabilities {capabilities}. It is identified by {identities}, which ismaintained by the framework. It is the member of the collective/s {col-lectives}. It performed the following activities {activities}.

identities prov:Agent The {subject} is the identify for the {agent/user/peer} and is main-tained 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, thathas the capabilities {capabilities}. It performed the following activities{activities}.

activity prov:Activity The {subject} is an activity performed by the{agent/user/peer/collective}.

capability prov:Entity The {subject} is a capability, specifically in this context it describes thecapability of the {agent/user/peer/collective}.

task prov:Entity The {subject} is a task, it describes the capabilities {capabilities} pos-sibly involving the following agents {agents/users/peers/collectives}.

plan prov:Entity The {subject} is a plan, it describes the a task that has thecapabilities {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 capabil-ities {capabilities} which involves communication between the follow-ing peers {peers}.

message prov:Entity The {subject} is a message that describes the a task that has the capa-bilities {capabilities} which involves communication between the fol-lowing peers {peers}.

messaging action prov:Activity The {subject} is an activity that sends the message {message} betweenthe following peers {peers}. The peer {peer} was responsible for send-ing 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}. Itwas submitted using the {activity}.

reputation report prov:Entity The {subject} is a reputation report, it was derived from the feedbackreports {feedback reports}. It was generated by the {activity} and wasleft by the {peer/user/collective}.

Table 2Template Sentences, where items in {} are variables which can be either a single item or a list.

10

Reputation Peer

REST Method URI DescriptionGET /subject/byURI/:subject_uri Retrieves feedback and reputation reports associated

with a subject.GET /application/:app/subject/:subject/ Retrieves the set of subjects associated with an appli-

cation.GET /application/:app/subject/:subject/feedback/ This calls returns all feedback id’s about a subject.

POST /application/:app/feedback/ Save a feedback report.GET /application/:app/feedback/:feedback/ Retrieves a feedback report with a specific id.GET /application/:app/subject/:subject/reputation/ Retrieves the set of reputation reports about a subject.GET /application/:app/reputation/:reputation/ Retrieves a reputation report with a specific id.

POST /application/:app/opinions/ Retrieves the set of opinion reports about subjects.

Explanation Peer

GET /application/:app/subject/:subject Retrieve a narrative about a subject.

Provenance Store

GET /store/api/v0/documents/ Retrieve a list of documents visible to the authenti-cated user or public.

POST /store/api/v0/documents/ Save a new document.

Table 3API calls for the reputation, explanation and provenance peers

Category Subcategory Description

Overall Star Rating - A five star rating for the ride

Ride Price A five star rating for the price of the rideRoute A five star rating for the route of the rideTimeliness A five star rating indicating whether the commuter was ready on

time

Individual Reliability A five star rating indicating the reliability of the commuter.Communication A five star rating indicating the communication during the ride.Friendliness A five star rating indicating the commuter’s friendliness.

Table 4Categories and Descriptions for User Feedback.

work is to explain to users how their ratings are com-puted; over time, there will be an investigate into morecomplex functions to compute reputation category val-ues.

5.2. Ride Share Vocabulary

In addition to the vocabulary defined for Smart Cityapplications, the following subtypes for Ride Shareare used and the hierarchy of the model is shownin Table 6. This vocabulary focuses on describingthe activities in Ride Share. Providing precise typingabout these different activities then enables the expla-nation peer to provide individualised descriptions ofRide Share activities. The namespace used for the vo-cabulary 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 reputa-

tion peer to store a feedback report within it.6. ride_request is a task that describes a ride re-

quest and contains information about a proposedride including, date and time, origin and destina-tion, and the role of the user submitting the task.

7. A reputation_item is a JSON object that is re-turned from a GET request to the reputation peer.

8. authenticating_activity is an activity which au-thenticates a user.

11

Category Subcategory Formula

Average Overall Star Rating - average(overall_star_rating)

Ride Average Price average(price)

Average Route average(route)

Average Timeliness average(timeliness)

Individual Average Reliability average(reliability)

Average Communication average(communication)

Average Friendliness average(friendliness)

Table 5Reputation categories and formula for summary driver and commuter reports

9. storing_task is an activity that stores a task lo-cally.

10. computing_composition is an activity that com-putes a set of valid tasks given constraints or ne-gotiation inputs.

11. computing_task_complement is an activity thatidentifies which set of tasks that are no longervalid.

12. sending_request is an activity that sends a re-quest to peer.

13. sending_negotiation_response is an entity thatcontains the response to a negotiation activity.

14. posting_task_request is an activity that posts atask to orchestration peer.

15. changing_view is an activity that changes theview in a UI.

16. composing_activity is an activity that may becomprised of the following activities authenti-cate, compute_composition and compute_task_complement.

17. negotiating_activity is an activity which sub-mits a task that may be used to modify anothertask, it may comprise of an authenticate and stor-ing_task activities.

18. submitting_activity is an activity which submitsa task, it may comprise of an authenticate andstoring_task activities.

19. computing_reputation is an activity that is runby the reputation peer when a feedback report issubmit, it computes a reputation report for all thesubjects referred to by the submitted feedback re-port.

5.3. Sentence Templates for Ride Share

The Ride Share vocabulary enables the explanationpeer to tailor the sentences it generates, with descrip-tions of the specific activities in Ride Share. Table

Prov type SmartCitytype

Ride Share type

prov:Entity entity ride_feedback_reportprov:Activity activity submitting_feedbackprov:Activity activity storing_feedbackprov:Activity activity computing_reputationprov:Activity activity composing_activityprov:Activity activity authenticating_activityprov:Activity activity storing_taskprov:Activity activity computing_task_complementprov:Activity activity submitting_activityprov:Activity activity sending_negotiation_responseprov:Activity activity negotiating_activityprov:Activity activity posting_task_requestprov:Activity activity sending_requestprov:Activity activity changing_viewprov:Entity plan ride_plan

Table 6The hierarchy of the Ride Share vocabulary.

7 details the sentence templates exploiting the RideShare vocabulary, similar to Table 2 it does not makethe provenance paths used to bind the variables explicitbecause of conciseness, and instead uses the possiblevariable’s types for the bindings.

The explanation peer is used to explain the prove-nance data stored by Ride Share to its users. Specifi-cally, it can describe:

1. The generation of reputation and opinions re-ports;

2. The generation of ride plans;3. The negotiation process among users for select-

ing ride plans.

12

Id Ride Share type SentencesRS1 reputation_report The {subject} is a reputation report. It was generated by the {comput-

ing_reputation} activity and by the {peer}.RS2 submitting_feedback The submit feedback activity {subject} was performed by the {peer}. This

activity submitted the feedback {ride_feedback_report} to the {reputa-tion_peer}.

RS3 storing_feedback 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.

RS4 computing_reputation The compute reputation activity {subject} was performed by {reputa-tion_peer}.This activity generated the reputation report {reputation_report}for the {user}, and was derived from the following feedback reports {feed-back_reports}, it averaged the ratings for each of the categories in the feed-back reports.

RS5 composing_activity The composition activity {subject} was performed by {peer}. Thecomposition activity is comprised of the following activities {com-puting_composition}, {computing_task_complement} and {send-ing_response}, it triggered the activity {sending_response}.

RS6 authenticating_activity The authenticate activity {subject} was performed by {peer}, uses the{peer}’s identity to authenticate it.

RS7 storing_task The store task activity {subject} was performed by {peer}, and it stored thetask {task} in its store.

RS8 computing_composition The compute composition activity {subject} was performed by {peer}, itgenerates potential ride matches between current ride requests and matcheson a requests origin, destination and time. The following ride requests{tasks} were matched using this activity.

RS9 computing_task_complement The compute task complement activity {subject} was performed by {peer},it generates the complement set to potential ride matches and contains rideplans that are no longer valid or that weren’t feasible based on ride request’sorigin, destination and time. The following rides were classified as comple-mentary {task}.

RS10 submitting_activity The submit activity {subject} was performed by {peer}, it is a com-position of activities that include {authenticating_activity}, a {comput-ing_composition} and {storing_task}, it triggered the activity {send-ing_response}.

RS11 sending_negotiation_response The sending negotiation response {subject} activity was performed by{peer} and it sent the {task}.

RS12 negotiating_activity The negotiation activity {subject} was performed by {peer}. The negotiationactivity is comprised of the following activities {authenticating_activity},{computing_composition}, {storing_task}, it triggered the activity {send-ing_response}.

RS13 posting_task_request The post task request activity {subject} was performed by {peer}.RS14 sending_request The send request request activity {subject} was performed by {peer}, by a

user with the identity {identity} via the {peer}.RS15 changing_view The change view activity {subject} was performed by {peer}, by a user with

the identity {identity} via the {peer}.RS16 ride_plan The ride plan {subject} was generated by the {computing_composition} ac-

tivity. It details the attributes of a ride including its date and time, the originand destination, and its potential participants and their roles. It was derivedfrom the ride requests {ride_requests}. It was generated by the {activity}.

RS17 ride_request The ride request {subject} was submitted by {user} and it was generated by{sending_request}. It includes information about a requested rides date andtime, the origin and destination, and the role played by the {user}.

RS18 sending_response The sending response task {subject} sends an acknowledgement to the{peer} to say that the {activity} has completed.

RS19 feedback_report 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 variableswhich can be either a single item or a list.

13

6. Ride Share Accountability Use Cases

This section expands on the three use cases identi-fied in Section 5.3 by providing examples of relevantprovenance collected from the different peers withinRide Share. For each use case, the explanation peer togenerate two narratives: the first narrative exploits thesemantics provided by the Smart City/Smart Share vo-cabularies, whereas the second narrative simply relieson the domain-agnostic types and relations providedby PROV. Presenting these two narratives demonstratesthe benefits of decorating provenance with application-specific semantics.

6.1. Accountability for Ride Plans

Ride Share generates ride plans when the ridematching peer receives a ride request. The prove-nance recorded for such ride plans includes descrip-tions about: which views the user viewed; the submis-sion of the ride request via the UI; the ride matchingpeer storing and generating ride plans; and the requestthat the ride matching peer sends the reputation peerfor opinion reports. An example of the provenance datacollected can be seen in Figure 5.

This use case is required to provide systems ac-countability for the generation of ride plans, thereforethe ride plan rideplan:1 is used as the subject. The fol-lowing narrative was generating using the semanticsdefined by the Smart City and Ride Share vocabular-ies:

Ride Share Narrative: The ride plan rideplan:1was generated by the rideshareapp:composition-1activity. It details the attributes of a ride includingits date and time, the origin and destination, andits potential participants and their roles. It was de-rived from the ride requests with the ids 1 and 2.The ride request riderequest:1 was submitted byusr:ido. It includes information about a requestedrides date and time, the origin and destination,and the role played by the usr:ido. The ride re-quest riderequest:2 was submitted by usr:avi andit was generated by view:submitRequestButton.It includes information about a requested ridesdate and time, the origin and destination, and therole played by the usr:avi and it was generatedby view:submitRequestButton. The compute com-position activity rideshareapp:composition-1 wasperformed by rideshareapp:rsa, it generates po-tential ride matches between current ride requests

and matches on a requests origin, destination andtime. The following ride requests with the ids 1 and2 were matched using this activity.

In contrast, the following narrative was generatedabout the same subject (rideplan:1) using sentencetemplates relying on the PROV semantics but ignoringthe Ride Share types.

PROV Narrative: The rideplans:1 is a prov:Entity.Entity rideplans:1 was derived from riderequestwith the ids 1 and 2. It was associated withagent/s rideshareapp: rsa. It was generated bythe activity rideshareapp:composition-1. The rid-erequest:1 is a prov:Entity. It was associated withagent/s rideshareapp:rsa. It was generated bythe activity view:submitRequestButton. The rid-erequest:2 is a PROV:entity. It was associated withagent/s rideshareapp:rsa. It was generated by theactivity view:submitRequestButton.

In order to compare the two narratives, the sentencesabout the same provenance elements and relationshipsfrom both narratives are presented side by side (seeTable 8). The table shows that the Ride Share Nar-rative provides additional information about activitiesin the form of summary description (see RS8 in Ta-ble 8). In contrast, the PROV Narrative was unable toprovide this information, because this information notavailable via the provenance: the provenance only ex-poses who performed an active and any inputs or out-puts. The narratives also differ when describing whois associated with the generating ride requests. TheRide Share Narrative describes the user submitting arequest via an agent (see RS17 in Table 8). In contrast,the PROV Narrative only details the agent (see P5 inTable 8), because it could exploit more data from theprovenance because of the specialised sentence tem-plates. In general, the sentences in PROV Narrativelack clarity about the relationships and roles of theprovenance elements, while the Ride Share Narrativewas able to provide it because of the additional seman-tics in the Ride Share vocabulary.

6.2. Accountability for Negotiation Processes

The negotiation process among users for selectingride plans requires a potential user agreeing to a partic-ular ride plan. The provenance recorded during a ne-gotiation includes descriptions about: which views theuser viewed; the submission of the negotiation offervia the UI; the ride matching peer using the offer to

14

Fig. 5. The provenance data recorded from the submission of a ride request (for more detailshttps://provenance.ecs.soton.ac.uk/store/documents/33414/).

15

Fig. 6. The provenance data recorded from the submission of a negotiation offer (for more detailshttps://provenance.ecs.soton.ac.uk/store/documents/33415/)

16

Table 7 Id Sentence Table 1 Id Sentence

RS16 The ride plan rideplan:1 was generated bythe rideshareapp:composition-1 activity.

P1, P6 The rideplans:1 is a prov:Entity. It was at-tributed to rideshareapp:composition-1.

RS16 It details the attributes of a ride including itsdate and time, the origin and destination, andits potential participants and their roles.

- -

RS16 It was derived from the ride requests with theids 1 and 2.

P10 Entity rideplans:1 was derived from rid-erequest with the ids 1 and 2.

RS17 The ride request riderequest:1 was submit-ted by usr:ido and it was generated by theview:submitRequestButton.

P1, P5, P12 The riderequest:1 is a prov:Entity. It wasassociated with agent/s rideshareapp:rsa.It was generated by the activityview:submitRequestButton

RS17 It includes information about a requestedrides date and time, the origin and destina-tion, and the role played by the usr:ido.

- -

RS17 The ride request riderequest:2 was submit-ted by usr:avi and it was generated byview:submitRequestButton.

P1, P5, P16 The riderequest:2 is a prov:Entity.It was associated with agent/srideshareapp:rsa. It was attributed toview:submitRequestButton.

RS17 It includes information about a requestedrides date and time, the origin and destina-tion, and the role played by the usr:avi.

- -

RS8 The compute composition activityrideshareapp:composition-1 was performedby rideshareapp:rsa, it generates potentialride matches between current ride requestsand matches on a requests origin, destinationand time. The following ride requests withthe ids 1 and 2 were matched using thisactivity.

- -

Table 8Comparison Table for Ride Plans Narratives

generate valid and invalid ride plans. An example ofthe provenance data can be seen in Figure 6.

This use case is required to provide systems ac-countability about how Ride Share handles negotia-tions and how it uses the negotiation to generate validand invalid ride plans. Therefore, an explanation ofthe negotiation rideshareapp:negotiation-1 is used asthe explanation subject. The generated sentences arepresent in Table 9, sentences about the same prove-nance elements and relationships from both narrativesare presented side by side. As in the previous use casethe table shows that the Ride Share Narrative pro-vides more detailed information about activities thanthe PROV Narrative. With the addition of the smartshare vocabulary the Ride Share Narrative was awarethat the negotiation was a composed of a set of activ-ities, whereas the PROV Narrative could not leveragethe provenance for this information because it is notexpressed using PROV. Therefore the Ride Share Nar-rative could describe the set of activities that the PROVNarrative could not.

6.3. Accountability for Reputation Reports

Ride Share generates reputation and opinion reportswhen the reputation peer receives a feedback report.The provenance recorded for the submission of feed-back includes descriptions about: which views the userviewed; the submission of the feedback report via theUI; the reputation peer storing and generating repu-tation and opinion reports. An example of the prove-nance data can be seen in Figure 7.

The generated sentences are present in Table 10,sentences about the same provenance elements and re-lationships from both narratives are presented side byside. As in the previous two use cases the table showsthat the Ride Share Narrative provides more detailedinformation about activities than the PROV Narrative.

6.4. Analysis

The aim of the analysis is to contrast Ride ShareNarratives and PROV Narratives, by identifying dis-

17


RS12 The negotiation activityrideshareapp:negotiation-1 was performedby rideshareapp:rsa.

P3, P5, P8 The rideshareapp:negotiation-1is a prov:Activity. It was associ-ated with agent/s rideshareapp:rsa.rideshareapp:negotiation-1 was informedby rideshareapp:sendResponse-2.

- - P2 The rideshareapp:rsa is a prov:Agent.

RS18 The sending response taskrideshareapp:sendResponse-2sends an acknowledgement to therideserver:OpenRideServer-RS/ to saythat the rideshareapp:negotiation-1 hascompleted.

P3, P5, P12, P8 The rideshareapp:sendResponse-2 is a prov:Activity. It was associ-ated with agent/s rideshareapp:rsa.rideshareapp:200 was generated by theactivity rideshareapp:sendResponse-2.rideshareapp:sendResponse-2 was in-formed by rideshareapp:negotiation-1.

RS12 The negotiation activity is com-prised of the following activi-ties rideshareapp:authentication-2,rideshareapp:generateComposition-2,rideshareapp:generateTaskComplement-2,and rideshareapp:storeTask-1.

- -

R6 The authenticate activityrideshareapp:authentication-2 was per-formed by rideshareapp:rsa, uses theusr:ido’s identity to authenticate it.

- -

RS8 The compute composition activityrideshareapp:generateComposition-2 wasperformed by rideshareapp:rsa, it generatespotential ride matches between current riderequests and matches on a requests origin,destination and time. The following riderequests riderequest:1 were matched usingthis activity.

- -

RS9 The compute task complement activityrideshareapp:generateTaskComplement-2was performed by rideshareapp:rsa, itgenerates the complement set to potentialride matches and contains ride plans that areno longer valid or that weren’t feasible basedon ride request’s origin, destination andtime. The following rides were classified ascomplementary ride plan:1 and ride plan:2.

- -

RS7 The store task activityrideshareapp:storeTask-1 was performedby rideshareapp:rsa, and it stored the taskrideshareapp:offeres/t1 in its store.

- -

Table 9Comparison 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


RS1 The ride_manager:application/1/reputation/1/is a reputation report, it was derived fromthe feedback reports with ids 0, it averagedthe ratings for each of the categories in thefeedback reports.

P1, P10 The ride_manager:application/1/reputation/1/is a prov:Entity. It was derived fromfeedback with the ids 0.

RS1 It was generated by theride_manager:generate_reputation-1activity and was left by usr:ido.

P5, P12 It was associated with agent/srideshareapp: rsa. It wasgenerated by the activityride_manager:generate_reputation-1.

RS4 The compute reputation ac-tivity was performed byride_manager:reputation_peer.This ac-tivity generated the reputation reportride_manager:application/1/reputation/1/,and was derived from the feedback reportswith ids 1 and 2.

- -

RS19 The feedback reportride_manager:application/1/feedback/0/was generated by theride_manager:storing_feedback-1 activity.It contains the reputation left by usr:ido

P1, P5 and P12 The feedback:0 is a prov:Entity. It wasassociated with agent/s rideshareapp:rsa.It was generated by the activityview:submitFeedbackButton.

Table 10Comparison Table for Reputation Reports

number of number of number ofuse case generic sentences specialised sentences resources exploited1: Ride Share Narrative 0 9 91: PROV Narrative 8 0 6

2: Ride Share Narrative 0 10 132: PROV Narrative 7 0 4

3: ride share narrative 0 6 73: PROV narrative 7 0 3

Table 11Summary statistics for the use case narratives

criminating characteristics of these narratives. To thisend, sentences are categorised as either generic orspecialised. Generic sentences are generated by mak-ing use of PROV concepts only, as per Table 1,whereas specialised sentences are those constructedwith knowledge of Ride Share types, as per Table 7.Furthermore, given that the sentence template vari-ables are placeholders for resources to be extractedfrom the provenance, and quantify the number of re-sources that each narrative exposes.

Table 11 shows that the explanation successfullyuses the Smart City vocabulary and that the vocabu-lary has good coverage of the terms used in the prove-nance for Ride Share. Specifically, the Ride Share nar-ratives all use specialised sentences, whereas the PROVnarratives use generic sentences. Also because of the

specialised semantics for the Ride Share application,the explanation peer was able to expose more of theresources that were relevant to the provenance subject.In more detail, the explanation peer could not identifyall the activities that were related to composite activi-ties in the second use case. Therefore, the Ride Sharenarrative exposed nine more resources than the PROV

narrative. In the third use case, the PROV narrativesuses more sentences to describe fewer resources, thanthe Ride Share narrative. This is because the sentencetemplates leveraged by the semantics in the Smart Cityvocabulary explicitly define associations between theprovenance elements and therefore can explain moreresources in fewer sentences.

20

7. Conclusion

The paper presents a vocabulary for Smart Cityapplications that supports an accountable framework.The framework uses provenance to provide an ac-count about how documents, data, and information ina Smart City application are used, modified, and cre-ated by both users and peers. The role of provenanceand its semantic markup is critical to build accountableSmart City applications. The framework also providesusers with narratives generated to support the trans-parency of automated processes. Specifically, this pa-per contributes to the state-of-the-art: A Smart City vo-cabulary specifically designed to support the markupof provenance to support accountability. The vocabu-lary is designed to support a board class of applica-tions, however, it is beneficial to expand these terms toinclude information about how specific types of activ-ities function; A framework that supports transparencyand accountability using PROV, including the:

1. The reputation peer, a provenance enable reputa-tion system that uses the Smart City vocabulary;

2. The explanation peer, which provides a narrativeabout a specified provenance element using theterms defined in the Smart City application vo-cabulary.

; and, provenance explanation examples that demon-strate the benefits of using semantics to provide an ac-count of provenance. The uses case discussed in Sec-tion 6 show that the explanation generated based onthe Smart City vocabulary were able to exploit moredata from the provenance, and could provide more spe-cialised sentences describing a provenance subject.

This work will be extended in four ways, it will :Firth, investigate how provenance data and the SmartCity vocabulary can be extended or used to generatenarratives for collectives, and how a narrative can becondensed while identifying commonalities and out-liers in collectives. Second, support privacy by usingprovenance data that has been transformed to obfus-cate and remove concepts that refer to sensitive in-formation or are private because of privacy policies.Third, evaluate the explanation service’s narrative viaa user study to validate how effect narrative to supportdecision making processes. Fourth, extend the jsonused in the serialisations so that they support json-DL.

8. Acknowledgments

The research leading to these results has receivedpartially funding from the European Community’sSeventh Framework Program (FP7/2007-2013) un-der grant agreement n. 600854 Smart Society: hy-brid and diversity-aware collective adaptive systems:where people meet machines to build smarter societieshttp://www.smart-society-project.eu/.

References

[1] Subbu Allamaraju. RESTful Web Services Cookbook. O’Reilly,2010.

[2] Ruth A Berman and Dan Isaac Slobin. Relating events innarrative: A crosslinguistic developmental study. PsychologyPress, 2013.

[3] Alessandro Bogliolo, Paolo Polidori, Alessandro Aldini,Waldir Moreira, Paulo Mendes, Mursel Yildiz, C Ballester, andJ Seigneur. Virtual currency and reputation-based cooperationincentives in user-centric networks. In Wireless Communica-tions and Mobile Computing Conference (IWCMC), 2012 8thInternational, pages 895–900. IEEE, 2012.

[4] Andrew D Brown, Michael Humphreys, and Paul M Gur-ney. Narrative, identity and change: a case study of laska-rina holidays. Journal of organizational change management,18(4):312–326, 2005.

[5] Brent N Chun and Andy Bavier. Decentralized trust manage-ment and accountability in federated systems. In System Sci-ences, 2004. Proceedings of the 37th Annual Hawaii Interna-tional Conference on, pages 9–pp. IEEE, 2004.

[6] Bruno Crispo. Delegation protocols for electronic commerce.In Computers and Communications, 2001. Proceedings. SixthIEEE Symposium on, pages 674–679. IEEE, 2001.

[7] Bruno Crispo and Giancarlo Ruffo. Reasoning about account-ability within delegation. In Information and CommunicationsSecurity, pages 251–260. Springer, 2001.

[8] Olivier Ferret. How to thematically segment texts by using lex-ical cohesion? In Proceedings of the 36th Annual Meeting ofthe Association for Computational Linguistics and 17th Inter-national Conference on Computational Linguistics-Volume 2,pages 1481–1483. Association for Computational Linguistics,1998.

[9] Roy Thomas Fielding. Architectural Styles and the Design ofNetwork-based Software Architectures. PhD thesis, Universityof California, Irvine, 2000.

[10] Joost Geurts, Stefano Bocconi, Jacco Van Ossenbruggen, andLynda Hardman. Towards ontology-driven discourse: From se-mantic graphs to multimedia presentations. Springer, 2003.

[11] Paul Groth, Yolanda Gil, James Cheney, and Simon Miles. Re-quirements for provenance on the web. International Journalof Digital Curation, 7(1):39–56, 2012.

[12] Harry Halpin. Provenance: The missing component of the se-mantic web for privacy and trust. In Trust and Privacy on theSocial and Semantic Web (SPOT2009), workshop of ESWC,2009.

21

[13] Mark Huang, Andy Bavier, and Larry Peterson. Planet-flow: maintaining accountability for network services. ACMSIGOPS 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 forthe representation of heterogeneous media. In Multimedia In-formation Retrieval Workshop (MMIR 2005) SIGIR. ACM SI-GIR, 2005. Event Dates: 08/05.

[15] Rajashekar Kailar. Reasoning about accountability in protocolsfor electronic commerce. In Security and Privacy, 1995. Pro-ceedings., 1995 IEEE Symposium on, pages 236–250. IEEE,1995.

[16] Allan Kuchinsky, Celine Pering, Michael L Creech, DennisFreeze, Bill Serra, and Jacek Gwizdka. Fotofile: a consumermultimedia organization and retrieval system. In Proceedingsof the SIGCHI conference on Human Factors in ComputingSystems, pages 496–503. ACM, 1999.

[17] Claude Lévi-Strauss. Structural anthropology. Basic Books,2008.

[18] Yutaka Matsuo and Mitsuru Ishizuka. Keyword extractionfrom a single document using word co-occurrence statisticalinformation. International Journal on Artificial IntelligenceTools, 13(01):157–169, 2004.

[19] Luc Moreau and Paul Groth. Provenance: An introduction toprov. Synthesis Lectures on the Semantic Web: Theory andTechnology, 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, RezaB’Far, James Cheney, Sam Coppens, Stephen Cresswell,Yolanda Gil, Paul Groth, Graham Klyne, Timothy Lebo, Jim

McCusker, Simon Miles, James Myers, Satya Sahoo, and CurtTilmes. PROV-DM: The PROV Data Model. W3C Recom-mendation REC-prov-dm-20130430, World Wide Web Con-sortium, October 2013.

[22] Helen L Partridge. Developing a human perspective to the dig-ital divide in the’smart city’. 2004.

[23] Michael Rovatsos. Multiagent systems for social computation.In Proceedings of the 2014 international conference on Au-tonomous agents and multi-agent systems, pages 1165–1168.International Foundation for Autonomous Agents and Multia-gent Systems, 2014.

[24] Paul Ruth, Dongyan Xu, Bharat Bhargava, and Fred Reg-nier. E-notebook middleware for accountability and reputationbased trust in distributed data sharing communities. In TrustManagement, pages 161–175. Springer, 2004.

[25] Mischa M Tuffield, Dave E Millard, and Nigel R Shadbolt. On-tological approaches to modelling narrative. In 2nd AKT DTASymposium, 2006. Event Dates: January 2006.

[26] Daniel J Weitzner, Harold Abelson, Tim Berners-Lee, JoanFeigenbaum, James Hendler, and Gerald Jay Sussman. Infor-mation accountability. Communications of the ACM, 51(6):82–87, 2008.

[27] Daniel J Weitzner, Harold Abelson, Tim Berners-Lee, ChrisHanson, James Hendler, Lalana Kagal, Deborah L McGuin-ness, Gerald Jay Sussman, and K Krasnow Waterman. Trans-parent accountable data mining: New strategies for privacyprotection. 2006.

[28] Aydan R Yumerefendi and Jeffrey S Chase. Trust but ver-ify: accountability for network services. In Proceedings of the11th workshop on ACM SIGOPS European workshop, page 37.ACM, 2004.


B HDA-CASs Vocabulary


12/22/2014 The SmartSociety CAS Namespace

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

The SmartSociety CAS NamespaceUnofficial Draft 22 December 2014Editors:

Heather Packer, University of SouthamptonLuc Moreau, University of Southampton

This document is licensed under a Creative Commons Attribution 3.0 License.

IntroductionThe namespace name http://purl.org/cas/ns# defines terms for theSmartSociety Collective Adaptive Systems (CAS).

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

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

AAcknowledgement

An acknowledgement is a message that is passed between two agents to signifyacknowledgement, or receipt of a response, which is part of a communicationsprotocol.

cas: Acknowledgement

Activity

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

cas: Activity

Agent



An agent is anything that can possibly perform an activity. Alternatively, anythingthat 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

CCall

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



Composing tasks is an activity that may be comprised of the following activitiesauthenticating identity, computing composition and computinginvalidtasks.

cas: ComposingTasks

CompositionManager

A Composition Manager A composition manager is a peer which specialises incomposing tasks by searching and matching relevant peers and computing plansfor a task.

cas: CompositionManager

ComputingComposition

Computing composition is an activity that computes a set of valid tasks givenconstraints or negotiation inputs.

cas: ComputingComposition

ComputingReputation

Computing reputation is an activity that is run by the reputation manager when afeedback report is submitted, it computes a reputation report for all the subjectsreferred to by the submitted feedback report.

cas: ComputingReputation

FFeedbackReport

A feedback report is a report about a subject that contains a set of value ratingcategories. For example, "star rating = 4.3".

cas: FeedbackReport

IIdentity



Agents, users, peers all have identities. An unauthenticated user gets assignedan identity automatically.

cas: Identity

IncentivesManager

A incentives manager is a peer that specialises in providing incentives for peersto participate in tasks.

cas: IncentivesManager

MMessage

A message is a piece of information exchanged between agents.

cas: Message

NNegotiatingtask

Negotiating task is an activity that submits a task which may alter other tasks, itmay comprise of an authenticating identity and storing task activities.

cas: Negotiatingtask

NegotiationManager

cas: NegotiationManager

O



Opinion

An opinion is a quantitive value of the estimation of a subjects worth based onfeedback categories about it. either an activity, agent, peer, user, or collective, thatis being discussed, described, or dealt with in the context of feedback reports andreputation reports.

cas: Opinion

OpinionReport

An opinion report is a reputation report, which contains a single key value pairand binds an opinion to a value. The value is an aggregation of ratings from a setof reputation topics.

cas: OpinionReport

OrchestrationManager

An orchestration manager is a peer, which specialises in coordinating theinteraction between other peers.

cas: OrchestrationManager

PPeer

A peer is a software agent in a SmartSociety system that represents anotheragent.

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



Protocol

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

cas: Protocol

RReputationManager

A reputation manager is a peer, which specialises in storing feedback aboutsubjects and generating reputation and opinion reports about subjects. A view isan 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 ratingcategories. For example, a subject has been rated with a set of star ratings, andthe 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 thereputation 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



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

cas: Response

SSendingMessage

A sending message is the constituent of a protocol: it involves informationexchange.

cas: SendingMessage

SendingNegotiationResponse

Sending negotiation response is an entity that contains the response to anegotiating 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 feedbackreport within it.

cas: StoringFeedback

StoringTask

Storing task is an activity that stores a task locally.

cas: StoringTask



SubmittingTaskRequest

Submitting task request is an activity that submits a task, it may comprise of anauthenticating identity and storing task activities.

cas: SubmittingTaskRequest

SubmittingFeedback

Submitting feedback is an activity that submits a feedback report to thereputation manager.

cas: SubmittingFeedback

Subject

A subject is either an activity, agent, peer, user, or collective, that is beingdiscussed, described, or dealt with in the context of feedback reports andreputation reports.

cas: Subject

TTask

A task is a potential activity that involves capabilities, potentially contributed byseveral 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



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 ina peer and interact with it through API calls.

cas: UserInterface

email address here $Revision: 1.1 $ of $Date: 2013/04/29$

Documents

D2.2 - Provenance, Trust, Reputation and Big Data