\documentclass{llncs}
\usepackage{graphicx}
\usepackage{url}
\usepackage{subfigure}
\usepackage{listings}
\usepackage{color}
\usepackage{floatflt,graphicx}
\usepackage{epsfig}
\usepackage{amssymb}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{algorithmic}
\usepackage{paralist}
\usepackage{alltt} %Verbatim extended
\usepackage{pifont}

\definecolor{lightblue}{rgb}{.3,.5,1}
\definecolor{orange}{rgb}{1,.7,0}
\definecolor{darkorange}{rgb}{1,.4,0}
\definecolor{darkgreen}{rgb}{0,.4,0}
\definecolor{darkblue}{rgb}{0,0,.4}
\definecolor{darkred}{rgb}{.56,0,0}
\definecolor{gray}{rgb}{.2,.2,.2}
\definecolor{shadecolor}{gray}{0.7}



%% define RDFa look and feel
\lstdefinelanguage{RDFa}{
      morekeywords=[1]{about, ref, rel, content, property, href, resource, datatype, typeof},
      morestring=[b]",
      sensitive=false%
}[keywords,comments,strings]

\lstset{
      basicstyle = \scriptsize \ttfamily,%
      keywordstyle = [1]\color{darkgreen},%
      stringstyle  = \ttfamily\color{darkred},%
      commentstyle = \itshape\color{darkblue},%
      showstringspaces = false,%
%     fancyvrb = true,%
      firstnumber = auto, stepnumber=1, numbersep=5pt,%
      numbers=left, numberstyle=\tiny \ttfamily,
      frame = shadowbox, frameround = ffff, rulesepcolor = \color{shadecolor},
      breaklines=true, breakatwhitespace=true,%
%     prebreak=\textellipsis,postbreak=\textellipsis,%
      emphstyle = \color{red}\underbar, emphstyle = {[2]\color{blue}\underbar},%
      extendedchars = true, inputencoding = utf8,%
%     backgroundcolor=\color{shadecolor},
      xleftmargin=20pt, xrightmargin=10pt,
      captionpos = b
}


%% define N3 look and feel
\lstdefinelanguage{N3}{
      morekeywords=[1]{@prefix, a },
      morestring=[b]",
      morecomment=[s]{<}{>}, % missusing comments for URIrefs
      otherkeywords={^, [, ], (, )},%
      %otherkeywords=[2]{<, >},% for URIrefs
      sensitive=false%
}[keywords,comments,strings]

\lstset{
      basicstyle = \scriptsize \ttfamily,%
      keywordstyle = [1]\bfseries\color{darkgreen},%
      stringstyle  = \ttfamily\color{darkred},%
      commentstyle = \itshape\color{darkblue},%
      showstringspaces = false,%
%     fancyvrb = true,%
      firstnumber = auto, stepnumber=1, numbersep=5pt,%
      numbers=left, numberstyle=\tiny \ttfamily,
      frame = shadowbox, frameround = ffff, rulesepcolor = \color{shadecolor},
      breaklines=true, breakatwhitespace=true,%
%      prebreak=\textellipsis,postbreak=\textellipsis,%
      emphstyle = \color{red}\underbar, emphstyle = {[2]\color{blue}\underbar},%
      extendedchars = true, inputencoding = utf8,%
%     backgroundcolor=\color{shadecolor},
      xleftmargin=5pt, xrightmargin=2pt,
      captionpos = b
}




%%%%%%%%%%%%%%%%%
\begin{document}

 \title{Policy-Aware Pipes: Support Accountability in Mashup Service of Linked Data}
\author{Fuming Shih \and Lalana Kagal}
\institute{Computer Science and Artificial Intelligence Laboratory\\
Massachusetts Institute of Technology \\
\email{( fuming | lkagal )@csail.mit.edu}}

\maketitle
\begin{abstract}

With the proliferation of linked data on the Web, more Semantic Web applications are built in the form of mashups where data comes from multiple sources. Mashups enable easy content reuse in Web applications because of the interlinking between linked data sets, but they also complicate the governing of data usage in such an open environment. Many legal issues could arise in mashups when different sources have different legal claims and usage policies. Both publishers of linked data and mashup developers need methods to avoid inappropriate use of data in the life cycle of mashup services.

In this paper, our primary focus is to facilitate participants in a mashup environment in being policy aware and making the right decision to be held accountable for data usage. We present the requirements for policy support in a mashup environment and the methods for incorporating policies into the life cycle of mashup development. We implement a tool called Policy Aware Pipes (PAP) which provides functions that (1) validate policy compliance statement from mashup sources, (2) check for policy compliance, and (3) generate provenance and policy compliance statement of the mashup. In addition, we also provide a walkthrough of the scenario using PAP to create a mashup with existing linked data set. 

\end{abstract}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Introduction} \label{sec:introduction}
The Linked Open Data project \cite{linked_proj} has successfully brought a great amount of data to the Web that serves as content for Semantic Web applications. Web developers can now create Semantic Web applications effectively with \textit{interlinking} data sets, making use of data from many different sources. We have seen the transformation of Web services due to the change in the nature of data on the Web. With the emergence of Web 2.0, companies that once created Web services from data isolated in different \textit{data gardens}, have begun to make these data publicly available by using APIs, connecting the data with semantic relationships as linked data \cite{kobilarov_BBC_2009}. The \textit{opening up} of data encourages developers to reuse content on the Web and build applications from different sources to provide new functions, called \textit{Mashups} \cite{mashup_wiki}. With the proliferation of linked open data, we can foresee a blossoming of semantic Web applications in the form of mashups.

However, given the \textit{open} environment for data in the mashup world, concerns arise when a user wishes to assert some controls over the use of the data. For example, government agencies that publish linked data such as census data, might prohibit the use of the data in any commercial service, directly or indirectly. Because mashups allow developers to reassemble data in different content, they also complicate the governing of data usage. To support the governing of data usage, it is clear that authorization and authentication alone are not sufficient in the \textit{data centric} phenomenon of linked data world. Once the data is linked or retrieved in the mashup, it is impossible to ensure correct usage in different context in the data flow. Many legal issues can arise when merging data from different sources with differing legal claims and usage policies \cite{sgerber_law_2006}. This situation places great burdens on the mashup developers, who need to synthesize these individual policies and determine the allowed uses of the merged data. It also hampers the process for data publishers, who may hesitate to open up their data due to the unpredictable ways in which it may be used \cite{open_data_common}. 

To succeed in creating an environment that benefits both data publishers and mashup developers, we argue that information accountability should be introduced to mashup environments by applying policies on data usage \cite{weitzner_accountability_2008}. The goal is to build necessary technology support into the mashup process to make information usage more transparent to prevent participants from misusing the data. Although policies are commonly used in claiming privacy considerations, accessibilities and restrictions of the data, they are rarely incorporated into the development process of mashup services. Different stages of the mashup life cycle require different types of policy interactions. Data publishers, for example, need ways to create and attach policies to their data, while mashup creators need to extract and understand those policies. It is important to have methods and tools to put guidance into practice, so as to minimize the efforts required of all participants in being policy-compliant when creating mashups.

We present in this paper (1) a method for incorporating policies into the process of mashup construction for different players and (2) a tool called Policy-Aware Pipes (PAP) that implements these concepts. These two contributions are presented as follows: the next section gives a motivating scenario to present the challenges and problems of building a mashup using linked open data. 
Section \ref{sec:requirements} presents the requirements of policy interactions in the mashup. 
In Section \ref{sec:architecture} we discuss the architecture overview of PAP, and in Section \ref{sec:implementation} the implementation details. In Section \ref{sec:walkthrough} we presents a walkthrough of using PAP for building a mashup of previous scenario. Section \ref{sec:relatedwork} discusses the related works issues. The conclusions and future directions are presented in Section \ref{sec:conclusion}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Motivating Scenario}\label{sec:scenario}
We use the scenario below to sketch out the general policy problems and challenges of building a mashup of linked data, especially when cascading data flow occurs between mashups.
\subsection{Open Data from BBC Backstage}
Suppose Joe is a pop-music fan who spends much time searching and reading news about albums on the market. He is also a Web expert who creates a mashup site called ``music-meme.org'' that aggregates the most up-to-date articles and news about pop music, and publishes RSS feeds to contribute to the community. In one section of the mashup service, called ``music notes'',  he obtains information and reviews of each music album from linked data released by the BBC. The BBC has produced many services related to television programming and music, and recently this content has been made available as RDF data via the BBC Backstage \cite{bbc_linkeddata}. Joe wants to make sure that his website does not infringe the copyright and other policies of the BBC. For this open data, the BBC only supports non-commercial use of the content. The following text is extracted from the license agreement and additional policies on BBC's website \cite{bbc_license}\cite{frequently_asked}.

\textit{You must not: \\ *Charge users for accessing your work that contains or uses BBC Content. \\ *Sell applications that use or incorporate BBC Content .\\
...however, you own the Intellectual Property rights in and to your application and nothing prevents you being able to sell or commercially licence your application and make money from it. What you can not do is sell access to any BBC content (i.e any commercial use of your application would have to be done without using any BBC Content).}

Joe feels confident that his website is compliant with the BBC's policy and publishes his site to the community. 
%%%%%%%%%%%%%%%%%%%%
\subsection{Problems}
Suppose Bob is a software engineer of website called ``Alpha Music Box'', an online music store that charges users for downloading songs. He implementes a function on the music store that provides professional reviews of each album. Eventually, those albums with better reviews become increasingly popular. The music reviews, though they were consumed from data feeds of music-meme.org, are actually data originally from the BBC. Bob's use of the music reviews in a commercial mashup have possibly infringed the license agreement of the data source, even the music website did not make money directly from the BBC's content. The reasons for the misuse of the BBC's content were because (1) the policies were only \textit{human readable} and (2) the policies did not \textit{propagate together with the data} in the mashup of Joe's website. PAP provides steps toward solving this problem by incorporating policy into the mashup workflow. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Requirements of the Policy Support in the Mashup}\label{sec:requirements}
We have learned from the above use cases that a mashup of linked data needs policy support for information accountability. In this section, we list the requirements for policy interactions throughout the mashup life cycle. We also discuss how participants are assisted in the different stages of a mashup's life cycle. As shown in the right half of Fig. \ref{fig_overview}, we identify three types of participants in the mashup life cycle. The life cycle includes (1) generating the data by a data publisher, (2) using this data to define a new mashup by a mashup developer, and (3) utilizing the mashup output by a mashup consumer.
\subsection{Policy for Data Usage}
As owners of the data source, the data publishers need a policy language to assert the policies before publishing the data. Publishers use policy languages to specify usage restrictions and conditions for the linked data. In this paper, we suggest using Semantic Web technology as a policy language because it allows different entities to have a shared data model to describe constraints (e.g. security and privacy) within the domain \cite{weitzner_policy-aware_2004}. This practice increases the interoperability between policies which could be separately developed by different communities.  
%%%%%% 
\subsection{Policy Checking and Awareness}
When a mashup uses data from multiple sources, the mashup developer needs to extract policies stated in different data streams. The mashup tool needs to detect policy conflicts among the source policies and mashup contexts, then provide informative feedback to the mashup developer. Justifications of policy decisions (being compliant or not compliant) allow the mashup developer to understand how results are obtained \cite{kagal_dependency_2008} and to take the necessary actions to adjust the mashup such that it becomes policy compliant.
After checking for conflicts, the mashup tool can then suggest an appropriate merged policy which is compatible with the source policies for that mashup.
\subsection{Provenance Information}
Throughout the construction of the mashup, a mashup developer can design the mashup in terms of various operations, including SPARQL queries. Knowing the data sources as well as the operations performed is useful to a mashup consumer in inferring the trustworthiness of the mashup. If the mashup is compliant with the policies, the mashup tool should output the policy compliance statement together with the provenance information, and publish the results together as triples with the content of the mashup. Then the data consumer could use this information as an evaluation of the trustworthiness of this mashup. The data consumer could even be another mashup developer. In such a case, this second mashup developer would validate the compliance statement and use it for future auditing to clarify responsibilities of the two parties.
 
\begin{figure}[!h]
\begin{center}
\includegraphics[width=4in]{images/overview_graph}
\caption{Overview of Policy-Aware Pipe and mashup process}
\label{fig_overview}
\end{center}
\end{figure}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Architecture}\label{sec:architecture}
We have developed the Policy-Aware Pipes (PAP) as an extended operator on top of Semantic Web Pipes (SWP) \cite {danh_semanticpipe_2009}, an RDF workflow engine that helps users to build customized mashup services from data sources dynamically. The intuition of PAP is to bring policy awareness to the design phase of mashup services by providing informative feedback messages to the editing interface. This policy information allows mashup creators (1) to validate that they are using data in compliance with the policies of the source
providers, (2) to know what policies they can/must provide with their derived data, (3) to publish a ``policy compliant'' statement with their mashup. As Fig. \ref{fig_editor} shows, the user simply feeds RDF data sources to PAP and defines the local policy of the mashup service in the editor. PAP will also display messages on the debugging pane of the pipe editor to explain the results from the policy checking.

PAP has four major functions: (1) validating source provenances and policy compliance statements, (2) checking policy compliance for the merged sources, (3) suggesting possible policies based on those of the sources, and (4) generating provenance and policy compliance statements. PAP first validates a source's provenance by checking for the existence of the triples about policy compliance from the source repository. The compliance information will be displayed in the pipe editor and bring awareness to the users about the reliabilities of the merged sources. The second step is to compute the compatibility of a merged source \textit{S}, denoted as \textit{X(S)}, by retrieving each source's policy \textit{P} and running it against all the sources' profile metadata \textit{M}. If the user creates any policy locally for this mashup, it will be applied as well for policy checking. The \textit{policy conflict} \textit{C} of each source is detected if the profiles of other sources are not compatible. 
\begin{figure}[!h]
\begin{center}
\includegraphics[width=3.5in]{images/pipe_editor}
\caption{Example editing interface of Policy Aware Pipe}
\label{fig_editor}
\end{center}
\end{figure}
\begin{equation}
X(S) = C_{1}\wedge C_{2} \wedge ... \wedge C_{n}
\end{equation}
An example of a policy specified in the data source is given in Fig. \ref{fig-policy}, and an example of service profile of the data source is given in Fig. \ref{fig-profile}.
\begin{figure}[!h]
\begin{center}
\includegraphics[width=3.5in]{images/policy}
\caption{Example of policy specified in the data source. It rejects mashing up with the service defined as commercial in its profile.}
\label{fig-policy}
\end{center}
\end{figure}
\begin{figure}[!h]
\begin{center}
\includegraphics[width=3.5in]{images/profile}
\caption{Example of service profile of the data source. The service describes itself as having a subject of sport and trust value of 5}
\label{fig-profile}
\end{center}
\end{figure}

Notice that there are many ways to implement \textit{X(S)} and compute policy conflicts. In this prototype, the overall score of a policy conflict is simply the AND logic of $C_{i}$. The policy $P_{i}$ only specifies the \textit{restrictions} of each source that will be applied against the mashup context, which in this case are the profiles \textit{M} of all sources. For example, the above policy states that it refuses to mashup with any source that has described itself as ``commercial'' in its profile. It also rejects data sources published by the ``person'' identified with a specific FOAF URI. If any conflict is detected, the value of $C_{i}$ will be set to 1 and a message explaining the conflict will be shown in the Pipes editor's debugging pane. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Implementation}\label{sec:implementation}
Building PAP as an extension on top of Semantic Web Pipes (SWP) required us to implement two components in the SWP framework. SWP is a mashup builder for linked data with a Web GUI which shows the creation of a mashup in a workflow style. SWP is built in Java as a Web servlet operating on the Apache Tomcat Server. We first implemented the ``Operator'' interface that manipulates the triple store in SWP with customized functions. Then, we created a supplementary Java class called ``PolicyMashup'' that supports primitive policy checking, policy information logging for policy awareness, and policy compliance statement generation. 
%%%%%%%
\subsection{Policy and Service Ontologies} \label{sec:ontology}
We have created lightweight ontologies for both policies and Web service profiles that can be used by data publishers to specify their services and the policies associated with them. These ontologies are placeholders in our architecture and can be easily replaced by more complicated and expressive ontologies. The policy ontology is shown in Fig. \ref{fig-policy-ontology}, and the service profile ontology is shown in Fig. \ref{fig-profile-ontology}.
\begin{figure}[!h]
\begin{center}
\includegraphics[width=3.5in]{images/wspolicy}
\caption{Example of policy ontology that describes restrictions of source's data usage, such as subjects to reject or minimum trust value of a service to be accepted.}
\label{fig-policy-ontology}
\end{center}
\vspace{-0.1in}
\end{figure}
\begin{figure}[!h]
\begin{center}
\includegraphics[width=3.5in]{images/wsprofile}
\caption{Example of service profile ontology that describes each source. The profile of each source or mashup itself is used later in the checking for policy compliance.}
\label{fig-profile-ontology}
\end{center}
\vspace{-0.1in}
\end{figure}
We have assumed that each data source has its usage policy and service profile published together with the data. Under this assumption, the policy and service profile also need a way to \textit{attach} to the linked data, so that they can be dereferenced and queried using SPARQL queries later. To simplify this demonstration, we have assumed that the data source identifies the policy with Creative Commons' \textit{CC:morePermissions} (CC+) tag. CC+ is suggested by Creative Commons \cite{cc_plus} to address rights beyond those granted by a CC license. Service profiles are identified with the service ontology mentioned in Section \ref{sec:ontology}. Fig. \ref{fig-sourcefeed} shows how the data source can attach policy and service profiles to the published data presented in the form of RSS.1.0 \cite{rss10}. Because users could use different ontologies when defining their policy statementsm PAP needs a mapping between the different ontologies used. This will allow PAP to check the policies using a singled unified ontology. We are currently developing adapters to support external policy engines for policy checking as well.  
\begin{figure}[!h]
\begin{center}
\includegraphics[width=3.5in]{images/datasourcefeed}
\caption{Example of data source feed}
\label{fig-sourcefeed}
\end{center}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Policy Compliance}
PAP helps to extract the policy of each data source in SWP. It starts by looking for policy compliance triples in the data source, since the source could be from another mashup. Then, PAP reads the content of the policy and service profile of each source as well as those of the mashup itself. To check for policy conflicts, PAP checks the context of the mashup (the union of all service profiles) against each policy. If the content of any service profile is rejected by any policy, a notification is logged to bring up policy awareness later on the interface. 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{License Resolution}
As discussed in Section \ref{sec:ontology}, a data consumer can use cc:morePermissions to define an expressive policy about the data's usage, or simply use cc:license to associate a Creative Commons license with a service. In this case, PAP would make a call to a tool such as the Attribution License Violations Validator \cite{oshani_cc_2009} to figure out whether there is a conflict between the licenses of the sources.
Fig. \ref{fig-cc} shows an example interface for CC license resolution between three different sources:
\begin{figure}[!h]
\begin{center}
\includegraphics[width=2.8in]{images/CClicense}
\caption{Example interface of CC license resolution. 
The result shows the suggested output license from multiple sources}
\label{fig-cc}
\end{center}
\end{figure}
%%%%%%%%%%%%%%%%%
\subsection{Policy Awareness with Logging}
We have implemented a logging module in PAP that logs policy messages in RDF. The logging module generates a log message for every operation in the workflow of SWP (e.g. SPARQL queries) and in PAP itself. The log consists of  the name of the operator in Semantic Pipes which performed the task, the time at which the task was performed, and the output of the policy checking activities. PAP treats logs as RDF \textit{data} that can be queried everywhere using SPARQL queries, and creates feedback to bring awareness in the editor interface of SWP. It helps to integrate policy awareness seamlessly into mashup development. Fig. \ref{fig-policy_log} shows a table generated by PAP, listing the details of policy aware activities and any policy conflict that occurred. 
\begin{figure}[!h]
\includegraphics[width=5in, height=1.6in]{images/policy-log}
\caption{Example output of the policy aware messages by logging. Explanation of policy conflicts is shown in the message.}
\label{fig-policy_log}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%
\subsection{Generating Policy Compliance Statement and Provenance}
PAP will generate a policy compliance statement only if \textit{X(S)} is $0$, indicating that the output content is compliant with all the policies in the mashup context. Besides policy compliance information, PAP will also create provenance data for the mashup. The provenance data, consists of three parts: the source description, the SPARQL queries which were applied to the merged data sets from, and a timestamp. This information is encoded as triples to publish with the data in the mashup. Fig. \ref{fig-provenance} shows an example triples that describe provenance and policy compliance information.
\begin{figure}[!h]
\begin{center}
\includegraphics[width=5in]{images/provenance}
\caption{Example of provenance and policy compliance statement}
\label{fig-provenance}
\end{center}
\vspace{-0.1in}
\end{figure}\\
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Scenario Walkthrough} \label{sec:walkthrough}
To demonstrate the major challenges in facilitating an accountable mashup service, and to demonstrate how PAP can help designers to ensure adequate accountability among all parties involved, we now revisit the scenario presented in Section \ref{sec:scenario} and explained how PAP operates to accomplish the tasks.
First of all, BBC Backstage could state a \textit{machine readable} policy that describes the usage restrictions about its content as shown in Fig. \ref{fig:backstage-policy}.\\
\begin{figure}[!h]
\begin{center}
\includegraphics[width=3.5in]{images/bbc-policy-example}
\caption{Example of BBC Backstage policy for linked data}
\label{fig:backstage-policy}
\end{center}
\end{figure}
Using PAP, Joe has RDF triples that describe his mashup service as shown in Fig. \ref{fig:music-site-profile}.
\begin{figure}[!h]
\begin{center}
\includegraphics[width=3.5in]{images/music-meme-profile}
\caption{Example of service profile of website \textit{music-meme.org}}
\label{fig:music-site-profile}
\end{center}
\end{figure}
Because Joe's service was compliant with the BBC's policy, PAP merges the policies with Joe's and generates provenance and policy compliance information as shown in Fig. \ref{fig-provenance-music}.
\begin{figure}[!h]
\begin{center}
\includegraphics[width=4.8in]{images/provenance_scenario}
\caption{Example provenance of \textit{music-meme.org} with policy compliance statement}
\label{fig-provenance-music}
\end{center}
\end{figure}
Also, PAP embeds policy and license agreements into the data feed of Joe's mashup output, as shown in Fig. \ref{fig-rssfeed}.
\begin{figure}[!h]
\begin{center}
\includegraphics[width=5in]{images/RSSfeed}
\caption{Example of RSS Feed published by website \textit{music-meme.org}}
\label{fig-rssfeed}
\end{center}
\end{figure}
Later, when Bob's mashup consumes the content of reviews from Joe's mashup, it first queries the provenance information to ensure that Joe's data output was compliant with the its sources' policies. Using PAP, he found in the policy-aware logs that his service is not compliant with Joe's policy to not use the content commercially. At this juncture, Bob decides to use the reviews in another service that is not commercial.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Related Work} \label{sec:relatedwork}
With the proliferation of linked data, it is important to have tools that help developers create Web applications rapidly through content reuse. Several tools have followed the programming paradigm of \textit{Mashups} in Web 2.0, and developed either a language such as MashQL \cite{jarrar_mashql_2008}, or tools such as Semantic Web Pipes \cite{danh_semanticpipe_2009} and Potluck \cite{huynh_potluck_2008} that lower the barrier of programming skills needed to build mashups. Although these tools provide a way to ease the construction of the mashup, they do not address problems of inappropriate content reuse. Researchers from the law community have pointed out that legal problems arise from data reuse in mashup applications. In  \cite{sgerber_law_2006}, Gerber listed the legal issues that mashup developers would face. For example, the contract law issues, copyright law issues, issues of misleading the trademark, and privacy issues all lead to legal liabilities that could occur in the life cycle of a mashup. Research showes that unclear content usage which leads to legal issues is one of the major concerns that prevents the data owner from publishing data publicly \cite{open_data_common}. PAP introduces methods to incorporate policy interactions into the development of a mashup, and thus provides tools to encourage all participants to be policy-compliant in the mashup environment.

How to ensure information accountability in mashups still remains an open question, especially as data becomes \textit{open} and \textit{linked}. In the research of e-business engineering, Zou and Pavlovski \cite{zou_towards_2007} propose a framework to develop effective accountability solutions for mashup environments. It focuses on bringing mashup accountability to a level of quality comparable to that of enterprise Service Oriented Architecture. The paper suggests using Semantic Web technologies, such OWL-S to model the relationships and roles of entities in the mashup environment. Such a model helps to capture the traceability of service compositions and reason over the responsibilities of parties involved in the mashup. Other work \cite{khalili_using_2008} uses encryption technology together with extra meta Web services to support identification and traceability between layers of mashups to ensure a trusted environment. Trust establishment requires transparency of the responsibility and obligations of all participants, as well as methods and technologies to support it. Both approaches require a mechanism that globally supports traceability in the mashup environment, whereas PAP uses provenance data and policy compliance statements for evaluating the trustworthiness between two players. 
%%%%%%%%%%%%%%%%%%%%% 
\section{Conclusion and Future Work} \label{sec:conclusion}
With more linked data being published on the Web, the next big challenge of Semantic Web could be the effective and appropriate use of linked data in mashup applications. We foresee the importance of the integration of policy frameworks into mashup development to facilitate both content publishing and content reuse for linked data. In this paper, we presented the requirements of policy support in mashup environments and a method for incorporating policies into the life cycle of mashup development. Then, we presented a tool called Policy Aware Pipes (PAP) that integrates into the the existing Semantic Web Pipes mashup tool to implement policy interactions. Finally we walked through a scenario about building a mashup application for linked data and demonstrated the feasibility and benefits of using PAP.

We envision that PAP could be extended to support different policy languages for policy chekcing. We plan to build an interface to connect to external policy reasoners, and a wrapper to understand the results returned from different policy reasoners. Another challenge we plan to undertake is to further explore how to bring policy awareness into the development workflow of tools like Semantic Web Pipes. An interesting future project might be to integrate policy into the mashup development cycle by using a coding paradigm called Aspect Oriented Programming (AOP) \cite{aop_ibm}. By considering the policy as an \textit{aspect} of the mashup system, AOP helps to separate the core concerns of a mashup, for example manipulating linked data, with crosscutting concerns such as policy conformance and enforcement. Such a system would allow a more flexible and modularized integration of policy into the content reuse life cycle. 

\section*{Acknowledgements}
The authors wish to thank their group members for their contributions
to this project. This work was supported in part by NSF Cybertrust award NSF CT-M: 0831442 and AFOSR YIP award FA9550-09-1-0152.
\bibliographystyle{abbrv}
\bibliography{paper}

\end{document}  