Metashare vocabulary for licenses
Requirements of a Vocabulary to License Linguistic Linked Data
This is the specification of a vocabulary extending ODRL 2.0 suitable to describe the licensing terms of language resources and more specifically linked data resources, taking as a base the META-SHARE requirements.
"The META-SHARE metadata model aims to describe Language Resources, encompassing both data sets (textual, multimodal/multimedia and lexical data, grammars, language models etc.) and tools/technologies/services used for their processing. Its main purpose is to serve the needs and requirements of META-SHARE, the open distributed facility for the sharing and exchange of resources of META-NET".
A part of the metadata model is aimed at describing the licensing terms under which language resources can be used. The current description, in XML, is available here: META-SHARE-LicenseMetadata.xsd. The whole MetaShare.ttl is here MetaShare.ttl
This wiki describes how these terms can be represented in RDF. For this regard, ODRL has been the vocabulary of choice.
ODRL 2.0 specifies an abstract core model and a common vocabulary. ODRL 2.0 can be serialized in XML, JSON and RDF. The latter serialization is based on the ODRL 2.0 Ontology.
A set of complete examples can be found here
The official TTL file and documentation can be found here.
Basic notions and rationale for modifications/extensions
A Language Resource may be available in one or more ways (e.g. as a downloadable file, on a CD-ROM or accessible via an interface), in different forms (e.g. as a csv or txt file), through different distributors and with different licensing terms. This is represented in the Distribution class (represented as dcat:distribution).
A Distribution is made available under a set of licensing terms and conditions which are described in the License class. META-SHARE has recommended the use of a set of standard licenses (see http://www.meta-net.eu/meta-share/licenses for more information) but, of course, providers can still use their own licenses to distribute their resources. The set of standardised licenses that are already in use in the context of META-SHARE are provided ?here? in RDF form.
The License class is used to describe the set of licensing terms and conditions associated with a certain policy. In order to allow for standard license texts/templates, details that may differ across distributions (e.g. pricing, formats, delivery channels etc.) are linked to the Distribution class.
Some requirements
With no particular order, the following requirements are identified.
R1 Distribution Rightsholder vs. IPR holder
Requirement: to represent the various rights sholders.
Representation: There is a DublinCore property to describe the rightsholder. Yet, economical rights (distribution, public communication, etc.) can be negotiated separatedly and there may be different rights holders for the same asset. Thus, in order to distinctly specify the distribution rightsholder we define the ms:distributionRightsHolder as a subproperty of dct:rightsHolder and the Intellectual Property Rights holder as a close match to dct:rightsHolder.
Example:
:languageResource a dcat:Distribution; ms:distributionRightsHolder "The Distribution Rights Holder"; ms:iprHolder "The IPR holder, usually the Creator of the Resource". .
R2 Temporal constraints
Requirement: to represent the temporal constraints of granted rights. Some licenses grant rights for a limited period of time.
Representation: ODRL permits representing temporal limits.
Example:
:myPolicy a odrl:Set ; odrl:permission [ odrl:action odrl:read ; odrl:target ms:languageResource ; odrl:constraint [ a odrl:Constraint ; odrl:operator odrl:lteq ; odrl:dateTime "2010-12-31"^^xsd:date ] ] .
R3 Common licenses in the linguistic domain
Requirement: to identify some of the most common licenses used in the linguistic domain. To write them in RDF if possible.
Representation: The following licenses are identified:
List of already mapped licenses, present in the RDFlicense dataset
ms:ApacheLicence_2.0 owl:sameAs <http://purl.org/NET/rdflicense/licAPACHE> ms:BSD-style owl:sameAs <http://purl.org/NET/rdflicense/licBSD> ms:GPL owl:sameAs <http://purl.org/NET/rdflicense/gpl2.0> ms:LGPL owl:sameAs <http://purl.org/NET/rdflicense/licGNU-LGPL> ms:cc-ZERO owl:sameAs <http://purl.org/NET/rdflicense/cc-zero1.0> ms:CC-BY-SA owl:sameAs <http://purl.org/NET/rdflicense/cc-by-sa3.0> ms:CC-BY-NC-ND owl:sameAs <http://purl.org/NET/rdflicense/cc-by-nc-nd3.0> ms:CC-BY-ND owl:sameAs <http://purl.org/NET/rdflicense/cc-by-nd3.0> ms:CC-BY-NC owl:sameAs <http://purl.org/NET/rdflicense/cc-by-nc3.0> ms:CC-BY owl:sameAs <http://purl.org/NET/rdflicense/cc-by3.0> <span style="color:red">? to add links ?</span> ms:MS-NC-NoReD-FF; ms:ELRA_EVALUATION; ms:ELRA_END_USER; ms:CC-BY-NC; ms:CLARIN_RES; ms:CLARIN_ACA; ms:MS-NC-NoReD-ND; ms:MS-NC-NoReD-ND-FF; ; ms:MS-C-NoReD-ND-FF; ms:MS-C-NoReD-FF; ms:MS-NC-NoReD; ms:MSCommons-BY-NC-SA; ms:proprietary; ms:CLARIN_PUB; ms:MSCommons-BY-NC-ND; ms:underNegotiation; ms:GFDL; ms:MSCommons-BY-SA; ms:MSCommons-BY-NC; ms:MS-C-NoReD; ms:MSCommons-BY-ND; ms:MSCommons-BY; ms:MS-C-NoReD-ND; ms:CLARIN_ACA-NC; ms:BSD; ms:Princeton_Wordnet; ms:AGPL; ms:ELRA_VAR
R4 To neatly represent conditions of use
Requirement: to represent the most common conditions present in the licenses of R3.
Representation: ODRL provides a clear structure to represent duties and constraints. In case more conditions are needed, new right operands can be defined. Yet, things are not so simple, as a flat structure would suffice and would be preferred by a non-RDF-acquainted editor of metadata.
Example: expressing the following straightforward statement should be possible.
ms:conditionsOfUse ms:languageEngineeringResearch, cc:Attribution, ms:nonCommercialUse, ms:noDerivatives ;
R5 Represent the obligation to inform the licensor
Requirement: Represent the obligation to inform the licensor
Representation: The element odrl:inform is defined as "The act of informing a party that an action has been performed on the asset".
Example:
:myPolicy
a odrl:Set ;
odrl:permission [
odrl:action odrl:read ;
odrl:target ms:languageResource ;
odrl:duty [ odrl:action odrl:inform ;
odrl:informedParty odrl:assigner ]
] .
R6 Represent the obligation to redeposit
Requirement: represent the obligation that if a work is derived from another one, it must be deposited in a determined place.
Example:
:myPolicy
a odrl:Set ;
odrl:permission [
odrl:action odrl:read ;
odrl:target :languageResource ;
odrl:duty [odrl:action ms:redeposit]
] .
Requirement: to limit the access (or exercise of other rights) to the resource to the members of a particular group.
Representation: this can be fully accomplished with ODRL. odrl:Group is defined as "Specifies that the scope of the relationship is the defined group with multiple individual members." odrl:nextPolicy is defined as "The Assigner requires that the Assignees grants the specified Policy to a third party for their use of the Asset." These two terms are used together to represent the case where the assignee is allowed to share a language resource only with members of the MetaShare group.
Example:
:myPolicy
a odrl:Set ;
odrl:duty [
odrl:action odrl:nextPolicy ;
odrl:target [
a odrl:Set ;
odrl:permission [
odrl:action cc:Sharing ;
odrl:assignee [
a odrl:Group ;
rdfs:label "MetaShare members"@en
] ;
] ;
] ;
].
R8 Academic / noncommercial / evaluation use
Requirement: Many licenses limit the uses that can be done with a resource depending on the use (purpose). (Note the difference: "academic use" means using a resource with academic purposes. "academic users" means used by a member of an academic institution. Both ideas are present in licenses, but this requirement only refers to the former).
Representation: The ODRL odrl:purpose element satisfies this requirement. However, it does not include specific terms for academic /noncommercial /evaluation uses. At least the following elements need to be defined: ms:noncommercial, ms:academic, ms:evaluation, ms:research, ms:languageEngineeringResearch .
Do note that the prohibition to commercialize can be specifically given. Both are commented in the example below
Example:
:myPolicy
a odrl:Set ;
#Here it is declared that it is forbidden to commercialize
odrl:prohibition [
odrl:action cc:commercialUse ;
odrl:asset ms:languageResource
] ;
#Here it is declared that distribution can be done but only for research purposes.
odrl:permission [
odrl:action cc:Distribution ;
odrl:asset ms:languageResource ;
odrl:constraint [
odrl:operator odrl:eq ;
odrl:purpose ms:research ]
] .
R9 Attribution condition
Requirement: Attribution is a very common case.
Representation: ODRL fully satisfies this requirement, see the example below.
Example:
:myPolicy
a odrl:Set ;
odrl:permission [
odrl:action cc:Distribution ;
odrl:asset :languageResource ;
odrl:duty [
odrl:action cc:Attribution;
odrl:attributtedParty <http://author.com>
]
] .
R10 Conditions on the user nature
Requirement: the representation should include conditions on the nature of the user (whether they are in a public institution, belong to the educational sector, etc.). At least the following list of values must be defined: academicUser, commercialUser, memberOfELRA, memberofLDC, memberOfTST-Centrale
Representation: ODRL permits declaring the assignee, and this assignee can be a class with different conditions. An example is shown below.
Example:
:myPolicy a odrl:Set ; odrl:permission [ odrl:action odrl:read ; odrl:target ms:languageResource ; odrl:constraint [ odrl:operator odrl:eq ; odrl:assignee ms:academicUser ] ; ] .
R11 Specification of features on the distribution
This features apply only for the distribution
Requirement R11a: to represent the delivery channel
Representation: ODRL permits declaring the delivery channel, but it does not give any hint on how to represent the channels.
Example:
:myPolicy a odrl:Set ; odrl:permission [ odrl:action odrl:read ; odrl:target :languageResource ; odrl:constraint [ odrl:operator odrl:eq ; odrl:deliveryChannel ms:CD-ROM ] ; ] .
Requirement 11b: to represent the download URL and the execution URL
Representation: This assertion is not a deontic assertion (must, can, cannot) but a positive one.
Example:
:languageResource a dcat:Dataset ; dcat:downloadURL <http://example.com/download> ; dcat:accessURL <http://example.com/access> .
R12 Specification of the condition to distribute derived material and the condition to create derived material
Requirement: to represent both the condition to create derived works and the condition to distribute derived works.
Representation: The definition of cc:DerivativeWorks and odrl:derive seems to suffice
Example:
:myPolicy
a odrl:Set ;
#Here it is declared that it is forbidden to create derived material
odrl:prohibition [
odrl:action odrl:derive
]
.
:myPolicy
a odrl:Set ;
#Here it is declared that it is forbidden to distribute derived material
odrl:prohibition [
odrl:action cc:DerivativeWorks
] ;
R13 Specification of the fee, within and outside the license
Requirement: to represent prices and different payment modalities. To specify the price not within the license (so that it remains in a generic, template-like form) but together with the distribution.
Representation: ODRL suffices to represent the price. For more complex payment modalities, the GoodRelations vocabulary is recommended.
Example: An example of the simple price.
:myPolicy
a odrl:Set ;
odrl:permission [
odrl:action odrl:read ;
odrl:target ms:languageResource ;
odrl:duty [
odrl:action odrl:compensate ;
odrl:target <http://example.com/ubl:AUD0.50> .
] ;
] .
An example of a more complex price, with the GoodRelations vocabulary
:myPolicy
a odrl:Set ;
odrl:permission [
odrl:action odrl:read ;
odrl:target ms:languageResource ;
odrl:duty [
odrl:action odrl:compensate ;
odrl:target [
gr:hasPriceSpecification [ a gr:UnitPriceSpecification;
gr:hasCurrencyValue "400"^^xsd:float;
gr:hasCurrency "USD"^^xsd:string. ].
] ;
] .
An example of price merely referenced, so that the license remains in a template form.
:myPolicy
a odrl:Set ;
odrl:permission [
odrl:action odrl:read ;
odrl:duty [
odrl:action odrl:compensate ;
] .
:languageResourceDist1 a dcat:Dataset ;
ms:price <http://example.com/ubl:AUD0.50>;
odrl:policy :myPolicy.
R14 Specify the next policy
Requirement: to represent the conditions imposed for the licensee to re-distribute or sublicense the resource. This is the case when A grants B a permission to distribute a resource to C. Then A can decide some of the constraints that C still can satisfy
Representation: the ODRL odrl:nextPolicy serves for this purpose
Example: the following example shows how distribution is permitted as long as this ditribution is made only to non-commercial institutions.
:myPolicy
a odrl:Set ;
odrl:permission [
odrl:action cc:Distribution ;
odrl:target :languageResource ;
odrl:duty [
odrl:action odrl:nextPolicy ;
odrl:target :myPolicy2 .
] ;
] .
:myPolicy2
a odrl:Set ;
odrl:permission [
odrl:action odrl:read ;
odrl:constraint [
odrl:operator odrl:eq ;
odrl:industry ms:nonCommercial
] ;
] .
R15 Use license templates
Requirement: to represent generic license templates so that they can be used with a few statements by different parties with the same structure but slightly different details (also sketched in R13)
Representation: ODRL does not support by nature this idea. So, in this case the extension of ODRL is not merely an addition of terms (the kind of extension that is expected) but a slight change in the interpretation of indirections (references) in the license template. This requirement shall be pushed forward to the ODRL community group.
Example: an example of what we would like to achieve would be that in this link , a sample resource offered under different modalities
R16 Define license categories
Requirement: Licenses should be able to be categorised into one of three types: PUB(lic), ACA(demic) and RES(tricted) (CLARIN recommendation).
Representation: ODRL does not support these terms. We propose declaring the new property ms:licenseCategory and the three values thereof.
Example:
:myPolicy a odrl:Policy ; rdfs:label "META-SHARE Commons BY NC SA" ; ms:licenseCategory ms:ACA .
R17 Referencing standard licenses
Requirement: Standard licenses should be simply referenced.
Representation: In case a resource is published under the CreativeCommons BY-NC-ND 4.0 license, the CreativeCommons' URI could be referenced:
http://creativecommons.org/licenses/by-nc-nd/4.0/
If the detailed RDF version of this license is desired, then a possible RDF mapping could be referenced. Many of them are available in the RDFlicense dataset. In this case, the license to be referenced would be
http://purl.org/NET/rdflicense/cc-by-nc-nd4.0
(check here the RDF code)
Example: The following is a language resource licensed under CC-ZERO.
:languageResource a dcat:Distribution; # ...nonlicensing metadata here... ms:license ms:CC-ZERO # ...nonlicensing metadata here... . ms:CC-ZERO rdf:type ms:License, owl:NamedIndividual; skos:closeMatch <http://purl.org/NET/rdflicense/cc-zero1.0> ; cc:legalCode <https://creativecommons.org/publicdomain/zero/1.0/legalcode> ; rdfs:comment "It refers to CC-ZERO which is a kind of license meant to govern the use of a resource"@en ; rdfs:label "CC-ZERO"@en .
The above URL (http://purl.org/NET/rdflicense/cc-zero1.0) implements content negotiation.
Requirement: Mapping MetaShare records to the RDF implementation.
Representation: All elements have been mapped.
Example: The following shows how the original MetaShare record for a language resource can be mapped to the RDF implementation: a Dictionary of Antonyms in Bulgarian Language.
The original XML record is described as follows:
<distributionInfo>
<availability>available-restrictedUse</availability>
<licenceInfo>
<licence>CC-BY-NC-ND</licence>
<restrictionsOfUse>academic-nonCommercialUse</restrictionsOfUse>
<restrictionsOfUse>noRedistribution</restrictionsOfUse>
<distributionAccessMedium>accessibleThroughInterface</distributionAccessMedium>
<downloadLocation>http://infolex.ibl.bas.bg/synomthes/antonimSearchPage.seam?cid=19</downloadLocation>
</licenceInfo>
<iprHolder>
<organizationInfo>
<organizationName lang="en">Institute for Bulgarian Language</organizationName>
<organizationShortName lang="en">IBL</organizationShortName>
<departmentName lang="en">Department of Bulgarian Lexicology and Lexicography</departmentName>
<communicationInfo>
<email>ibl@ibl.bas.bg</email>
<url>http://ibl.bas.bg</url>
<address>52 Shipchenski prohod Blvd., Bl. 17</address>
<zipCode>1113</zipCode>
<city>Sofia</city>
<country>Bulgaria</country>
<telephoneNumber>+35 92 97 92 948</telephoneNumber>
</communicationInfo>
</organizationInfo>
</iprHolder>
<availabilityStartDate>2013-01-21</availabilityStartDate>
</distributionInfo>
The RDF version of the licensing info with the new vocabulary would be as follows:
:bulgarianDictionary a ms:LanguageResource ;
ms:iprHolder "Institute for Bulgarian Language" ;
ms:availability ms:available-restrictedUse ;
dcat:Distribution [
a dcat:Distribution ;
ms:DistributionAccessMedium ms:AccessibleThroughInterface ;
ms:license ms:CC-BY-NC-ND ;
dcat:downloadURL <http://infolex.ibl.bas.bg/synomthes/antonimSearchPage.seam?cid=19> ;
ms:availabilityStartDate "2013-01-21"
] .
Open issues
On the vocabulary IRI
The XML Schema for licensing was http://www.ilsp.gr/META-XMLSchema. The one for RDF is currently: http://purl.org/ms-lod/MetaShare.ttl
How should be the new IRI?
ask Dave about this