| SubmissionsW3C is pleased to receive the ccREL: The Creative Commons Rights Expression Language Member Submission from Creative Commons.
ccREL is a major update of the earlier work of Creative Commons, proposing an annotation mechanism for expressing licenses of resources on the Web. ccREL provides a comprehensive approach, covering an abstract model using RDF, a definition of basic properties and classes that can be extended and reused by third parties, and recommended practices to serialize this abstract model.
The abstract model separates the concept of License, which
can be characterized by a number of predefined properties with possible values,
and so called "work properties", i.e., properties that relate a specific work
to a specific instance of a License. The latest versions of the
well-known Creative Commons licenses
("Creative
Commons Attribution License", "Creative
Commons Attribution-Share Alike", etc.) are all instances of
License; however, and therein lies one of the important new
features of ccREL, by defining those in terms of specific RDF properties, third
parties can define their own variants of License and combine those
with the rest of the general ccREL framework. Also, automation can be built to
interpret other licenses that re-use the same properties (with some caveats
described below).
ccREL is firmly rooted in RDF, meaning that the various syntax possibilities for ccREL are also bound to possible RDF serializations. For (X)HTML documents, RDFa is the preferred serialization format (discontinuing the previous practice of adding RDF/XML code as an HTML comment in the HTML source), and the document gives several examples of how to do that in practice. For other document formats, usage of GRDDL, direct embedding of RDF data, XMP, etc, are also described. The separation of the abstract RDF-based model from the specific syntax is rewarded insofar as many different syntaxes become possible depending on the underlying Web resource format. This is also a major step forward compared to the earlier Creative Common license recommendations.
Although not formally part of the submission, the ccREL namespace document and ccREL RDF schema file are integral parts of ccREL, hence we give some small comments on those.
The goal of the ccREL work is to provide a general vocabulary that allows third parties to express their own licenses. Let us suppose that this third party wants to prohibit reproduction of the work; the natural approach would be to say (using Turtle notation):
example:ThirdPartyLicense a cc:Licence ;
cc:prohibits cc:Reproduction ;
...
It is, however, not clear from the namespace document, or from the ccREL
schema, whether this usage of prohibits is consistent with the
expected ccREL usage patterns. The ccREL schema explicitly
defines the range of prohibits to be a Prohibition.
This means that an RDFS reasoner may deduce that Reproduction is
(also) of type Prohibition. This is not in contradiction
with the schema document. However, it looks contradictory to the namespace document, which seems to
make a strict separation between the possible instances of
Prohibition and Permission; clearly a better
documentation is needed here.
Another, though simpler issue is that there is no explanation on the usage
of Jurisdiction, except that it is in the range of
jurisdiction (e.g., it is an RDF Class). What are the possible
instances of that class?
The core of the current abstract model is to define RDF triples of the form:
<URI-of-resource> xhtml:license <http://creativecommons.org/licenses/by/3.0> .
relating some Web resource to a particular license (e.g., by encoding this
triple in RDFa in the XHTML source of the Web document). In this setup,
<.../by/3.0> is an instance of the general
cc:License class.
An alternative might have been to use RDF typing instead, using a triple of the form:
<URI-of-resource> rdf:type <URI-for-Class-of-Documents-licensed-under-cc-by-3.0> .
in which case <...-by-3.0> would be a subclass
of cc:License. This approach would have made it possible to use
the richer classification facilities of OWL to define more complex Licenses.
For example, if the goal was to define a special license with a fixed
attribution URI to, e.g. http://www.example.com, one could define
something like:
example:NewLicense owl:subClass <URI-for-Class-of-Documents-licensed-under-cc-by-3.0> ;
owl:subClass owl:Restriction ;
owl:onProperty cc:attributionURI ;
owl:hasValue <http://www.example.com> .
and the user of such a Licence could then simply say:
<URI-of-resource> rdf:type example:NewLicense .
The OWL restriction idiom is used by POWDER to attach document properties to classes of resources. (Whether the attribution would then be added explicitly by the user or inferred by an OWL aware tool is a secondary question.) The usage of OWL might facilitate the modeling of a number of more complex features such as the definition of the disjointness of certain classes, or the usage of property characterization (functional, inverse functional, etc.). Tools could then detect possible contradiction more easily.
It must be said that using OWL, even a simple profile thereof, might be too
complicated for the core constituency of ccREL, supporting the model in this
Member Submission. We also recognize that such an approach would depart from
the common usage of the XHTML license
relation or Dublin Core's
license term. Nevertheless, it may be worth considering this
direction in the future if more complex licensing approaches are to be
considered and developed.
Some design choices of the Semantic Web lead to interesting interactions with the intended semantics of ccREL: RDF is designed to allow systems to get useful and reliable data without supporting all possible forms of inference. This is accomplished by making sure that any conclusions an application draws at one level of inference are still true when the application performs more inference.
The intended interpretation of ccREL licenses means that agents need to
assume defaults on some properties. For example, the permission to use a work
commercially is concluded from the absence of an explicit
cc:prohibits property. Likewise, an agent will need to know the
full set of cc:requires statements before it can conclude
that it actually can and will fulfill all requirements that go along with the
agent's intended use of the work.
In order to be able to draw these conclusions in a predictable way, an agent needs to work on an explicit RDF graph; the conclusions are then drawn limited to the scope of that graph. Speaking technically, ccREL as currently specified employs non-monotonic reasoning. To map this non-monotonic reasoning into RDF's monotonic semantic framework, the reasoning needs to be scoped to a specific context.
To establish such a context, ccREL could, e.g., specify that no additional reasoning is applied to the graph that describes a license, and limit the graph that is considered to the triples obtained by dereferencing the license URI. Given such an explicit rule, someone wanting a list of documents which can be used as the basis for derivative works could perform a SPARQL query like this one:
PREFIX cc: <http://creativecommons.org/ns#>
PREFIX xhtml: <http://www.w3.org/1999/xhtml/vocab#>
SELECT ?doc WHERE {
?doc xhtml:license ?license
GRAPH ?license {
?license cc:permits cc:DerivativeWorks
}
}
By not specifying what graph precisely is used to determine the meaning of a license, implementors of the rights expression language encounter a trust question concerning who may make what statements about what license. That question is then partially solved through a social convention:
"Importantly, Creative Commons does not allow third parties to modify these properties for existing Creative Commons licenses."
On the one hand, this social convention is somewhat surprising in a largely technical specification; it is specific to the licenses issued by Creative Commons, and does not, on its face, apply to licenses isssued by third parties. On the other hand, it is not specific enough to solve the scope issue discussed above.
However, a solution that scopes the statements about a license in the way outlined above would also help to solve the trust issue, without having to resort to inexact interpretations of a social convention.
The design pattern that we describe above enables transforming non-monotonic data into monotonic data, and is therefore safely usable by in the richer context of the Semantic Web. However, several key extension possibilities of the Semantic Web need to be restricted when using defaults:
requires relationships as applications that don't
perform exactly this inference will assume a contradictory default
value.While the trade-off between these restrictions and the use of defaults may very well be the right choice for the ccREL case, we recommend caution in other environments in which the Semantic Web's ability to extend and mix knowledge from different sources is beneficial to consumers of the data.
The RDF aspects of the Creative Commons infrastructure are clearly an integral part of the Semantic Web landscape, including the Linking Open Data cloud. As such, this Member Submission is obviously related to the Semantic Web Activity.
As a policy language, ccREL is also related to the work done by the Policy Languages Interest Group (PLING).
ccREL is a clear application use case for a future trust/provenance infrastructure for the Semantic Web. A solution in this area should cover some of the problems raised by the usage of ccREL. As such, this Submission should play an integral part in any work in this area as a major use case. W3C does not yet have a timetable for starting this work.
ccREL should also be brought to the attention of PLING. W3C will consider the PLING results when determining whether to commence work on W3C Recommendations on policy languages.
Finally, ccREL is also a clear use case for the POWDER work. Although the formal POWDER Use Case document will not necessarily change in future, ccREL should certainly be made known to the POWDER group as an important practical example for their technology.