When Commons Machinery started, one of the organizations or groups that we reached out to was a W3C community group called ODRL. ODRL stands for Open Digital Rights Language, and is managed by a very enthusiastic fellow called Renato Iannella. The idea of ODRL is to create a general purpose language and a model to express rights digitally using machine readable and machine understandable formatting. An example of when you might use ODRL: John gives permission to Liza play an .mp3 ten times, after which the permission is no longer valid. We can then build this into the software we are using so that it can interpret this permission and ensure that Liza plays this .mp3 only ten times, after which she isn’t able to play it any more. This can be used as Digital Rights Management (DRM), which is not something Commons Machinery likes, but is something that some users of ODRL might be looking for. However, you can also use it for more circumstances more similar to what we are working on, for example: John gives everyone in the world permission to reuse his work, to copy it, to display it, and to use it in other contexts as long as the users give him credit (an attribution requirement) — essentially a creative commons attribution license. You can express this whole range of anything from DRM to non-DRM with ODRL.
In order to be so all-purpose, ODRL makes a number of assumptions about the environments it will be used in. That lets us know already that ODRL is mostly designed to be used within particular domains in business-to-business transactions, between softwares from the same vendor, or between vendors that are collaborating in some way. It’s only when you have an understanding or control in some way of both recipients and senders of the ODRL permissions that you can really make use of it.
Let’s take the example from before: John gives Liza permission to play an .mp3 ten times. One of the questions you can ask yourself is: So which .mp3? That’s something we encountered in our work previously; that in order to identify the work that you’re referring to in many situations you need an identifier (an identifier for digital work is the equivalent of ISBN for a book or ISSN for a journal).
There are a number of different identifiers, and for essentially any domain there is someone who is managing the registry of identifiers. ODRL requires that every asset is marked with an identifier, but it never specifies which, leaving that to the implementation. You need to determine for your particular ODRL implementation which identifier you are going to use for the works you are referring to. Are you going to use something like ISBN expressed as a URI or are you going to use something else? ODRL code doesn’t specify, so you need to invent this yourself.
Second challenge is: Who are John and Liza? If you are talking about permissions that John gives to Liza there should be some way of identifying who these people are, and so we need unique identifiers not only for the works but also for the people involved in this transaction. It could also be a company that gives or receives permission, and so a company would need a unique identifier as well. ODRL simply says that we need identifiers for people or organizations, but it doesn’t say what they should look like, who will be managing them, or what particular identifiers we might need.
If you are going to make use of ODRL, you really need to have some control over both the sender and receiver, or at least some understanding with both the sender and receiver about which particular identifier you’re going to use for people or organizations. ODRL is a relatively simple standard. They have kept it lean and clean and a lot of things are built into the core vocabulary of ODRL. This means that a lot of the permissions you are able to give people — like ‘play’ and ‘use’ — are defined, and they have a meaning already in the ODRL standard while other permissions do not. So there could be permissions that are relevant for some industries, but which are not part of the ODRL standard. The IPTC are building on the ODRL standard for one of their standards, but they are extending it and changing the meaning of some of the terms while introducing other terms that make sense for their industry. This is the way that ODRL is supposed to function, but it introduces complexity: if you want to understand what an ODRL policy means then not only do you need the identifiers but you also need to have an understanding of whether you are talking about ODRL core vocabulary or if you are talking about an ODRL extension, and extensions can be anything. There’s no limit to the number of extensions, and it’s up to each particular implementation to deal with this. Whew!
In our work at Commons Machinery, I originally felt that ODRL could be useful if we could get people to use that as a way to express Creative Commons licenses in a machine readable way. Then, as time went on, I realized that we don’t have an issue with permission: our focus is attribution. Permission is something we might get to eventually, but it’s not critical to what we are thinking about right now. We are thinking about how to make it possible to relate a work to its context, not who is or is not allowed to use it. That’s part of the contextual information, but it’s far from the most critical information that we need to convey. We decided to put our work with ODRL on hold indefinitely, until we feel that there’s an actual need to investigate further and to look deeper at the subject of right management. Once we can find support for a use case where this is relevant, we’ll definitely get back to ODRL again.