Licenses Compatibility and Composition
in the Web of Data
Serena Villata? and Fabien Gandon
INRIA Sophia Antipolis, France
{firstname.lastname}@inria.fr
Abstract. The absence of clarity concerning the licensing terms does
not encourage the reuse of the data by the consumers, thus preventing
further publication and consumption of datasets, at the expense of the
growth of the Web of Data itself. In this paper, we propose a general
framework to attach the licensing terms to the data queried on the Web
of Data. In particular, our framework addresses the following issues: (i)
the various license schemas are collected and aligned taking as reference
the Creative Commons schema, (ii) the compatibility of the licensing
terms concerning the data affected by the query is verified, and (iii)
if compatible, the licenses are combined into a composite license. The
framework returns the composite license as licensing term about the
data resulting from the query.
1 Introduction
Heath and Bizer [5] underline that “the absence of clarity for data consumers
about the terms under which they can reuse a particular dataset, and the absence
of common guidelines for data licensing, are likely to hinder use and reuse of
data”. Therefore, all Linked Data on the Web should include explicit licensing
terms, or waiver statements [8]. Data consumers need to know the licenses on
the data to avoid misusing and even illegal reuse of the data. Following these
highlights, several machine-readable licensing terms have been proposed, leading
to a huge amount of unrelated but comparable ways of expressing the licenses.
The scenario we consider in this paper is visualized in Figure 1. When consumers
query the Web of Data, results from different datasets, and thus released under
different licensing terms, are provided. Our objective is to build a composite
license which combines the elements from the distinct licenses associated to the
selected data. The research questions we answer in this paper are: (1) How to
verify the compatibility among the licensing terms associated to a query result?,
and (2) How to compose, if compatible, the distinct licensing terms for creating
a composite license?
We answer the research questions by adopting Semantic Web languages only,
and reusing the Creative Commons (CC) licenses schema [1]. In particular,
we choose the CC vocabulary to define the anatomy of our licenses. Licenses
?
The author acknowledges the support of the DataLift Project ANR-10-CORD-09.
LICENSES COMPATIBILITY
AND COMPOSITION MODULE
LICENSES
SELECTION
CLIENT QUERY CLIENT QUERY
COMPATIBILITY
SELECT... EVALUATION
WHERE{...} QUERY RESULT
GENERATION
COMPOSITE
LICENSE
QUERY RESULT +
Fig. 1. The architecture of the license compatibility and composition framework.
are composed by models (cc:Permission, cc:Requirement, cc:Prohibition)
which specify the permissions allowed by the license, the required behaviors and
the prohibited use and reuse of the data. The models are composed by elements
like ShareAlike, Attribution, and many others, which specify the precise per-
missions, requirements, and prohibitions associated to the license. We choose this
vocabulary because it provides a general schema for licenses specification. We are
aware that there are works which cannot be considered as creative works [8, 5].
For addressing this issue and covering a wider range of machine-readable license
specifications, we align CC with the other schemas representing licenses.
The set of licenses is evaluated as compatible if a number of compatibil-
ity rules are satisfied. These rules specify the subsumption relations among the
licenses’ elements and evaluate the compatibility among Permissions, Require-
ments and Prohibitions elements. If the pre-requisite of licenses compatibility is
satisfied, the licenses are composed. We propose rules to deal with the compo-
sition of the licenses whose elements subsume other elements, and of the con-
straints expressed by the licenses. We define some basic heuristics to address the
composition. Using these heuristics, the Composite License Generation algorithm
returns the composite license. This license will be the only license attached to the
data returned by the query. The composite license is retuned together with the
query result using the standard SPARQL query results XML format by means
of the 1 element.
In this paper, we do not introduce yet another licensing schema. We con-
sider RDF machine-readable license specifications only, and we do not consider
MPEG-212 . Moreover, we do not provide verification compliance about the reuse
of the data by the consumer. We extend and adapt existing proposals for licenses
compatibility and composition in the area of service license analysis [4] to the
Web of Data scenario.
The reminder of the paper is as follows: Section 2 compares the existing
literature with the proposed approach. Section 3 formalizes the licenses structure
and presents the alignment with the other vocabularies. Section 4 defines the
compatibility rules and the evaluation algorithm, and Section 5 shows how the
licenses are composed.
1
http://www.w3.org/TR/rdf-sparql-XMLres/#head
2
http://mpeg.chiariglione.org/standards/mpeg-21/mpeg-21.htm
2 Related work
The Creative Commons Rights Expression Language (ccREL) [1] is the standard
recommended by Creative Commons for machine-readable expression of copy-
right licensing terms and related information. Miller et al. [8] propose the Open
Data Commons waivers and licenses3 that try to eliminate or fully license any
rights that cover databases and data. The Waiver vocabulary4 defines properties
to use when describing waivers of rights over data and content where a waiver is
the voluntary relinquishment or surrender of some known right or privilege. Ian-
nella [6] presents the Open Digital Rights Language (ODRL), a language for the
Digital Rights Management community for expressing rights information over
content. The ODRL-S language 5 extends ODRL by implementing the clauses
of service licensing. Gangadharan et al. [4, 3] address the issue of service license
composition and compatibility analysis. They specify a matchmaking algorithm
which verifies whether two service licenses are compatible. In case of a positive
answer, the services are composed and the framework determines the license of
the composite service. Even if the Compatibility Evaluation algorithm we pro-
pose follows the basic steps of [4, 3], there are several differences between the two
approaches. The application scenarios are different (service composition vs Web
of Data) and this opens different problems. In particular, the subsumption and
compatibility rules we define are different, and this affects also the algorithm
definition. The composite license mirrors the same differences. Truong et al. [9]
address the issue of analyzing data contracts which leads to the definition of
a contract composition where first the comparable contractual terms from the
different data contracts are retrieved, and second an evaluation of the new con-
tractual terms for the data mashup is addressed. This work concentrates on data
contracts and not on data licenses. However, there are also some common points
like the use of RDF for the representation of data licenses/contracts. Krotzsch
and Speiser [7] present a semantic framework for evaluating ShareAlike recursive
statements, developing a general policy modelling language for supporting self-
referential policies as expressed by CC. We address another kind of problem that
is the composition of the licenses constraining the data into a unique composite
license.
3 Creative Commons licensing language
The Creative Commons licenses are a family of license models for publishing
resources on the Web, enabling the reuse of the data instead of the forbidden by
default approach of traditional copyright specifications. The basic anatomy of
such licenses6 is composed by a Work which is a potentially copyrightable work,
a License that is a set of permissions/requirements/prohibitions to the users of
a Work, and a Jurisdiction that is the legal jurisdiction of a license.
3
http://opendatacommons.org/licenses/
4
http://vocab.org/waiver/terms/.html
5
http://odrl.net/Profiles/Services/WD-20080402.html
6
http://creativecommons.org/ns
License L
0...n
Model
0...n
Permissions Requirements Prohibitions
Reproduction Notice Commercial Use
Element 0...n Distribution Attribution High Income Nation Use
Derivative Works Share Alike
0...n Sharing Source Code
Copyleft
Element
Value (a) (b)
Fig. 2. The basic structure of our licenses (a), and the CC models and elements (b).
Figure 2.a shows the structure of a license in our framework. This structure is
as desired general enough to include possible extensions to the CC vocabulary.
Each license L is composed by a set of models. In particular, the models are
cc:Permission, cc:Requirement, and cc:Prohibition, and express the kind
of actions respectively permitted, required and prohibited on the data.
Figure 2.b shows the set of elements associated to each model in CC. Our
general model of licenses takes into account for generality purposes also the
possible values assigned to the elements.
Definition 1. A license L(R) for a named graph R is a finite set of models m,
each of which further consists of a set of elements el.
A huge amount of vocabularies includes properties and classes about the
licensing terms for data reuse. In order to achieve interoperability, we align
the CC vocabulary with these vocabularies, in some cases very heterogeneous,
including licensing terms. A summarization of the alignment about licensing
terms7 is visualized in Figure 3. Note that in the CC vocabulary it holds that
cc:license subPropertyOf dcterms:license, and cc:License subClassOf
dcterms:LicenseDocument. The alignment considers the following vocabularies:
the Description of a Project vocabulary (doap)8 , the Ontology Metadata vocab-
ulary (omv)9 , the Data Dictionary for Preservation Metadata (premis)10 , the
Vocabulary Of Attribution and Governance (voag)11 , the NEPOMUK Informa-
7
The research of the vocabularies including licensing terms has been addressed using
the LOV dataset (available at http://labs.mondeca.com/dataset/lov/).
8
http://usefulinc.com/ns/doap
9
http://omv2.sourceforge.net/index.html
10
http://bit.ly/MVTZkr
11
http://voag.linkedmodel.org/schema/voag
tion Element Ontology (nie)12 , the Music Ontology (mo)13 , the Good Relations
vocabulary (gr)14 , and the myExperiment Base Ontology (meb)15 .
omv:hasLicense omv:LicenseModel
doap:license gr:License
premis:licenseTerms premis:LicenseInformation
subPropertyOf cc:license subClassOf cc:License
voag:hasLicenseType voag:LicenseModel
nie:license vivo:License
mo:license meb:License
Fig. 3. Alignment between the CC vocabulary and other vocabularies.
4 Licenses compatibility analysis
For providing a definition of the Compatibility Evaluation algorithm, we need to
define a set of compatibility rules assessing the possible compatibility among the
elements composing the licenses, following [4] for service licenses. First, there are
certain elements which are broader in scope of permission than other elements.
Consider the following example where two named graphs16 R1 and R2 respec-
tively are associated to different licenses where the elements are cc:Reproduction
and cc:Sharing. The consumer’s query returns triples from both R1 and R2 ,
thus the compatibility between the two licenses has to be verified. Reproduction
permits making multiple copies, and Sharing permits commercial derivatives [1].
In our model these two licenses are evaluated as compatible because cc:Sharing
subsumes cc:Reproduction. In this context, subsumption means that there is
a compatibility if a certain element eli is more permissive, i.e., it accepts more,
than the other element elj . For instance, we have that cc:Sharing is more
permissive than cc:Reproduction where only multiple copies are allowed but
no commercial derivatives. The way the two licenses then are combined into
the composite license Lc depends on the redefinition rule applied by the data
provider (Section 5). The subsumption rules for the cc:Permission elements
are shown in Table 1.
Table 2.a shows whether an element el1 is compatible with another element
el2 , i.e., el1 el2 , for cc:Permission elements. Rules are expressed under the
form of truth tables where elements are evaluated as compatible T , or incom-
patible F . The rationale behind Table 2.a is that the elements are compati-
ble if there is a subsumption relation between them. Thus, the only case in
which the compatibility does not hold is when the elements are cc:Sharing and
12
http://www.semanticdesktop.org/ontologies/2007/01/19/nie/
13
http://purl.org/ontology/mo/
14
http://purl.org/goodrelations/v1
15
http://rdf.myexperiment.org/ontologies/base/
16
The discussion about the use of named graphs in RDF 1.1 can be found at
http://www.w3.org/TR/rdf11-concepts
Subsumption More permissive Less permissive
DerivativeW orks Sharing DerivativeW orks Sharing
Distribution Reproduction Distribution Reproduction
DerivativeW orks Reproduction DerivativeW orks Reproduction
Sharing Reproduction Sharing Reproduction
DerivativeW orks Distribution DerivativeW orks Distribution
Table 1. Compatibility rules for subsumption relation for cc:Permission elements.
cc:Distribution where no subsumption relation is present because cc:Sharing
allows for non-commercial distribution only, while cc:Distribution allows com-
mercial distribution as well. Note that compatibility in our rules is bi-directional,
where (el1 compatible with el2 ) is equivalent to (el2 compatible with el1 )17 .
As in [4], a possible situation which may arise is that one license speci-
fies clauses which are not specified by the other license, e.g., one license spec-
ifies cc:Prohibition and the other license does not specify this clause. Ta-
ble 2.b shows the compatibility rules for cc:Requirement, cc:Prohibition and
cc:Permission elements against Unspecified elements18 . Concerning
cc:Requirement, the requirement for specification of Attribution does not affect
the compatibility with Unspecified (the same holds for Notice, SourceCode, and
CopyLeft), and ShareAlike affects the composite license Lc by requiring that Lc
is similar to the original license. Concerning cc:Prohibition, these elements
are incompatible with Unspecified. For instance, commercial use is the default
setting of the licenses, thus we cannot assume compatibility if commercial use is
denied by NonCommercial19 . The same holds for the cc:HighIncomeNationUse
element. Concerning cc:Permission, we follow the “conservative” approach in
handling Unspecified elements where unspecification means a denial of compat-
ibility [3].
Finally, the Compatibility Evaluation algorithm has to verify whether and
how cc:Requirement elements and cc:Prohibition elements are compatible
due to the constraints they specify. Assume two licenses L1 and L2 where L1
contains a clause specifying the requirement for cc:Attribution and L2 con-
tains a clause specifying the prohibition cc:CommercialUse. Are these clauses
compatible? The answer is that, despite Table 2.b, they are compatible as far
as the composition of the two licenses includes both the elements, i.e., it satis-
fies both the cc:CommercialUse clause and the cc:Attribution clause. This
means that these license sets are non-disjoint. Table 3 shows the compatibility
rules applied to the requirements cc:Attribution and cc:ShareAlike and the
17
Differently from software compatibility, it is not a matter of having the same element
changed in different versions, but to have different elements to be compared, e.g.,
Sharing and Reproduction.
18
We interpret unspecified elements as “do not care”, as in [4].
19
Note that in this section we refer to the element cc:CommercialUse as NonCommer-
cial for keeping clear that it is a prohibition.
el1 el2 el1 el2
N otice U nspecif ied T
Attribution U nspecif ied T
el1 el2 el1 el2
ShareAlike U nspecif ied T
Sharing DerivativeW orks T
SourceCode U nspecif ied T
Reproduction Distribution T
CopyLef t U nspecif ied T
Reproduction DerivativeW orks T
N onCommercial U nspecif ied F
Reproduction Sharing T
HighIncomeN ationU se U nspecif ied F
Distribution DerivativeW orks T
Reproduction U nspecif ied F
Sharing Distribution F
Distribution U nspecif ied F
DerivativeW orks U nspecif ied F
Sharing U nspecif ied F
Table 2. (a) Compatibility rules among cc:Permission elements, (b) Compatibility
rules among cc:Requirement, cc:Prohibition and cc:Permission elements against
Unspecified.
cc:CommercialUse prohibition where, with a slight abuse of notation, we write
L1 L2 = el1 ∧ el2 to indicate that the composition of the licenses will include
both the elements.
el1 el2 el1 el2 L1 L2
Attribution ShareAlike T el1 ∧ el2
Attribution N onCommercial T el1 ∧ el2
ShareAlike N onCommercial T el1 ∧ el2
Table 3. Compatibility rules among cc:Requirement and cc:Prohibition elements.
The rules detailed in Tables 1-3 provide the basic components of our Com-
patibility Evaluation algorithm. Let L(C) = {L1 (R1 ), . . . , Ln (Rn )} be the set
of licenses associated to the n named graphs affected by the consumer’s query
where Li (Ri ) is the license associated with named graph Ri , then our objective is
to compose these licenses into the composite license Lc . Definition 2 defines that
two licenses are compatible if for all their clauses li , these clauses are compatible.
Definition 2. A license Li is compatible with another license Lj , Li Lj , if
∀li=1,...,n ∈ Li , ∀lj=1,...,m ∈ Lj it holds that li lj .
The Compatibility Evaluation algorithm (Figure 4) compares the clauses of
the licenses to be composed. Two licenses are compatible if the models in both
the licenses are compatible20 . The models are compatible if (i) the models are
the same (mi ≡ mj ), (ii) the models are composed by elements which satisfy
20
In this paper, we do not consider the presence of sub-elements and of numerical
values assigned to the elements, e.g., financial use, however the algorithm can easily
be extended for treating these cases as well.
Algorithm 1: LicensesCompatibility
Input: Licenses Li , Lj
Output: true if Li Lj , false otherwise
if ∀mi : mi ∈ Li , ∃mj : mj ∈ Lj ← ModelsCompatibility(mi , mj ) = true ∧
∀mj : mj ∈ Lj , ∃mi : mi ∈ Li ← ModelsCompatibility(mi , mj ) = true then
compatible = true;
else
compatible = f alse;
return compatible;
Algorithm 2: ModelsCompatibility
Input: Models mi , mj
Output: true if mi mj , false otherwise
if ((mi ≡ mj ) ∨ IntersectionRules(mi , mj ))∧
∀eli : eli ∈ mi , ∃elj : elj ∈ mj ← ElementsCompatibility(eli , elj ) = true ∧
∀elj : elj ∈ mj , ∃eli : eli ∈ mi ← ElementsCompatibility(eli , elj ) = true then
compatible = true;
else
compatible = f alse;
return compatible;
Algorithm 3: ElementsCompatibility
Input: Elements eli , elj
Output: true if eli elj , false otherwise
if ((eli ≡ elj )
∨SubsumptionRules(eli , elj ) ∨ UnspecifiedRules(eli , elj ) ∨ IntersectionRules(eli , elj ))∧
∀eli : eli ∈ mi , ∃elj : elj ∈ mj ← ElementsCompatibility(eli , elj ) = true ∧
∀elj : elj ∈ mj , ∃eli : eli ∈ mi ← ElementsCompatibility(eli , elj ) = true then
compatible = true;
else
compatible = f alse;
return compatible;
Fig. 4. The compatibility evaluation procedure.
the compatibility rules (Table 3), and (iii) their elements are compatible. The
elements compatibility is checked with respect to the following features: (i) the
elements are the same (eli ≡ elj ), (ii) the elements satisfy the subsumption rules
(Table 1) (SubsumptionRules(eli , elj )), (iii) the elements satisfy the compatibil-
ity rules against Unspecified (Table 2.b) (UnspecifiedRules(eli , elj )), (iv) the
elements satisfy the compatibility rules (Table 3) (IntersectionRules(eli , elj )),
and (v) all the nested elements (if any) are compatible.
Example 1. Assume we want to analyze two licenses L1 and L2 , visualized in
Figure 5. Following our algorithm, we first compare the two licenses at the model
level. Both licenses contain the model cc:Permission, and both of them per-
mit cc:Reproduction. As the models are of the same type and the elements
are of the same type as well, then the compatibility is verified. License L1 con-
tains the model cc:Requirement with the element cc:Notice. This model is
not specified by license L2 , but following the compatibility rules of Table 2.b,
the algorithm evaluates that the element cc:Notice is compatible with an Un-
specified element. Compatibility is maintained. Finally, the algorithm evaluates
the model cc:Prohibition of L2 , looking for the same model and the same
@prefix cc: http://creativecommons.org/ns. @prefix cc: http://creativecommons.org/ns.
@prefix : http://example/licenses. @prefix : http://example/licenses.
:lic1 a cc:License; THE ELEMENTS :lic2 a cc:License; THE ELEMENTS
cc:permits cc:Reproduction; cc:permits cc:Reproduction;
cc:requires cc:Notice. cc:prohibits cc:CommercialUse.
THE MODELS: THE MODELS:
- Permission - Permission
- Requirement - Prohibition
(a) (b)
Fig. 5. An example of compatibility evaluation which leads to a false result.
element (cc:CommercialUse) in license L1 . The model cc:Prohibition is not
specified in L1 . From Table 2.b, the algorithm evaluates cc:CommercialUse and
Unspecified incompatible. The compatibility evaluation of the licenses leads to
a false answer.
The following properties hold for the license compatibility relation we define.
Property 1 (Symmetry). Let Li , Lj be two compatible licenses, then ∀li ∈ Li , ∀lj ∈
Lj it holds that if li lj then lj li .
The proof follows from the definition of the Compatibility Evaluation algo-
rithm and the composition rules. The symmetry property ensures that
Li Lj ≡ Lj Li .
Property 2 (Associativity). Let Li , Lj , Lk be three licenses then it holds that
(Li Lj ) Lk = Li (Lj Lk ).
Proof. (Associativity ⇒) Let the clause l ∈ (Li Lj ) Lk , then either l ∈
(Li Lj ) or l ∈ Lk (or both). This means that either l ∈ Li , or l ∈ Lj , or
l ∈ Lk . Thus l ∈ Li or l ∈ (Lj Lk ). This means that l ∈ Li (Lj Lk ) where
(Li Lj ) Lk ⊂ Li (Lj Lk ).
(Associativity ⇐) Let the clause l ∈ Li (Lj Lk ), then either l ∈ Li or
l ∈ (Lj ) Lk ) (or both). This means that either l ∈ Li , or l ∈ Lj , or l ∈ Lk .
Thus l ∈ (Li Lj ) or l ∈ Lk . This means that l ∈ (Li Lj ) Lk where
Li (Lj Lk ) ⊂ (Li Lj ) Lk .
5 Licenses Composition
The result of the Compatibility Evaluation algorithm is an answer of the kind
true/false. If the answer is false, then the licenses considered for composition
are not compatible. In this case, we leave to the data provider to decide the
strategy to deal with this situation: (i) the data queried by the consumer is
returned without attaching any license, (ii) the data is returned together with
the more constraining license among L(C), and (iii) the data is returned together
with the less constraining license among L(C).
If the licenses, instead, are compatible then we compose the licenses in L(C)
such that the resulting composite license Lc satisfies the licensing clauses speci-
fied by the licenses in L(C). In particular, the definition of the composite license
satisfies the following properties, where is the composition relation. First, the
composite license Lc can be generated only if all the licenses composing it are
compatible (Section 4).
Property 3. Let L1 , . . . , Ln be n licenses to be composed in a composite license
Lc . If it holds that L1 L2 . . . Ln , then Lc = L1 . . . Ln .
Second, the composite license, if allowed, is consistent with the set of licenses
used to compose it, due to the Compatibility Evaluation module.
Property 4. Let L1 (R1 ), . . . , Ln (Rn ) be the licenses associated to named graphs
R1 , . . . , Rn . The composite license Lc for R1 , . . . , Rn is consistent with
L1 (R1 ), . . . , Ln (Rn ).
We now define the algorithm which generates Lc from the set of compatible
licenses. The first step consists in providing the redefinition rules the algorithm
applies in case a subsumption relation holds among these license elements. Ta-
ble 1 shows the redefinition rules given the subsumption relation among the
elements. We identify two kinds of redefinition: a redefinition where the more
permissive element is included in Lc , and another redefinition which follows the
converse. The second step consists in detailing the composition which results
from the rules expressed in Table 3. The composition of these license elements
is achieved by assigning both these elements to the composite license Lc . These
rules are necessary to keep the consistency of Lc w.r.t. the licenses composing
it. These rules overcome the compatibility rules against Unspecified, and the
heuristics which guide the composition. This leads to the generation of some
popular licensing terms: Attribution-ShareAlike, Attribution-NonCommercial,
and ShareAlike-NonCommercial, namely. This is a minimum set of composed
licenses. However, other composition rules can be defined, depending on the
requirements of the data provider.
The algorithm for Composite License Generation is listed in Figure 6. The
pre-requisite for license composability is that the licenses in L(C) are compatible
with each others. If so, L(C) are composed as follows: the
ElementsSelectionHeuristic procedure adopts the heuristic h to combine the
elements of each license together in a single license Lc .
Algorithm 4: Composite License Generation Algorithm
Input: Compatible Licenses L1 , . . . , Ln
Output: Composite license Lc
Lc ← ElementsSelectionHeuristich (L(C));
return Lc ;
Fig. 6. The procedure for generating the composite license.
The three basic heuristics we consider in our framework are the following [2]:
OR-composition : If there is at least one of the licenses involved in the com-
position that owns a clause then also the composite license owns it;
AND-composition : if all the licenses involved in the composition own a clause
then also the composite license owns it;
Constraining-value : the most constraining clause among the ones offered by
the licenses is included in the composite license.
In this paper, we do not argue in favor or against these three possibilities, and
a qualitative evaluation of the best composition heuristics is left as future work.
We leave to the data provider the choice of her best strategy for composing the
licenses, e.g., AND-composition typically leads to a shorter and simpler license,
while OR-decomposition leads to a more complex license where all the clauses
present in L(C) are included.
@prefix cc: http://creativecommons.org/ns.
@prefix : http://example/licenses. @prefix cc: http://creativecommons.org/ns.
@prefix : http://example/licenses.
:lic1 a cc:License;
cc:permits cc:Reproduction; :licComposite a cc:License; THE ELEMENTS
cc:requires cc:ShareAlike. cc:permits cc:DerivativeWorks;
(a) cc:requires cc:ShareAlike;
cc:prohibits cc:CommercialUse.
@prefix cc: http://creativecommons.org/ns.
@prefix : http://example/licenses. THE MODELS:
- Permission
:lic2 a cc:License; - Requirement
cc:permits cc:DerivativeWorks; - Prohibition
cc:prohibits cc:CommercialUse.
(b) (c)
Fig. 7. Compatibility evaluation and composition which leads to a true result.
Example 2. Assume we want to analyze two licenses L1 and L2 , visualized
in Figure 7.a-b. Following our Compatibility Evaluation algorithm, we first
compare the two licenses at the model level. Both licenses contain the model
cc:Permission, the first element is cc:Reproduction, and the second element is
cc:DerivativeWorks. Even if the two elements are not the same, we know from
Table 1 that there is a subsumption relation between the element cc:Reproduc-
tion and cc:DerivativeWorks. This means that we can redefine one element as
the other element when we build the composite license. The first license does not
contain the model cc:Prohibition and the second license does not contain the
model cc:Requirement. However, the two respective elements cc:ShareAlike
and cc:CommercialUse are compatible due to Table 3, and then the two li-
censes are compatible. Thus composition is allowed, following Table 3 and the
composition rules defined above. Lc is obtained using the more permissive per-
mission (Table 1), and the OR-composition heuristic (Figure 7.c). Lc permits
cc:DerivativeWorks (from the redefinition rules of Table 1), requires
cc:ShareAlike, and prohibits cc:CommercialUse.
6 Conclusions
In this paper, we present a framework to associate licensing terms to the data on
the Web of Data. The result of the consumer’s query is not only the requested
data but also its licensing terms. We adopt the CC licenses vocabulary because
it provides a general schema for data licensing, and we align it with the other
vocabularies including license specifications. First, we verify the compatibility
among the licenses associated to the various named graphs affected by the con-
sumer’s query. Second, given the compatibility among the composed licenses, we
construct Lc which aggregates the clauses of the distinct licenses following the
heuristics we propose. The composite license is finally returned to the consumer
together with the requested data.
The first point to be addressed is a legal and social validation of the pro-
posed framework, answering research questions like “Can data be licensed at
all depending on the jurisdiction?” and “Can non CC licenses be related to CC
licenses in a legally correct way to extend the framework to non CC licenses
and waivers?”. This means to evaluate, not only quantitatively the performance
of the algorithms to retrieve remote licensing statements referenced in the data,
but also the legal value of the composite license. We will address an evaluation of
the disparate named graphs that might be used in a “typical” query, and their
relative proportions that have compatible or incompatible licenses. Moreover,
we plan to integrate our framework with the W3C provenance working group’s
activities21 . Finally, we are defining more complex heuristics like the one looking
for the minimal composite license.
References
1. H. Abelson, B. Adida, M. Linksvayer, and N. Yergler. ccREL: The Creative Com-
mons Rights Expression Language, 2008.
2. M. Comerio. Web Service Contracts: Specification, Selection and Composition. PhD
thesis, University of Milano-Bicocca, 2009.
3. G. R. Gangadharan, H. L. Truong, M. Treiber, V. D’Andrea, S. Dustdar, R. Iannella,
and M. Weiss. Consumer-specified service license selection and composition. In
ICCBSS, IEEE, pages 194–203, 2008.
4. G. R. Gangadharan, M. Weiss, V. D’Andrea, and R. Iannella. Service license com-
position and compatibility analysis. In ICSOC, LNCS 4749, pages 257–269, 2007.
5. T. Heath and C. Bizer. Linked Data: Evolving the Web into a Global Data Space.
Morgan & Claypool, 2011.
6. R. Iannella. Open Digital Rights Language (ODRL), 2002.
7. M. Krötzsch and S. Speiser. Sharealike your data: Self-referential usage policies for
the semantic web. In ISWC, LNCS 7031, pages 354–369, 2011.
8. P. Miller, R. Styles, and T. Heath. Open data commons, a license for open data. In
LDOW, 2008.
9. H. L. Truong, G. R. Gangadharan, M. Comerio, S. Dustdar, and F. De Paoli. On
analyzing and developing data contracts in cloud-based data marketplaces. In AP-
SCC, IEEE, pages 174–181, 2011.
21
http://www.w3.org/2011/prov/