[Odrl-version2] Model 2 Semantics - 'unspecified' Rights, canonical list, and GUI

[Steven Rowat]

Hi,

Vicky wrote:

>Maybe I'm being naïve, but I think all we need is a constant `unspecified',
>which can appear anywhere in an agreement.  The assigner of the agreement is
>allowed to replace any occurrence of `unspecified' with anything else and the
>assignment is complete (i.e., can be used to imply a permission) if and only
>if none of the fields in the assignment are `unspecified'.  Why would things
>need to be more complicated than that?  

To answer this interesting question, for myself I'd like to know more about what the expected linkage chain is between ODRL and the enduser. Perhaps others can chime in to give an overview of where exactly ODRL is being planned to fit in, especially in the major context of the Internet and browsers.

However, for now, here's an example situation I've imagined: for general Internet use, I'm assuming that ODRL is going to be used primarily by two entities that interact using it: one will be the web browser and one will be an application written around ODRL that allows content publishers to set permissions on their web pages. 

Of course, this latter permission-setting in ODRL could be done also by hand, by savvy coders, in the same way that an HTML/CSS page can be coded by hand. However hundreds of thousands, perhaps millions, more people will quickly be able to use ODRL if there is a coding application that relieves them of the need to learn a new language; in the same way that the explosion of web pages is due to the GUI html-coding applications.

Anyway, in either case, what I envision is that ensuring that ODRL correctly conforms to a category such as Ticket, Next Rights, or Agreement requires that the permissions code inserted by the coding app or person (Assignor) be perfectly understood by the browser, so that it can be used accurately in interacting with the Assignee. 

Now, how can this happen if it's 'unspecified'? It would appear there would still need to be a canonical list of acceptable terms to plug into that 'unspecified' place, or the browser wouldn't understand and know how to proceed. So that's a first point - there would still need to be categories with accepted terms, even using an 'unspecified' system This may be trivial to you.

However, second, and I believe important for the successful acceptance of the ODRL system, is the following: if the permissions-setter is not coding savvy (as many individual content-owners or even publishers will not be), they may appreciate the help that a coding app will give them; especially if almost all the forseeable situations can be covered by several variations that are already laid out. 

In other words, the canonical list may need to have 10 or even 20 terms to cover all situations of types of Rights Agreement that it will encounter in 'unspecified', but the average, say, poetry publisher, will only want to have to learn about the three or four categories of Rights Agreement that they will actually use; so an GUI application for them will only present them with those alternatives.

So, I find the position I'm coming to with this reasoning is that the two positions could be combined. Your 'unspecified', with a cononical list of possibles, could be the default position, to guarantee maximum flexibilty for both developers and for coders who want to use a full range of the possible forms for the agreement; and a UI wrapper application would merely choose which ones it wants to present to its target audience of permissions-setters. 

And the browser would understand all of them in either case.

?



steven rowat