Collaborative e-Science projects commonly require data analysis to be performed on distributed data sets which may contain sensitive information. In addition to the credential-based privacy protection, ensuring proper handling of computerized data for disclosure and analysis is particularly essential in eScience. In this paper, we propose a semantic approach for enforcing it through workflow systems. We define privacy preservation and analysis-relevant terms as ontologies and incorporate them into a proposed policy framework to represent and enforce the policies. We believe that workflow systems with the proposed privacy-awareness incorporated could ease the scientists in setting up privacy polices that suit for different types of collaborative research projects and can help them in safeguarding the privacy of sensitive data throughout the data analysis lifecycle.
Trust and security were always central to the vision of the Semantic Web [
The Web has always raised concerns for privacy data. There is concern about the
wide availability of yellow pages and other directory information, and the fact that
protected or sensitive information may become available over the Web perhaps
unintentionally [
Although privacy has broader interest and applicability, our research arises and
focuses in the context of e-Science applications. Many areas in biomedical sciences
envision benefit from clinical records (e.g., cabig.nci.nih.gov), phenotype
information, and health history. In social and behavioral sciences, widely available
on-line information can be integrated and analyzed to reveal significant patterns that
emerge in specific communities, influential groups and individuals within a social
network, and trends or events of interest. Much of this research is hindered because of
the concern of individuals with their privacy and therefore their reluctance to allow
the use of their personal data. Yet, many people would choose to give up their privacy
for some greater good such as advancing medical research, especially when they are
provided with mechanisms to protect the privacy of their data [
A variety of mechanisms are being investigated to ensure data privacy including secure data storage, data access control, auditing mechanisms, and securing lines of communication. Also, laws and policies for protecting and enforcing health information privacy will need to be formulated in order to determine how those technologies need to be used to implement the law. These mechanisms are important and necessary to control the access and release of data. However, they will not necessarily support the anticipated sophistication of people’s wishes over the finegrained control over the uses of their sensitive data, say, for clinical data analysis conducted by some third parties. Furthermore, the control is further complicated by the recent trend that the uses of sensitive data are no longer confined to the institution that collected or owns the data but highly distributed (e.g., cabig.nci.nih.gov). 1.2
In recent years, a variety of workflow systems have been developed to manage
complex scientific analysis processes [
We take a semantic approach to incorporate privacy awareness into workflow
architectures and our implementation in the Wings/Pegasus workflow system [
The paper begins with ontological representations for privacy-relevant terms in data analysis workflows and illustrate how those ontologies could be used to describe workflow systems that incorporate traditional data analysis algorithms and privacypreserving algorithms for analyzing sensitive data. To support automatic privacy policy enforcement in data analysis workflows, we propose a particular policy representation which has components describing applicable context, data usage requirement, privacy protection requirement, and corrective actions if the policy is violated. We present initial results on extending a workflow system to include representations of privacy policies that can be enforced by the system. We finalize with a discussion of related work and possible avenues for future research in this area.
of privacy preservation methods that convert the input into privacy preserved forms.
Privacy preservation methods can process on each attribute individually or the data set
as a whole. PrivacyPreservationPerAttribute contains component types such as
Anonymization (e.g., masking, substitution) and PrivacyPreservationPerDataset
contains Generalization (e.g., k-anonymity [
Data Analysis Ontology. It provides a separate taxonomy of data analysis methods. We consider here statistical data analysis algorithms that are widely used in many domains. In our ontology, DataAnalysis is the root class with subclasses like Clustering (e.g., Gaussian mixture model ), Classification, etc.
Extensions of the file ontology. We extend the ontology to describe data protection up to per-attribute level. Some additional properties and classes added include: • hasAttribute whose range captures data attributes described as Attribute. • hasAuthorizedUse which refers to the intended use or purpose of the File. • Attribute which models file attributes and has a property protectedBy (with subproperties, e.g. anonymizedBy) to indicate the adopted privacy preservation method. • special types of File, e.g., DataSet for raw data files and Clusters for clustering results which can go with data items (ClustersWithDataItems) or just per-cluster statistics (ClustersWithStatistics). The latter is needed when data privacy is an issue.
• hasPurpose which refers to data analysis purpose. • hasOutputQuality which refers to overall output quality descriptors, e.g. accuracy. Extensions of component ontology. Some properties and subclasses added include: • hasParameterSet which refers to the set of parameters needed by the component. • PPComponentType which contains privacy preservation methods as its sub-classes, e.g., Generalizer (which in turn has sub-classes, e.g. k-anonymity), and has a property hasLevelOfProtection for describing the level that its output is protected. • DAComponentType which contains data analysis methods as its sub-classes, e.g., Clustering (which in turn has sub-classes, e.g. GMM), and has supportPPType and supportDataType to indicate its supporting types of privacy preservation and data.
To illustrate how a domain-specific data analysis workflow can be described, we
adopt a hypothetic clinical data analysis task. Like many other domains, clinical data
can contain patents’ personal identification and demographic information as well as
sensitive ones including medical measurements, medical treatment, drug dosage,
diagnosis, etc. We assume data collected from patient records archived at different
clinic to (1) have the personal identification fields anonymized, (2) be generalized
into groups based on their demographic information by k-anonymity and (3) be
abstracted up to an agreed level of details based on the numerical medical attributes
(e.g., by GMM [
We represent data privacy policies semantically based on the derived ontologies so as to support automatic policy enforcement in data analysis workflows via reasoning. Note that the privacy awareness being considered here is not conventional credentialbased authentication and authorization. Instead we require a policy language that is flexible enough to describe conditions reflecting different relationships among data sets, components, and their privacy-relevant properties. Such a flexibility requirement naturally leads us to the use of rule-based representation. Note that other than expecting the users to specify the rules, rule-based policies carefully created by experts of the respective field can always be adopted.
In our current design, a policy representation contains four parts, namely (1) context, (2) usage requirement, (3) protection requirement, (4) corrective action. Informally, context specifies what workflows the policy applies. As we are dealing with data privacy, the context refers to some types of links, data or components where the policy is applicable. Usage requirements and protection requirements are for detecting policy violation within the context. Finally, corrective actions are suggestions for remedy of the policy violation, typically referring to the statements mentioned in the protection requirements. We further characterize requirements to be of positive and negative types. Positive requirements specify compliance conditions and policy violations occur when the conditions ARE NOT satisfied. Negative requirements specify non-compliance conditions and policy violations occur when the conditions ARE satisfied. As seen in the following, both types of requirements are essential for policy representation.
Context refers to the condition where the underlying policy is relevant. In other words, the policy applies only if this condition is satisfied. • Example C1: “Input files of a workflow containing medical images.”
InLink(?l) ^ hasFile(?l, ?d) ^ hasAttribute(?d, ?a) ^ MedicalImage(?a) Usage requirement refers to the non-amendable condition under which the use of data is required (+ve) or not allowed (-ve). • Example UR1 (+ve): “It is required that the purpose of the workflow should be equal to the authorized usage of the inputs that match the context.” for(?w, ?pw) ^ hasAuthorizedUse(?d, ?pw) ^ equal(?pw, ?pd) Protection requirement refers to the condition when the use of data is required (+ve) or not allowed (-ve) with respect to data protection and analysis quality. • Example PR3 (-ve): “It is not allowed that the nodes that match the context have inputs with attributes in common.” hasAttribute(?d1, ?a1) ^ hasAttribute(?d2, ?a2) ^ equal(?a1, ?a2)) Corrective action refers to the remedies recommended to fix policy violation. For “usage requirement” violation, only a printed message stating the violating policy is expected as no remedy is possible. For “protection requirement” violation, a corresponding recommended action for fixing the violation will also be provided.
context component rule to locate where the policy applies and a requirement component rule to determine if non-compliance conditions occur within the context.
For the policy with a negative requirement, its context component rule and requirement component rule can simply be combined by conjunction and applied to a workflow description. Thus, the overall rule becomes [context rule] ^ [requirement rule] -> invalid (?l). Matched results will correspond to the policy violation situations.
For the policy with a positive requirement, the overall rule for detection problematic
parts can be represented as [context rule] ^ not [requirement] -> invalid (?l). However, the
rule becomes not a horn clause and thus cannot be easily represented using SWRL.
Thus, instead of applying directly the overall rule, we apply the context rule first to
the workflow and the matched results form a set with items of concern. Then, we
applied the requirement rule to the set. The newly matched items are removed from
the set in context and the remaining ones are the violation situations. This treatment
works when the policies are free of conflicts among them. If there are some parts in
the workflow with more than one policies applicable, policy conflicts will occur. We
are currently investigating algorithms for policy conflict detection and resolution [
General Policy G1:“For all the inputs, it is required that the purpose of the workflow should be equal to the authorized usage of the inputs.” context: usage: protection: NULL correction: prompt [workflow and data purpose mismatch]
WorkflowTemplate(?w) ^ for(?w, ?l) ^ hasFile(?l, ?d) +ve: for(?w, ?pw) ^ hasAuthorizedUse(?d, ?pdl) ^ equal(?pw, ?pd)
Domain Specific Policy S1: “For data that contain dosage information, it is not allowed that they are not first anonymized before being used for analysis.” context: usage: hasLink(?w, ?l) ^ hasFile(?l,?d) ^ hasAttribute(?d, ?a) ^ Dosage(?a) hasDestinationNode(?l, ?n) ^ hasComponent(?n, ?c) ^ DAComponent(?c)
NULL
protection: -ve: anonymized(?d, ?aVal) ^ equal(?aVal, false)
correction: prompt [add an anonymization step right after (?d) found at (?l) ]
Suppose a researcher creates a simple workflow template that takes directly all the
raw clinical datasets and feeds them into a basic GMM clustering component to
perform a clinical study. The workflow system would find that policy G1 applies and
is respected. However, policy S1 is fired as the aggregate dataset fed to the
GMMbasic was found not to be anonymized. Fig. 3 shows the detection of the violation of
the policy S1. The workflow in Fig. 2 complies with all these policies. In [
To the best of our knowledge, there has not been prior work on extending
workflow systems with data privacy awareness. Some policy frameworks like KAoS
[
In this paper, we motivated the need for a new type of privacy policies that constrain processing on data. We described our initial work on a semantic approach to represent privacy policies relevant to data analysis. We argued the validity of the approach by showing how privacy-preserving data analysis processes can be defined using ontologies, and how the ontologies can be combined with a policy framework to represent the policies. We discussed how those policies can be applied via examples. Future work includes conflict detection algorithms for the proposed policy framework and incorporation of the policy enforcement module in the Wings system.
This research was supported in part by the Air Force Office of Scientific Research (AFOSR) through grant FA9550-06-1-0031. The second author was a Visiting Scholar at ISI, USC while this paper was written, and he thanks Hong Kong Baptist University for a sabbatical leave.