# Policies Composition Based on Data Usage Context

Valeria Soto-Mendoza, Patricia Serrano-Alvarado, Emmanuel Desmontils,
José-Antonio García-Macías

► To cite this version:

Valeria Soto-Mendoza, Patricia Serrano-Alvarado, Emmanuel Desmontils, José-Antonio García-Macías. Policies Composition Based on Data Usage Context. Sixth International Workshop on Consuming Linked Data (COLD2015) at ISWC, Oct 2015, Bethlehem, United States. hal-01184660

HAL Id: hal-01184660

https://hal.science/hal-01184660

Submitted on 5 Oct 2015

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
Policies Composition Based on Data Usage
Context

Valeria Soto-Mendoza¹, Patricia Serrano-Alvarado²,
Emmanuel Desmontils², and J. Antonio García-Macías¹

¹ CICESE Research Center, Ensenada, Baja California, Mexico
vsoto@cicese.edu.mx, jagm@cicese.mx

² LINA, Université de Nantes, France
{Patricia.Serrano-Alvarado, Emmanuel.Desmontils}@univ-nantes.fr

**Abstract.** In federated query processing, different datasets can be queried simultaneously. Each dataset has different privacy policies attached, but, which privacy policy will govern the usage of the query result? In this work we propose a mechanism, based on semantic web technologies, to compose privacy policies. The originality of our approach is that our composition rules are based on the data usage context and deduce implicit terms.

**Keywords:** semantic web, federated query, federated query engine, privacy policy, usage policy, usage context, policies composition

# 1 Introduction

The semantic web allows to express data in a way that facilitates data sharing and data analysis. On the one hand, data owners can share their data through endpoints which process queries. Privacy policies are often attached to these data. These policies describe how to use data, what is permitted, obliged or prohibited. Nevertheless, everything is not expressed and implicit aspects should be considered about data usage taking into account contextual aspects. On the other hand, data consumers access endpoints to process data using a query engine. This latter can be a federated query engine able to process queries, orchestrating simultaneous access to multiple endpoints.

The issue we deal with in this paper is, how to compute the usage policy of combined data, result of a federated query. Challenging questions are (i) how to define a usage policy by composition of multiple usage policies? (ii) how to take into account usage context aspects like usage location, usage purposes but also predefined stances of users (optimistic, pessimistic)? (iii) how to compose privacy policies that are not defined with the same set of policy terms or how to manage a term created specifically for a policy or for a context?

In this paper, an approach for composition of usage policies, based on semantic web technologies is proposed. Besides defining usage policies, this solution
takes into account implicit or general aspects of the data usage context during policies composition.

This paper presents a usage policy model and a motivating example in Section 2. The process to compose usage policies is presented in Section 3. Related works are analyzed in Section 6, and Section 7 concludes.

# 2 Context-aware usage policies

Nowadays people own several mobile devices or plug computers with increas-
ing capabilities to collect and generate data. Data owners must be responsible
of their personal data, this means that every one should have the capability
to manage his/her own data. So, every grantor should create usage policies for
his/her resources as simply as possible, and in a machine-readable format, spe-
cially if data should be shared with others. In this work, we consider the use of
semantic web technologies to represent privacy policies. The particularity of our
policies is the usage context.

## 2.1 Policies representation

The ontology Privacy Lookout<fnref n="3" /> (PriLoo) [5] is used to represent policies. An abstraction of the PriLoo ontology is shown in Figure 1. It supports traditional models, such as *permissions*, *prohibitions* and *obligations*, represented as properties and organized between a Policy of Usage Context (PUC) and a License. A PUC has a License which can obligate or prohibit *LegalTerms* (i.e., *by, sa, history, notice, etc.*). Licenses can also permit or prohibit *Operations* (*read, write, distribute, etc.*).

PUC describes the usage policy under different contextual aspects. It describes (i) *implicitProperties* in terms of *ImplicitStatus*, two values are allowed, *all-but-prohibited*, to prohibit all implicit terms and *all-but-permits-or-obliges*, to permit or to oblige implicit terms; (ii) *Purposes* (i.e., *commercial, medical, tracking, scientific*, etc.) that are considered in the usage context because they are business activities; (iii) other properties like the grantee, the grantor, concerned resources, the valid period of time, the usage locality, etc.

*LegalTerms, Operations and Purposes* are *terms* that can be structured according to a hierarchical tree using the inheritance relationship. For instance, *LegalTerm* "moral rights preserve" inherits of "rights preserve", *consultation* purpose inherits of *medical* purpose).<fnref n="4" />

Several standard licenses have been defined in PriLoo like CC-By or Beer-
ware.<fnref n="5" /> In order to simplify licenses, PriLoo allows to define a license as part of
a family of licenses. Thus, licenses which have common descriptions are grouped

<footnote n="3">³ http://privacy-lookout.net/ontologies/2015/06/28/pl-ontology.n3.</footnote>

<footnote n="4">⁴ See http://privacy-lookout.net/ontologies/2015/06/28/pl-usage-terms.n3 to obtain the legal terms, operations and purposes defined in PriLoo.</footnote>

<footnote n="5">⁵ See http://privacy-lookout.net/ontologies/2015/06/28/pl-licenses.n3 for the list of standard licenses expressed with PriLoo.</footnote>
into families, for example *CreativeCommons* or *PublicDomain*. These licenses
can be included in PUCs.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Abstraction of the PriLoo ontology.</figcaption></figure>

Figure 2 shows two examples of privacy policies written in the RDF/N3 syntax. Policy 1 is defined by a resident of a care institution, to protect access to his/her personal information such as temperature or blood pressure, contained in the file *Resident1PersonalData.n3*. In addition, the PUC of this policy permits access for *scientific* and *medical* purposes but the *tracking* purpose is prohibited. The grantee is a geriatrician. The licence of this policy allows the *read* operation. Policy 2 is defined by Mary Thomson. PUC states that data about daily activities, contained in the file *Digitalresources.n3*, can be accessed for *scientific* purposes by a research center (specified in *pl:grantee*). The license of this policy is CC BY that belongs to the family *CreativeCommons* and the *write* operation is permitted.

1 :License1 a pl:License ;
2 pl:permits operation:read .
3 :PUC_elder1 a pl:PUC ;
4 pl:permits purpose:scientific, purpose:medical ;
5 pl:prohibits purpose:tracking ;
6 pl:object <Resident1PersonalData.n3> ;
7 pl:hasLicense :License1 ;
8 pl:duration "P0Y0M2D" * xsd:duration ;
9 pl:maxUses "3" * xsd:integer ;
10 pl:grantee <http://www.clinicasantaclarita.com/Dr.Clemente.Humberto.Zuniga_Gil.html>,
<http://serenaseniorcare.com/> ;
<http://www.cicese.edu.mx/> ;
12 pl:grantor <Resident1.n3> ;
13 pl:usageLocality
<http://dbpedia.org/resource/Mexico>,
<http://dbpedia.org/resource/USA> ;
14 pl:storageLocality
<http://dbpedia.org/resource/Mexico> ;
15 pl:global-preference pl:pessimistic .

1 :License2 a pl:License ;
2 pl:memberOfTheFamily lic:CreativeCommons ;
3 pl:obliges legalTerm:by ;
4 pl:permits operation:write .
5 :PUC_researchCenter1 a pl:PUC ;
6 pl:object <Digitalresources.n3> ;
7 pl:hasLicense :License2 ;
8 pl:permits purpose:scientific ;
9 pl:prohibits purpose:sales, purpose:commercial ;
10 pl:duration "P0Y0M2D" * xsd:duration ;
11 pl:grantee <http://www.cicese.edu.mx/> ;
12 pl:grantor <MaryThomson.n3> ;
13 pl:usageLocality <http://dbpedia.org/resource/Mexico>;
14 pl:storageLocality <http://dbpedia.org/resource/USA> .

a) Policy 1

b) Policy 2

<caption>Fig. 2. Two examples of privacy policies.</caption>

Other contextual aspects are defined like location of storage (e.g., “Mexico”
in line 14 of Figure 2a), usage locality (e.g., “Mexico” in line 13 of Figure 2b),
the period of time of usage, number of permitted usages (e.g., 3 uses in line 9 of Figure 2a).

## 2.2 Motivating example: Geriatric center use case

The scenarios considered concern daily activities of a geriatric center [6] where many older adults are living together. Produced personal data are stored in a distributed system where each older adult has his/her own storage system and personal policies available through an endpoint. We consider a single federated query engine as a web service available to physicians, caregivers, scientist, etc. Our module PrODUCE (Privacy Policies cOmposition with Data Usage Con-tExt) performs a context-aware composition process using ontology-based rules (see Figure 3).

<figure><img src="image_3.png" /><figcaption>Fig. 3. Federated query process in a geriatric center.</figcaption></figure>

### Scenario 1.

Every two weeks a physician visits the geriatric center to check residents. She searches for the relevant data of each consulted resident, so she uses the information system to get the data. The relevant information is related with vitals signs (temperature, blood pressure, pulse, weight, etc.), meals, medicaments, but also, anomalies or comments from caregivers. In this occasion a physician requires data about blood pressure of all older adults who have hypertension.

In this scenario three policies from different residents are considered: *Policy 1* (Figure 2), *Policy 3* and *Policy 4* (Figure 4). The physician needs to obtain the older adults having blood pressure > 120, which is considered as an indicator of
1 :License3 a pl:License ;
2 pl:permits operation:read, operation:distribute .

3 :PUC_elder2 a pl:PUC ;
4 pl:permits purpose:medical ;
5 pl:prohibits purpose:commercial, purpose:scientific ;
6 pl:object <Resident2PersonalData.n3> ;
7 pl:hasLicense :License3 ;
8 pl:duration "P0Y0M2D" ^ xsd:duration ;
9 pl:maxUses "3" ^ xsd:integer ;
10 pl:global-preference pl:pessimistic ;
11 pl:grantee <http://serenaseniorcare.com/> ;
12 pl:grantor <Resident2.n3> ;
13 pl:usageLocality <http://dbpedia.org/resource/Mexico> ;
14 pl:storageLocality <http://dbpedia.org/resource/Mexico> .

a) Policy 3

1 :License4 a pl:License ;
2 pl:permits operation:sharing, operation:publishing, operation:distribute, operation:read ;
3 pl:obliges tlegalTerm:by .

4 :PUC_elder3 a pl:PUC ;
5 pl:permits purpose:scientific, purpose:medical, purpose:wellbeing, purpose:consultation, purpose:commercial ;
6 pl:object <Resident3PersonalData.n3> ;
7 pl:hasLicense :License4 ;
8 pl:duration "P0Y0M2D" ^ xsd:duration ;
9 pl:maxUses "3" ^ xsd:integer ;
10 pl:global-preference pl:optimistic ;
11 pl:grantee <http://www.clinicasantaclarita.com/Dr_Clemente_Humberto_Zuniga_Gil.html>,
<http://serenaseniorcare.com/> ;
12 pl:grantor <Resident3.n3> ;
13 pl:usageLocality <http://dbpedia.org/resource/Mexico>, <http://dbpedia.org/resource/USA> ;
14 pl:storageLocality <http://dbpedia.org/resource/Mexico>, <http://dbpedia.org/resource/USA> .

b) Policy 4

1 :License5 a pl:License ;
2 pl:permits term:read, term:distribution .

3 :PUC_elder2 a pl:PUC ;
4 pl:permits term:scientific, term:tracking ;
5 pl:prohibits term:commercial, term:medical ;
6 pl:object <Resident2PersonalData.n3> ;
7 pl:hasLicense :License5 ;
8 pl:duration "P0Y0M2D" ^ xsd:duration ;
9 pl:maxUses "3" ^ xsd:integer ;
10 pl:global-preference pl:optimistic ;
11 pl:grantee <http://serenaseniorcare.com/> ;
12 pl:grantor <Resident2.n3> ;
13 pl:usageLocality <http://dbpedia.org/resource/Mexico> ;
14 pl:storageLocality <http://dbpedia.org/resource/Mexico> .

c) Policy 5

<caption>Fig. 4. Policies for scenarios 1 and 2.</caption>

hypertension. The purpose of the physician's query is *medical* which is included
in the query.

Scenario 2.

The geriatric center collaborates with other institutions for scientific research purposes. Scientists investigate about specific topics related with the caring process. This time a scientist performs an evaluation of a group of elders taking a particular drug. For this, she queries regularly the blood pressure of the group and collects related data of every older adult of the group.

For this scenario, three policies from different residents are also considered:
*License1*, *License4* and *License5*. Now, the purpose of this query is *scientific*.

In both scenarios, users want to query data about older adults. Each resident
has his/her own personal policy and the users their specific query's purposes. So
the need to merge every aspect of concerned policies emerged. The composition
process is presented in next section.

3 Composition process

The proposed composition process, generates a policy from a set of policies,
see Figure 5. Firstly, input policies are extended with terms used by the PUC
and the license. Then implicit terms are added according to context rules or
explicit default terms. Secondly, basic composition rules are applied. Finally,
inconsistencies are identified and solved. When the composition is not possible a
*FALSE* answer is returned. The rationale of every stage is presented next, and
illustrated, step by step, with scenarios from previous section.

<figure><img src="image_4.png" /><figcaption>Fig. 5. Composition process.</figcaption></figure>

3.1 Stage 0. Pre-processing.

In this stage, the policies are analyzed and, if necessary, all additional terms of
the ontology (which are concerned by the policy) are incorporated. This rule-
based process, takes into account not only terms existing at the PUC definition
but also all terms existing at the composition time (perhaps terms existing in
another policy). Consequently, rules that exploit relationships with data-usage
context and, sometimes, that define implicit terms management are proposed to
complete policies. Table 1 presents examples of rules (written in Jena⁶) used in
this stage. Three sets of rules were defined:

1. "business rules" depend on licenses (Table 1a). For instance, these rules are used to add a purpose to a PUC or to add a legal term, associated to a given purpose, to a license.

⁶ Java API for RDF in https://jena.apache.org/.
2. "propagation rules" take into account inheritance of terms according to a property (Table 1b). For instance, when a term inherits from another term and the last one is permitted, then the first one is permitted too (unless the PUC prohibits it).

3. "implicit management rules" manage implicit terms (Table 1c). If a term is not specified in a PUC, the propagation rules (explained before) do not conclude and the property to manage them (*pl:implicitProperties*) does not exist, then, implicit management rules deduce, from the context (purposes, licenses, etc.), if unspecified terms are permitted, obliged or prohibited.

<table><caption>**Table 1.** Ontology-based rules considering data usage context.</caption><thead><tr><th></th><th>Ontology-based rules</th><th>Description</th></tr></thead><tbody><tr><td>a</td><td>[addTermsFromContext: (?up pl:hasLicense ?l), (?up pl:permits term:scientific), noValue(?l pl:PolicyProperty term:constraintDerivative) -> (?l pl:obliges term:constraintDerivative)]</td><td>For a context which contains the purpose "scientific", this business rule adds to the licence the obligation of "constraint-Derivative".</td></tr><tr><td>b</td><td>[addHierachicalPurposes: (?up pl:hasLicense ?lic), (?up pl:prohibits ?t), (?s term:inherits ?t), noValue(?lic ?p ?s) -> (?up pl:prohibits ?s)]</td><td>This propagation rule applies inheritance to a term : when a term is prohibited, all terms more specific are also prohibited unless this term is already used.</td></tr><tr><td>c</td><td>[addImplicitTerms: (?up pl:permits term:medical), -> noValue(?p pl:implicitProperties ?q) (?up pl:implicitProperties pl:all-but-prohibited)]</td><td>In this implicit management rule, when the PUC permits a medical use, all terms which are not used by the licence are prohibited.</td></tr></tbody></table>

## Pre-processing stage for Scenario 1.

The input policies are pre-processed and all of them allow the *medical* purpose which is the main query's purpose of the physician. The expanded policies include terms added based on the *medical* purpose after applying the business rules. For instance, in the extended *Policy 3*, shown in Figure 6a, *consultation* and *tracking* purposes are added because they inherit from the *medical* purpose. Moreover, due to the *medical* purpose and after applying the implicit management rules (*all-but-prohibited*) because in *medical* context all data is very important and must be treated as confidential), all not explicitly specified terms are added as *prohibits*, as well as prohibited purposes in the PUC.

## Pre-processing stage for Scenario 2.

One objective pursued by scientists is to publish their research results. Therefore, as a part of the context the *publishing* purpose inside the *permits* model is included in all the policies containing the *scientific* purpose. These not explicitly specified terms are included in the pre-processing stage, the property *all-but-permit-oblig* is used to perform this action. This property also allows to include all not prohibited terms as obligations inside the *obliges* model shown in *Policy 5* (Figure 6b).
## 3.2 Stage 1. Operators execution.

In this stage, the terms of all models (*permits*, *prohibits* and *obliges*) are analyzed. The operators shown in Table 2 are applied depending on the model: AND operator for permissions and OR operator for prohibitions and obligations. AND operator includes terms that appear in all the policies inside the *permits* model. In the *prohibits* and *obliges* models, the OR operator includes all the terms that appear in at least one policy.<fnref n="7" />

<figure><img src="image_5.png" /><figcaption>b) Policy 5 extended, Scenario 2

**Fig. 6.** Extended policies for both scenarios.</figcaption></figure>

### Operators execution stage for Scenario 1.

Here, the AND/OR operators are applied to combine the three policies. In this case, only the *permits* (i.e., *read* and *medical*) that appeared in all the policies are added to the composite policy, all *prohibitions* and *obligations* terms are also added to the composite policy if they appear in at least one policy.

<footnote n="7">⁷ Due to lack of space, the resulting policies of the scenarios are not presented.</footnote>
## Operators execution stage for Scenario 2.

In this case, the *permits* purposes are *scientific* and *distribute*. The latter as a result of the policy expansion in the pre-processing stage. The purpose *medical* is *prohibit* therefore it remains as is. The term *by* is *obliges* and all the rest of the terms added in the previous stage remain (i.e., *moralRights*, *origin*, etc.).

<table><caption>**Table 2.** Operators used for policies composition.</caption><thead><tr><td>Model</td><td>Operator</td><td>Description</td></tr></thead><tbody><tr><td>Permits</td><td>AND</td><td>A term is permitted if it appears in all policies.</td></tr><tr><td>Prohibits</td><td>OR</td><td>A term is prohibited/obligated if it appears in at least in one policy.</td></tr><tr><td>Obliges</td><td></td><td></td></tr></tbody></table>

## 3.3 Stage 2. Inconsistencies detection.

Generated policy in the previous stage is checked to search for inconsistencies. In this verification, we consider that original terms appearing in the policy have the highest priority, terms added by business rules have a medium priority, and terms added by implicit management and propagation rules have the lowest priority. Taking into account the previous priorities, next steps were applied:

- if one permitted term, with the same priority, is prohibited in at least one policy, then it will not be included in the final policy;

- if two terms are not compatible then we choose one of them based on the requester purpose;

- the term with the highest priority will always be included in the final policy.

### Inconsistencies detection stage for Scenario 1.

The final stage eliminates the remaining inconsistencies, i.e. the term *by* and *constraintDerivative* as *obliges* are the original terms. This means they have the highest priority, then they are eliminated from the *prohibits* model (Figure 7a).

### Inconsistencies detection stage for Scenario 2.

Some of the terms of the resulted policy, after the previous stage, appeared as *obliges* and *prohibits* what generates inconsistencies. Only the purpose *scientific* and, terms *publishing* and *read* were as *permits*. For the composite policy (Figure 7b), the inconsistencies found among terms inside *obliges* and *prohibits* models are suppressed considering the priority of the terms (i.e., *by*, *notice*).

As can be seen, each purpose contributes to each policy by adding different terms. Also, the stance of the owner is considered, as well as the user purpose (i.e., purposes expressed in the query by the scientist - *scientific* purpose - and the physician - *medical* purpose).
It is possible the composition gives an empty policy if the composition process does not succeed. When the composition process ends, PrODUCE sends its results to the query engine. If the process does not succeed, the result is FALSE. Otherwise, the produced policy is returned. The query engine then returns FALSE or processes the user query. If the query is possible, the composed policy is attached to the query result and the pl properties are used to specify the concerned resource (the query result as a pl:object).

1 :resultedMedicalPolicy a pl:License ;
2 pl:obligues term:by , term:constraintDerivative ;
3 pl:permits operation:read ;
4 pl:prohibits operation:rename , term:PublicDomainPreserve , term:waiver , term:fairDealing ,
term:otherRightsPreserve , term:holdLiable , operation:using , term:copyrightNotice , term:warranty , oper-
ation:distribute , operation:derivative , term:sa , term:rightsPreserve , operation:copy , term:lesserCopyLeft ,
operation:sharing , term:by , term:unlimitedDisclosure , term:limitedCommercial , term:history , operation:write
, operation:publishing , laterm:moralRightsPreserve , term:freeSourceCode , term:origin , term:notice .
5 :PUC_scenariol a pl:PUC ;
6 pl:permits purpose:medical , purpose:consultation ;
7 pl:prohibits purpose:care , purpose:tracking , purpose:management , purpose:sales , purpose:privateUse , pur-
pose:commercial , purpose:gift , purpose:scientific , purpose:wellbeing .
8 pl:duration "P0Y0M2D" ^ xsd:duration ;
9 pl:grantee <http://serenaseniorcare.com/> ;
10 pl:grantor <Residen1.n3>, <Residen2.n3>, <Residen3.n3> ;
11 pl:hasLicense resultedMedicalPolicy ;
12 pl:object <CompositePersonalData.n3> ;
13 pl:storageLocality <http://dbpedia.org/resource/Mexico> ;
14 pl:usageLocality <http://dbpedia.org/resource/Mexico> ;
15 pl:maxUses 3 .

<caption>a) Scenario 1</caption>

1 :resultedScientificPolicy a pl:License ;
2 pl:obligues term:moralRightsPreserve , term:by , term:notice , term:lesserCopyLeft , term:holdLiable , term:fairDealing , term:origin , term:rightsPreserve , term:PublicDomainPreserve , term:warranty , term:copyrightNotice , term:waiver , term:sa , term:constraintDerivative , term:otherRightsPreserve , term:history , term:freeSourceCode , term:limitedCommercial ;
3 pl:permits operation:publishing , operation:read ;
4 pl:prohibits operation:rename , term:PublicDomainPreserve , term:waiver , term:fairDealing , term:otherRightsPreserve , term:holdLiable , operation:using , term:copyrightNotice , term:warranty , operation:distribute , operation:derivative , term:sa , term:rightsPreserve , operation:copy , term:lesserCopyLeft , operation:sharing , term:by , term:unlimitedDisclosure , term:limitedCommercial , term:history , operation:write , term:moralRightsPreserve , term:freeSourceCode , term:origin , term:notice .
5 :PUC_scenario2 a pl:PUC ;
6 pl:permits purpose:scientific ;
7 pl:prohibits purpose:consultation , purpose:care , purpose:tracking , purpose:management , purpose:sales , purpose:privateUse , purpose:commercial , purpose:gift , purpose:medical , purpose:wellbeing .
8 pl:duration "P0Y0M2D" ^ xsd:duration ;
9 pl:grantee <http://cices.edu.mx/> ;
10 pl:grantor <Residen1.n3>, <Residen2.n3>, <Residen3.n3> ;
11 pl:hasLicense resultedScientificPolicy ;
12 pl:object <CompositePersonalData.n3> ;
13 pl:storageLocality <http://dbpedia.org/resource/Mexico> ;
14 pl:usageLocality <http://dbpedia.org/resource/Mexico> ;
15 pl:maxUses 3 .

<caption>b) Scenario 2</caption>

<caption>Fig. 7. Composite policies of both scenarios.</caption>

4 Related Work

Recently, some works have focused on licenses composition in different contexts.
[1] proposes an approach for licenses composition in the context of service com-
position. Authors extended the ODRL<fnref n="8" /> ontology to represent licenses and use
subsumption rules to determine compatibility between two licenses. If they are
compatible then they are composed in a new one that will govern the composed
service. Models considered are permission, requirement and constraint. In the
composition decisions, they define rules, case by case for unspecified elements.

<footnote n="8">⁸ Open Digital Rights Language.</footnote>
The stance assumed for unspecified elements depends on these rules and cannot be user or context-determined.

[4] proposes a composition of digital licenses in collaborative environments in the context of DRM (Digital Ritgths Management). The goal is to compose digital resources (e-books, audio files, images, etc.) and generate related licenses. Rights associated with the use of resources are taken from the MPEG-21⁹ specification. The set theory is used to define licenses and the composition is based on rights compatibility. Authors consider the usage context by incorporating user profiles and the purpose of use expressed in the compose license request.

<table><caption>**Table 3.** Comparison between approaches found in the literature.</caption><thead><tr><th></th><th>Gangadharan,<br>et al.[1]</th><th>Mesiti,<br>et al.[4]</th><th>Villata,<br>et al.[7, 2, 3]</th><th>PrODUCE</th></tr></thead><tbody><tr><td>Contex</td><td>Web services</td><td>MPEG resources</td><td>Web of data</td><td>Web of data</td></tr><tr><td>Policies<br>representation</td><td>Ontology-based</td><td>Set of grants</td><td>Ontology-based</td><td>Ontology-based</td></tr><tr><td>Models</td><td>Permission,<br>requires,<br>constraints</td><td>-</td><td>Permissions,<br>obligations,<br>prohibitions</td><td>Permits,<br>obliges,<br>prohibits</td></tr><tr><td>Terms</td><td>by scopes: Rights:<br>{adaptation,<br>composition,<br>derivation,<br>attribution,<br>shareAlike,<br>non-commercial},<br>Financial:<br>{peruse,<br>payment}</td><td>by groupes:<br>Use:<br>{play, print,<br>execute},<br>Manage:<br>{install,<br>uninstall, move,<br>delete},<br>Transformation:<br>{reduce,<br>enlarge, modify,<br>diminish, enhance,<br>adapt, embed}</td><td>DerivativeWorks,<br>Sharing,<br>Distribution,<br>Reproduction,<br>Notice, Attribution,<br>ShareAlike,<br>SourceCode,<br>CopyLeft,<br>NonCommercial,<br>Commercial, High-<br>IncomeNationUse</td><td>operations:<br>{read,<br>write, publish,<br>distribuite},<br>terms:<br>{notice, by,<br>sa, waranty,<br>holdliable},<br>purposes:<br>{commercial,<br>private, medical,<br>scientific, care,<br>wellbeing, tracking}</td></tr><tr><td>Composition<br>rules</td><td>Meaning-based</td><td>Group-based</td><td>Deontic logic-based</td><td>Ontology-based</td></tr><tr><td>Unspecified<br>terms</td><td>Rules<br>case by case</td><td>-</td><td>Conservative<br>decision</td><td>Decision based on<br>the data-usage<br>context</td></tr><tr><td>Data-usage<br>context</td><td>No</td><td>Yes</td><td>No</td><td>Yes</td></tr></tbody></table>

[7] proposes a composition mechanism for policies in the web of data. As in our work, they focus on licensing terms of data resulting from a SPARQL query, evaluated on datasets having different licenses. They adopt the CC vocabulary to represent licenses. As in [1], if licenses are compatible then they are combined in a composite license. They have subsumption rules, inspired from [1], to verify licenses compatibility among licenses' elements of permissions, requirements and prohibitions. In the composition process, they use heuristics based on OR-composition, AND-composition, and constraining value. [2, 3], a work close to [7], defines formally AND-composition and OR-composition heuristics in deontic logic. Used elements are permissions, obligations, and prohibitions. They propose the L4lod vocabulary to express licenses in the linked open data.

From these works, only [4] takes into account the context but they do not deal with implicit terms or with a user-defined stance. In our work, we take into

<footnote n="9">⁹ Framework for multimedia applications from Moving Picture Experts Group</footnote>
account usage context, implicit terms and user-defined posture in the composi-
tion decisions. In addition, our subsumption rules are semantics-based because
they depend on the inclusion of relationships expressed in the PriLoo ontology.

Table 3 compares these works based on the policies representation, the models
and terms used, the approach used in the composition, the consideration of
unspecified terms and data usage context.

5 Concluding remarks

PrODUCE, the policies composition process presented in this paper, uses basic
operators and ontology-based rules that consider data usage context.

Implicit terms, based on the usage context, extend usage policies leading
to additional inconsistencies during the composition process. However, most of
these inconsistencies can be eliminated with contextual rules that may incorpo-
rate priorities. This approach is very flexible because, new aspects of data usage
context can be easily included by extending the PriLoo ontology and defining,
accordingly, the set of rules necessary for the composition.

Future works include the definition of rules for other contextual aspects as
the laws of the usage and storage locations of concerned data. Another research
direction is to analyze how to construct a feedback when the policies combination
is not possible and return it to the user, instead of a false result.

**Acknowledgments.** Authors thank to the Mexican National Council for Science and Technology (CONACYT) for partially financing this work.

References

1. Gangadharan, G., Weiss, M., D'Andrea, V., Iannella, R.: Service License Composition and Compatibility Analysis. In: Conference on Service Oriented Computing (ICSOC). Springer (2007)

2. Governatori, G., Lam, H.P., Rotolo, A., Villata, S., Gandon, F.: Heuristics for Licenses Composition. In: Conference on Legal Knowledge and Information Systems (JURIX) (2013)

3. Governatori, G., Rotolo, A., Villata, S., Gandon, F.: One License to Compose Them All. A Deontic Logic Approach to Data Licensing on the Web of Data. In: International Semantic Web Conference (ISWC). Springer (2013)

4. Mesiti, M., Perlasca, P., Valtolina, S.: On the Composition of Digital Licenses in Collaborative Environments. In: Conference on Database and Expert Systems Applications (DEXA). Springer (2013)

5. Serrano-Alvarado, P., Desmontils, E.: Personal Linked Data: a Solution to Manage User's Privacy on the Web. In: Atelier sur la Protection de la Vie Privée (APVP) (2013)

6. Soto-Mendoza, V., García-Macías, J.A., Chávez, E., Martínez-García, A.I., Favela, J., Serrano-Alvarado, P., Zúñiga, M.R.R.: Design of a Predictive Scheduling System to Improve Assisted Living Services for Elders. Transactions on Intelligent Systems and Technology (TIST) 6(4) (2015)

7. Villata, S., Gandon, F.: Licenses Compatibility and Composition in the Web of Data. In: Workshop on Consuming Linked Data (COLD) at ISWC (2012)