=Paper=
{{Paper
|id=Vol-1426/paper-01
|storemode=property
|title=Policies Composition based on Data Usage Context
|pdfUrl=https://ceur-ws.org/Vol-1426/paper-01.pdf
|volume=Vol-1426
|dblpUrl=https://dblp.org/rec/conf/semweb/Soto-MendozaSDG15
}}
==Policies Composition based on Data Usage Context==
https://ceur-ws.org/Vol-1426/paper-01.pdf
Policies Composition Based on Data Usage
Context
Valeria Soto-Mendoza1 , Patricia Serrano-Alvarado2 ,
Emmanuel Desmontils2 , and J. Antonio Garcı́a-Macı́as1
1
CICESE Research Center, Ensenada, Baja California, Mexico
vsoto@cicese.edu.mx, jagm@cicese.mx
2
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 com-
position rules are based on the data usage context and deduce implicit
terms.
Keywords: semantic web, federated query, federated query engine, privacy pol-
icy, 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 seman-
tic 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 Lookout3 (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 prop-
erties 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, his-
tory, notice, etc.). Licenses can also permit or prohibit Operations (read, write,
distribute, etc.).
PUC describes the usage policy under different contextual aspects. It de-
scribes (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, track-
ing, 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 ac-
cording to a hierarchical tree using the inheritance relationship. For instance,
LegalTerm “moral rights preserve” inherits of “rights preserve”, consultation
purpose inherits of medical purpose).4
Several standard licenses have been defined in PriLoo like CC-By or Beer-
ware.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
3
http://privacy-lookout.net/ontologies/2015/06/28/pl-ontology.n3.
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.
5
See http://privacy-lookout.net/ontologies/2015/06/28/pl-licenses.n3 for the list of
standard licenses expressed with PriLoo.
into families, for example CreativeCommons or PublicDomain. These licenses
can be included in PUCs.
xsd:duration xsd:datetime
rdfs:Resource
nd in
pl:duraton
:e g
pl:ob
pl l:be
ject its
rm bits pl:Purpose
p
pe
pl: rohi
p
pl:gran
tor pl:
tee pl:PUC
pl:gran
foaf:Agent pl:ma
lity xUse
oca lity pl:i s
g eL oca mp
lici xsd:positiveInteger
s a e L tPr
pl:u torag op ert
pl:hasLicense
pl:s ies
dbpedia:Place pl:License
pl:ImplicitStatus
pl:obliges
pl:permits
pl:prohibits
pl:prohibits
pl:LegalTerm pl:Operation
Fig. 1. Abstraction of the PriLoo ontology.
Figure 2 shows two examples of privacy policies written in the RDF/N3 syn-
tax. 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 opera-
tion. 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 .
1 :License2 a pl:License ;
2 pl:memberOfTheFamily lic:CreativeCommons ;
3 :PUC elder1 a pl:PUC ;
3 pl:obliges legalTerm:by ;
4 pl:permits purpose:scientific, purpose:medical ;
4 pl:permits operation:write .
5 pl:prohibits purpose:tracking ;
6 pl:object ;
5 :PUC researchCenter1 a pl:PUC ;
7 pl:hasLicense :License1 ;
6 pl:object ;
8 pl:duration ”P0Y0M2D”ˆ ˆ xsd:duration ;
7 pl:hasLicense :License2 ;
9 pl:maxUses ”3”ˆ ˆ xsd:integer ;
8 pl:permits purpose:scientific ;
10 pl:grantee ,
10 pl:duration ”P0Y0M2D”ˆˆxsd:duration ;
,
11 pl:grantee ;
;
12 pl:grantor ;
12 pl:grantor ;
13 pl:usageLocality ;
,
14 pl:storageLocality ;
USA> .
14 pl:storageLocality
;
15 pl:global-preference pl:pessimistic .
a) Policy 1 b) Policy 2
Fig. 2. Two examples of privacy policies.
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).
Resident Resident Resident
Personal endpoint Personal endpoint Personal endpoint
Personal
policies Personal
data
Personal
policies Personal
data
... Personal
policies Personal
data
Query
fo r purp purpose
r
ose Query fo
Federated Query
Manager se Engine Que
rpo r y fo Scientist
fo r pu r pu
ery rpo
Qu se
PrODUCE Priloo
ontology
Physician Caregiver
Fig. 3. Federated query process in a geriatric center.
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 informa-
tion 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 ;
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 ;
12 pl:grantor ;
13 pl:usageLocality ;
14 pl:storageLocality .
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 ;
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 ,
;
12 pl:grantor ;
13 pl:usageLocality , ;
14 pl:storageLocality , .
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 ;
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 ;
12 pl:grantor ;
13 pl:usageLocality ;
14 pl:storageLocality .
c) Policy 5
Fig. 4. Policies for scenarios 1 and 2.
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 pro-
cess. 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.
Fig. 5. Composition process.
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 Jena6 ) 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.
6
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 1. Ontology-based rules considering data usage context.
Ontology-based rules Description
[addTermsFromContext: For a context which contains the purpose
(?up pl:hasLicense ?l), (?up pl:permits term:scientific),
a noValue(?l pl:PolicyProperty term:constraintDerivative) -> “scientific”, this business rule adds to
the licence the obligation of “constraint-
(?l pl:obliges term:constraintDerivative)] Derivative”’.
[addHierachicalPurposes: This propagation rule applies inheritance
b (?up pl:hasLicense ?lic), (?up pl:prohibits ?t),
(?s term:inherits ?t), noValue(?lic ?p ?s) ->
to a term : when a term is prohibited,
all terms more specific are also prohibited
(?up pl:prohibits ?s)] unless this term is already used.
[addImplicitTerms: In this implicit management rule, when
the PUC permits a medical use, all terms
c (?up pl:permits term:medical), ->
noValue(?p pl:implicitProperties ?q) which are not used by the license are pro-
(?up pl:implicitProperties pl:all-but-prohibited)] hibited.
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-oblige 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 ana-
lyzed. 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. 7
1 :License3 a pl:License ;
2 pl:permits operation:distribute , operation:read ;
3 pl:prohibits term:rightsPreserve , term:by , term:rename , operation:publishing ,
term:history , term:origin , operation:unlimitedDisclosure , term:PublicDomainPreserve ,
term:waiver , term:using , term:fairDealing , term:holdLiable , term:lesserCopyLeft , oper-
ation:sharing , term:limitedCommercial , term:moralRightsPreserve , term:copyrightNotice
, term:derivative , operation:copy , term:warranty , operation:write , term:freeSourceCode ,
term:otherRightsPreserve , term:sa , term:notice , term:constraintDerivative .
4 :PUC elder2 a pl:PUC ;
5 pl:begin ”2014-02-03T00:00:00.000+01:00” ;
6 pl:getPurposeFrom :License3 ;
7 pl:global-preference pl:pessimistic ;
8 pl:grantee ;
9 pl:grantor ;
10 pl:hasLicense :License2 ;
11 pl:implicitProperties pl:all-but-permitted-or-obliged , pl:all-but-prohibited ;
12 pl:object ;
13 pl:permits purpose:consultation , purpose:tracking , purpose:medical ;
14 pl:prohibits purpose:scientific , purpose:care , purpose:sales , purpose:privateUse , pur-
pose:commercial , purpose:gift , purpose:wellbeing , purpose:management ;
15 pl:storageLocality ;
16 pl:usageLocality ;
17 pl:duration ”P0Y0M2D”ˆ ˆ xsd:duration ;
18 pl:maxUses 3 .
a) Policy 3 extended, Scenario 1
1 :License5 a pl:License ;
2 pl:obliges term:fairDealing , term:constraintDerivative , term:waiver ,
term:otherRightsPreserve , term:copyrightNotice , term:warranty , term:history ,
term:sa , term:notice , term:holdLiable , term:lesserCopyLeft , term:by , term:origin
, term:PublicDomainPreserve , term:moralRightsPreserve , term:limitedCommercial ,
term:freeSourceCode , term:rightsPreserve ;
3 pl:permits operation:read , term:sharing , operation:rename , operation:distribute , oper-
ation:using , operation:unlimitedDisclosure , operation:derivative , operation:copy , opera-
tion:write , operation:publishing .
4 :PUC elder2 a pl:PUC ;
5 pl:begin ”2014-02-03T00:00:00.000+01:00” ;
6 pl:duration ”P0Y0M2D”ˆ ˆ xsd:duration ;
7 pl:getPurposeFrom :License5 ;
8 pl:global-preference pl:optimistic ;
9 pl:grantee ;
10 pl:grantor ;
11 pl:hasLicense :License3 ;
12 pl:implicitProperties pl:all-but-permitted-or-obliged ;
13 pl:object ;
14 pl:permits purpose:management , purpose:scientific , purpose:tracking , purpose:privateUse
, term:care , term:wellbeing ;
15 pl:prohibits purpose:sales , purpose:commercial , purpose:medical , purpose:gift , pur-
pose:consultation ;
16 pl:storageLocality ;
17 pl:usageLocality ;
18 pl:maxUses 3 .
b) Policy 5 extended, Scenario 2
Fig. 6. Extended policies for both scenarios.
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.
7
Due to lack of space, the resulting policies of the scenarios are not presented.
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 2. Operators used for policies composition.
Model Operator Description
Permits AND A term is permitted if it appears in all policies.
Prohibits
OR A term is prohibited/obligated if it appears in at least in one policy.
Obliges
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 pro-
cess 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 re-
turns 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 scenario1 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 ;
10 pl:grantor , , ;
11 pl:hasLicense resultedMedicalPolicy ;
12 pl:object ;
13 pl:storageLocality ;
14 pl:usageLocality ;
15 pl:maxUses 3 .
a) Scenario 1
1 :resultedScientificPolicy a pl:License ;
2 pl:obliges 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 , 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
, 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 ;
10 pl:grantor , , ;
11 pl:hasLicense resultedScientificPolicy ;
12 pl:object ;
13 pl:storageLocality ;
14 pl:usageLocality ;
15 pl:maxUses 3 .
b) Scenario 2
Fig. 7. Composite policies of both scenarios.
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 ODRL8 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.
8
Open Digital Rights Language.
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-219 speci-
fication. 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 3. Comparison between approaches found in the literature.
Gangadharan, Mesiti, Villata,
PrODUCE
et al.[1] et al.[4] et al.[7]
Contex Web services MPEG resources Web of data Web of data
Policies
Ontology-based Set of grants Ontology-based Ontology-based
representation
Permission, Permissions, Permits,
Models requires, - obligations, obliges,
constraints prohibitions prohibits
by groupes: DerivativeWorks, operations:{read,
by scopes: Rights: Sharing,
Use:{play, print, write, publish,
{adaptation, Distribution,
execute}, distribuite},
composition, Reproduction,
Manage:{install, terms:{notice, by,
derivation, Notice, Attribution,
uninstall, move, sa, waranty,
Terms attribution, ShareAlike,
delete}, Transfor- holdliable}, pur-
shareAlike, SourceCode,
mation:{reduce, poses:{commercial,
non-commercial}, CopyLeft,
enlarge, modify, private, medical,
Finantial:{peruse, NonCommercial,
diminish, enhance, scientific, care,
payment} Commercial, High- wellbeing, tracking}
adapt, embed}
IncomeNationUse
Composition
Meaning-based Group-based Deontic logic-based Ontology-based
rules
Rules Decision based on
Unspecified Conservative
- the data-usage
terms case by case decision
context
Data-usage
No Yes No Yes
context
[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 com-
bined in a composite license. They have subsumption rules, inspired from [1],
to verify licenses compatibility among licenses’ elements of permissions, require-
ments 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 de-
ontic 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
9
Framework for multimedia applications from Moving Picture Experts Group
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 Compo-
sition 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 Li-
censes 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. In: Workshop on the Semantic Web at 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 Ap-
plications (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)