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 a ected by the query is veri ed, 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.
Heath and Bizer [
We answer the research questions by adopting Semantic Web languages only,
and reusing the Creative Commons (CC) licenses schema [
CLIENT QUERY SELECT...
WHERE{...}
QUERY RESULT +
<link URI-Lc>
COMPATIBILITY
EVALUATION
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
permissions, requirements, and prohibitions associated to the license. We choose this
vocabulary because it provides a general schema for licenses speci cation. We are
aware that there are works which cannot be considered as creative works [
The set of licenses is evaluated as compatible if a number of compatibility rules are satis ed. These rules specify the subsumption relations among the licenses' elements and evaluate the compatibility among Permissions, Requirements and Prohibitions elements. If the pre-requisite of licenses compatibility is satis ed, the licenses are composed. We propose rules to deal with the composition of the licenses whose elements subsume other elements, and of the constraints expressed by the licenses. We de ne 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 <link>1 element.
In this paper, we do not introduce yet another licensing schema. We
consider RDF machine-readable license speci cations only, and we do not consider
MPEG-212. Moreover, we do not provide veri cation 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 [
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 de nes the compatibility rules and the evaluation algorithm, and Section 5 shows how the licenses are composed.
The Creative Commons Rights Expression Language (ccREL) [
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 speci cations. 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.
License L 0...n 0...n Model Element
0...n Element Value 0...n (a)
Permissions Reproduction
Distribution Derivative Works
Sharing
Requirements
Notice Attribution Share Alike Source Code
Copyleft (b)
Prohibitions
Commercial Use High Income Nation Use
De nition 1. A license L(R) for a named graph R is a nite 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 vocabulary (omv)9, the Data Dictionary for Preservation Metadata (premis)10, the Vocabulary Of Attribution and Governance (voag)11, the NEPOMUK Informa7 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 pvroeamgi:sh:alsiLciecnesnesTeeTrympse subPropertyOf cc:license pvroeamgi:sL:iLciecnesnesMeoIdneflormation subClassOf cc:License nie:license vivo:License mo:license meb:License
For providing a de nition of the Compatibility Evaluation algorithm, we need to
de ne a set of compatibility rules assessing the possible compatibility among the
elements composing the licenses, following [
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 incompatible F . The rationale behind Table 2.a is that the elements are compatible 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 cc:Distribution where no subsumption relation is present because cc:Sharing allows for non-commercial distribution only, while cc:Distribution allows commercial 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 [
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
contains 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
satises 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 Di erently from software compatibility, it is not a matter of having the same element
changed in di erent versions, but to have di erent elements to be compared, e.g.,
Sharing and Reproduction.
18 We interpret unspeci ed elements as \do not care", as in [
el1 el2
Sharing DerivativeW orks Reproduction Distribution Reproduction DerivativeW orks Reproduction Sharing Distribution DerivativeW orks
Sharing Distribution el1
el2 T T T T T F
el1 el2
Notice Unspecified Attribution Unspecified ShareAlike Unspecified SourceCode Unspecified
CopyLeft Unspecified
NonCommercial Unspecified HighIncomeNationUse Unspecified
Reproduction Unspecified
Distribution Unspecified DerivativeW orks Unspecified
Sharing Unspecified T T T T T F F F F F F 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 Attribution ShareAlike Attribution N onCommercial ShareAlike N onCommercial el1
T T T el2 L1 L2 el1 ^ el2 el1 ^ el2 el1 ^ el2
The rules detailed in Tables 1-3 provide the basic components of our Compatibility Evaluation algorithm. Let L(C) = fL1(R1); : : : ; Ln(Rn)g be the set of licenses associated to the n named graphs a ected 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. De nition 2 de nes that two licenses are compatible if for all their clauses li, these clauses are compatible. De nition 2. A license Li is compatible with another license Lj , Li 8li=1;:::;n 2 Li; 8lj=1;:::;m 2 Lj it holds that li lj .
Lj , if
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., nancial use, however the algorithm can easily be extended for treating these cases as well.
Input: Licenses Li, Lj Output: true if Li Lj , false otherwise if 8mi : mi 2 Li; 9mj : mj 2 Lj ModelsCompatibility(mi; mj ) = true ^ 8mj : mj 2 Lj ; 9mi : mi 2 Li ModelsCompatibility(mi; mj ) = true then compatible = true; else
compatible = f alse; return compatible;
Input: Models mi, mj Output: true if mi mj , false otherwise if ((mi mj ) _ IntersectionRules(mi; mj ))^ 8eli : eli 2 mi; 9elj : elj 2 mj ElementsCompatibility(eli; elj ) = true ^ 8elj c:oemljp2atmiblje; 9=eltiru:ee;li 2 mi ElementsCompatibility(eli; elj ) = true then else
compatible = f alse; return compatible; else
compatible = f alse; return compatible;
Input: Elements eli, elj Output: true if eli elj , false otherwise if ((eli elj ) _SubsumptionRules(eli; elj ) _ UnspecifiedRules(eli; elj ) _ IntersectionRules(eli; elj ))^ 8eli : eli 2 mi; 9elj : elj 2 mj ElementsCompatibility(eli; elj ) = true ^ 8elj c:oemljp2atmiblje; 9=eltiru:ee;li 2 mi ElementsCompatibility(eli; elj ) = true then 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 compatibility rules against Unspeci ed (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 rst compare the two licenses at the model level. Both licenses contain the model cc:Permission, and both of them permit cc:Reproduction. As the models are of the same type and the elements are of the same type as well, then the compatibility is veri ed. License L1 contains the model cc:Requirement with the element cc:Notice. This model is not speci ed by license L2, but following the compatibility rules of Table 2.b, the algorithm evaluates that the element cc:Notice is compatible with an Unspeci ed 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 cc:permits cc:Reproduction; cc:requires cc:Notice.
:lic2 a cc:License; THE ELEMENTS cc:permits cc:Reproduction; cc:prohibits cc:CommercialUse.
THE MODELS: - Permission - Requirement (a)
THE MODELS: - Permission - Prohibition (b) element (cc:CommercialUse) in license L1. The model cc:Prohibition is not speci ed in L1. From Table 2.b, the algorithm evaluates cc:CommercialUse and Unspeci ed incompatible. The compatibility evaluation of the licenses leads to a false answer.
The following properties hold for the license compatibility relation we de ne. Property 1 (Symmetry). Let Li; Lj be two compatible licenses, then 8li 2 Li; 8lj 2 Lj it holds that if li lj then lj li.
The proof follows from the de nition of the Compatibility Evaluation algorithm 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 2 (Li Lj ) Lk, then either l 2 (Li Lj ) or l 2 Lk (or both). This means that either l 2 Li, or l 2 Lj , or l 2 Lk. Thus l 2 Li or l 2 (Lj Lk). This means that l 2 Li (Lj Lk) where (Li Lj ) Lk Li (Lj Lk). (Associativity () Let the clause l 2 Li (Lj Lk), then either l 2 Li or l 2 (Lj ) Lk) (or both). This means that either l 2 Li, or l 2 Lj , or l 2 Lk. Thus l 2 (Li Lj ) or l 2 Lk. This means that l 2 (Li Lj ) Lk where Li (Lj Lk) (Li Lj ) Lk. 5
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 satis es the licensing clauses specied by the licenses in L(C). In particular, the de nition of the composite license satis es 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 de ne the algorithm which generates Lc from the set of compatible licenses. The rst step consists in providing the rede nition rules the algorithm applies in case a subsumption relation holds among these license elements. Table 1 shows the rede nition rules given the subsumption relation among the elements. We identify two kinds of rede nition: a rede nition where the more permissive element is included in Lc, and another rede nition 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 Unspeci ed, 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 de ned, 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.
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 [
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. :lic1 a cc:License; cc:permits cc:Reproduction; cc:requires cc:ShareAlike.
(a) :lic2 a cc:License; cc:permits cc:DerivativeWorks; cc:prohibits cc:CommercialUse.
(b) @prefix cc: http://creativecommons.org/ns. @prefix : http://example/licenses. :licComposite a cc:License; THE ELEMENTS cc:permits cc:DerivativeWorks; cc:requires cc:ShareAlike; cc:prohibits cc:CommercialUse.
THE MODELS: - Permission - Requirement - Prohibition (c) Example 2. Assume we want to analyze two licenses L1 and L2, visualized in Figure 7.a-b. Following our Compatibility Evaluation algorithm, we rst compare the two licenses at the model level. Both licenses contain the model cc:Permission, the rst 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:Reproduction and cc:DerivativeWorks. This means that we can rede ne one element as the other element when we build the composite license. The rst 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 licenses are compatible. Thus composition is allowed, following Table 3 and the composition rules de ned above. Lc is obtained using the more permissive permission (Table 1), and the OR-composition heuristic (Figure 7.c). Lc permits cc:DerivativeWorks (from the rede nition rules of Table 1), requires cc:ShareAlike, and prohibits cc:CommercialUse.
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 speci cations. First, we verify the compatibility among the licenses associated to the various named graphs a ected by the consumer'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 nally returned to the consumer together with the requested data.
The rst point to be addressed is a legal and social validation of the proposed 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 de ning more complex heuristics like the one looking for the minimal composite license.