[Odrl-version2] ODRLv2 Model Semantics, further comments [was: RE: ODRL-Version2 Digest, Vol 6, Issue 3]

[Steven Rowat]

Hi,

Some further remarks about the ODRL 2 model, prompted largely by Vicky's interesting comments. Since the markup is getting complex, I'll separate each of my separate points with:  ++++++++

+++++++++++

>2.1 Rights Class Model

>The ODRL Model consist of a number of predetermined classes of rights expressions...>

A small grammatical error I believe; 'consists', not 'consist' would be correct here, since the subject of the sentence ("Model") is singular.

+++++++++

>The Rights entity may contain a Context that supports the following information: .../...Where do we define these terms formally? >

I'm confused by the final sentence. Are you asking if there is a place in ODRL where this information can be entered? Or, are you saying that they are somehow contained in the following section, the "Rights Entities", and we should be suggesting which of them need which values of the context?

+++++++++

Vicky wrote:

>2*) If the Context includes a `space' for textual comments and remarks, why
>do you need another space for the human readable formulation of the rights
>expression?  

I'd like this clarified also. My untutored assmption is that it means that 'textual comments and remarks' will be machine readable - at least to the degree that they are identified in XML as being comments and remarks on this particular entity - whereas the second is a description of the entire entity that would include an abstraction of all the other information in the context. There will be some overlap between the two fields, but the 'human readable formulation' could just be containing an abstracted/summary version of all the information, including  of the text/comments, whereas the latter could be more extensive in its dedicated form.

+++++++++

>Statement. The Statement entity supports rights expressions that consists of any number of (or none of) entities from the complete model. This is aimed at scenarios where there is no fixed criteria for the content....>

I'm having trouble understanding how this would be used, and I would like a real-world example of this, other than the "rights template" example shown later. If a rights template is the only real-world use, then I suggest that having a separate entity for this purpose is unnecessary. (One could just as easily make up an offer, leave out the names, and save it as a personal template.)

+++++++++

Vicky wrote:

>3**)  It seems to me that there are two types of Rights entity, an agreement and a request...<snip>...If this is correct, then wouldn't it be simpler and clearer to remove all but the agreement and request entities and to say that partial agreements can be created to suit an application's needs....>>

Perhaps, but if ODRL is going to standardize the DRM process so that all user agents can understand it, then this would require a fairly subtle (and likely complex) layer of constraints on how the agreemtents could be rewritten, would it not? My guess is that this would be even more complicated and subject to pitfalls than spelling out six types of Rights Entities.

However, I do believe it would be a good idea to compromise between the two positions: maybe reducing down to three or four types of Rights entities, and making two or three of them as context- or value-dependent versions of the others. 

+++++++++

  Vicky wrote:

>4) I don't understand the Request entity.  Could you send me a few examples?

Examples of this would be interesting to me also; I'm guessing it would be something like this: A web site  has a standing Rights Entity Offer that you can download 10 songs for $10, but only play them on one machine. A person coming to the web site could send a Request that they download 5 songs for 5 dollars (and specify, probably, which songs). Or they might Request that they download the 10 songs for $15, but be able to play them on any machine. Or that they be able to download the 10 songs for $1,000, and be able to resell them to anyone. ;-)  Etc.  In essence, it would be a form of bartering. Especially since the Assignor could come back with a return offer. It could even work as haggling, in a formal way, in order to buy and sell large objects, like books or artworks, that might have offers and counter-offers....could it not?

+++++++++

>2.2 Asset Model

Vicky wrote:

>In particular, suppose that an
>agreement gives Alice the right to copy a speech that has 5 parts.  Why
>should it necessarily follow that Alice may copy only one of the parts,
>possibly taking it out of context?

Would this not already be convered by Constraint/Prohibition in the Agreement? In other words, the Agreement will be specifically set up by the Assignor so that this can't happen.

+++++++++

Vicky wrote:

>4) Suppose that an agreement includes a permission whose Action is {`copy',
>`download'} and the exclusive Boolean flag is set. ...<snip>...I think I'm missing the
>intuition behind the flag.

You're not the only one. :-).  I skipped the 'exclusive boolean flag' paragraph the first time around since I didn't understand it, but this time, since you're (admirably) not going to let it go by, I searched on Google for "Exclusive boolean flag" to see if I could find something about it. Result: 8,058,044,651 pages searched. ONE RESULT. It was Vicky's statement, above!  :-)  LOL.

After that I widened the search and did find out what it meant, which I think is "one or the other but not both", which doesn't seem so hard..... But still, in the Model 2 explanation, I'd be happier if we could avoid sentences like the last one in section 2.4.1:

<The default Exclusive boolean flag setting for all Actions is false.>

This made my head spin the first time around. Perhaps adding a gloss sentence would help, like: "In other words, by default ODRL 2 Actions do not use the exclusive 'or'". 

Still, in the larger context, is it absolutely necessary to use the exlusive 'or'? It makes the document hard to understand for people who are not academic specialists in logic. And what we are attempting here, or at least what I'm attempting <grin>, is something that will be accessible to non-specialists and specialists alike, to the degree that is feasible in the context of the job that needs to be done.

+++++++++

>2.4.2 Constraint Model

Vicky wrote:

>1) Can a constraint capture the fact that an assignee has a certain property
>(e.g., is a student, has no outstanding fines)?  Can a constraint capture
>that an assignee does not have a certain property (e.g., is not a felon or is
>not on the do-not-sell-to list)? 

Very interesting suggestions. I agree it would be good to have these types of information available.

+++++++++

>2.4 Duty Model

Small grammatical error in first paragraph:
>...the Assignee of the linked Permission is responsible for fulfill the Duty...>

Should be 'for fulfilling' the Duty, I believe.

+++++++++

>The Duty entity contains the following: .../..../ Object (required). The Object of a Duty may also be an Asset entity. The Object entity contains an unlimited set of Object Names which are formally defined as Profiles. >

I would like examples of the "Object" of Duty in the real-world. I don't yet understand how this would function. What sorts of "Objects" are contemplated here?

I'll note that the word "Object" is misused, overused, and confusingly used in many other applications. Perhaps it could be avoided here entirely, and some other word that has a hint of the desired function (which I don't understand yet) could be substituted.


_______

Again, thanks to all who work on this. 

I'm hopeful that someday ODRL will be an important step in world information flow. 

steven rowat