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 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 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 compatibility rules are satisfied. 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 satisfied, 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 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 <link>1 element.
In this paper, we do not introduce yet another licensing schema. We consider 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.
The Creative Commons Rights Expression Language (ccREL) [1] is the standard recommended by Creative Commons for machine-readable expression of copyright 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. Iannella [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 language5 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 propose 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 contractual 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 selfreferential 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.
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. 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. 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 Informa-tion Element Ontology (nie)12 , the Music Ontology (mo)13 , the Good Relations vocabulary (gr)14 , and the myExperiment Base Ontology (meb) 15 .
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 R 1 and R 2 respectively are associated to different licenses where the elements are cc:Reproduction and cc:Sharing. The consumer's query returns triples from both R 1 and R 2 , 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 el i is more permissive, i.e., it accepts more, than the other element el j . 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 L c 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 el 1 is compatible with another element el 2 , i.e., el 1 el 2 , 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 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 (el 1 compatible with el 2 ) is equivalent to (el 2 compatible with el 1 )17 .
As in [4], a possible situation which may arise is that one license specifies clauses which are not specified by the other license, e.g., one license specifies cc:Prohibition and the other license does not specify this clause. Table 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 L c by requiring that L c 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 compatibility [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 L 1 and L 2 where L 1 contains a clause specifying the requirement for cc:Attribution and L 2 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 satisfies both the cc:CommercialUse clause and the cc:Attribution clause. This means that these license sets are non-disjoint. The rules detailed in Tables 1-3 provide the basic components of our Compatibility Evaluation algorithm. Let L(C) = {L 1 (R 1 ), . . . , L n (R n )} be the set of licenses associated to the n named graphs affected by the consumer's query where L i (R i ) is the license associated with named graph R i , then our objective is to compose these licenses into the composite license L c . Definition 2 defines that two licenses are compatible if for all their clauses l i , these clauses are compatible. Definition 2. A license L i is compatible with another license L j , L i L j , if ∀l i=1,...,n ∈ L i , ∀l j=1,...,m ∈ L j it holds that l i l j .
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 (m i ≡ m j ), (ii) the models are composed by elements which satisfy 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 (el i ≡ el j ), (ii) the elements satisfy the subsumption rules (Table 1) (SubsumptionRules(el i , el j )), (iii) the elements satisfy the compatibility rules against Unspecified (Table 2.b) (UnspecifiedRules(el i , el j )), (iv) the elements satisfy the compatibility rules (Table 3) (IntersectionRules(el i , el j )), and (v) all the nested elements (if any) are compatible.
Example 1. Assume we want to analyze two licenses L 1 and L 2 , 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 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 verified. License L 1 contains the model cc:Requirement with the element cc:Notice. This model is not specified by license L 2 , but following the compatibility rules of Table 2.b, the algorithm evaluates that the element cc:Notice is compatible with an Unspecified element. Compatibility is maintained. Finally, the algorithm evaluates the model cc:Prohibition of L 2 , looking for the same model and the same @prefix cc: http://creativecommons.org/ns. @prefix : http://example/licenses. :lic1 a cc:License; cc:permits cc:Reproduction; cc:requires cc:Notice.
THE MODELS:
-Permission -Requirement THE ELEMENTS @prefix cc: http://creativecommons.org/ns. @prefix : http://example/licenses. :lic2 a cc:License; cc:permits cc:Reproduction; cc:prohibits cc:CommercialUse.
-Permission -Prohibition THE ELEMENTS Fig. 5. An example of compatibility evaluation which leads to a false result.
element (cc:CommercialUse) in license L 1 . The model cc:Prohibition is not specified in L 1 . 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 L i , L j be two compatible licenses, then ∀l i ∈ L i , ∀l j ∈ L j it holds that if l i l j then l j l i .
The proof follows from the definition of the Compatibility Evaluation algorithm and the composition rules. The symmetry property ensures that
Property 2 (Associativity). Let L i , L j , L k be three licenses then it holds that
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 L c satisfies the licensing clauses specified 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 L c can be generated only if all the licenses composing it are compatible (Section 4). Property 3. Let L 1 , . . . , L n be n licenses to be composed in a composite license
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 L 1 (R 1 ), . . . , L n (R n ) be the licenses associated to named graphs R 1 , . . . , R n . The composite license L c for R 1 , . . . , R n is consistent with
We now define the algorithm which generates L c 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. Table 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 L c , 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 L c . These rules are necessary to keep the consistency of L c 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 L c . 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 composition 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. :lic1 a cc:License; cc:permits cc:Reproduction; cc:requires cc:ShareAlike.
@prefix cc: http://creativecommons.org/ns. @prefix : http://example/licenses.
:lic2 a cc:License; cc:permits cc:DerivativeWorks; cc:prohibits cc:CommercialUse.
@prefix cc: http://creativecommons.org/ns. @prefix : http://example/licenses.
:licComposite a cc:License; cc:permits cc:DerivativeWorks; cc:requires cc:ShareAlike; cc:prohibits cc:CommercialUse. Example 2. Assume we want to analyze two licenses L 1 and L 2 , 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:Reproduction 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 licenses are compatible. Thus composition is allowed, following Table 3 and the composition rules defined above. L c is obtained using the more permissive permission (Table 1), and the OR-composition heuristic (Figure 7.c). L c permits cc:DerivativeWorks (from the redefinition 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 specifications. First, we verify the compatibility among the licenses associated to the various named graphs affected by the consumer's query. Second, given the compatibility among the composed licenses, we construct L c 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 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 activities 21 . Finally, we are defining more complex heuristics like the one looking for the minimal composite license.