[Odrl-version2] RE: ODRL-Version2 Digest, Vol 6, Issue 7

[Vicky Weissman]

Hi,

Sorry for the late reply.  Steven has brought up a point that I strongly
agree with.  I'd like to reiterate and expand on it a bit.  

I think ODRL would be a much more compelling language if it came with a
relatively easy-to-use implementation.  In other words, there should be a way
for people to read/write agreements easily.  Also, there should be a way for
people to ask (and answer) questions about agreements, such as whether a
particular action is allowed, which actions are allowed, and what can be done
(if anything) to get a desired permission.  Designing/building such a
solution is a daunting task, at least to me, but I suspect a reasonable
effort in this direction could give awesome results.  Following in the
Creative Commons spirit, we could choose a fragment of ODRL that would likely
be of interest to many applications and design a "simple" implementation for
that fragment.  It still wouldn't be easy, but it could be very worthwhile.

On another topic...  
<S>
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.
<V>
I think you might be confusing `unspecified' with `forall'.  An agreement
that mentions `unspecified' is an unfinished agreement.  Its interpretation
is the same as any other agreement that has yet to be finalized; it does not
give or deny rights.  It could be used as a template, an advertisement, etc.


Note that the term `unspecified' would not necessarily be used in a ticket or
a Next Rights.  I propose that a ticket is an agreement whose assignee is a
constant, say `ticket holder'.  The browser would interpret `ticket holder'
to be a name for whoever presents the ticket.  This is not the same as the
ticket giving rights to everyone, so we wouldn't want to replace `ticket
holder' with every subject in the system.  Next Rights is an agreement that
gives a particular subject permission to grant certain rights to others, so
`unspecified' would not be necessary here either.

Best,
Vicky