[Odrl-version2] Discussion of ODRL v2.0 Model (Cont)

[Vicky Weissman]

Hi Susanne,

<SG>
I think that your contribution is required for the Model and the Core
Profile. However, I think it might make sense to open up new documents for
your contribution. What do you think?

<VW>
I don't have a good sense of what each document will include, so it's hard to
say.  I'll probably have an opinion after I read the descriptions of the
docs.

<SG>
I think of a fragment as something incomplete. However, a statement can still
be a complete rights expression with parties, permissions, constraints, etc.
and then fragment would not really fit. Maybe we find some other term?

<VW>
I wonder if the naming problem is symptomatic of a larger issue.  Maybe there
should be 2 names/constructs; one for a collection of fragments and another
for a (complete) statement.

<SG>
a Request usually provokes an offer

<VW>
Ah ha!  The problem is that I misinterpreted the role of requests.  I thought
a request was formed by an agent who wanted immediate access to an asset
(e.g., Alice requests to download the movie), rather than an agent who wanted
an offer to be made that would, if accepted, permit access under certain
conditions (e.g., Alice requests the movie company to tell her the terms
under which she can download the movie).      

<SG>
Vicky I don't see that we can not express "consumer is over 18 years of age"
or "consumer must have a valid driver's license." We would simply chose the
constraint name accordingly. E.g. ( age_consumer >= 18 ) or (
valid_driverslicense == TRUE)


<VW>
If I understand your response correctly, then every statement can be written
as a constraint.  In particular, for any statement s, we can create a symbol
m to represent s (e.g., m could be s written in English with the words
separated by underscores rather than spaces), then we can write s as the
constraint "m == true".  I'm concerned that evaluating the statements might
be a bit tricky.  For example, to determine whether "age_consumer >= 18", I
think we would need some sort of processing algorithm that would take the
entire context (consumer is Bob Smith, asset is file f, maybe some other
info?) and the constraint as input; munge it to get an appropriate database
query such as "what is Bob Smith's age?"; and then replace "age_consumer"
with Bob's age.  Note that the problem is somewhat more complex if the
constraint is written as "age_of_consumer_is_at_least_18 == true".  If,
instead, the constraint is written as "Age(user) >= 18" then we at least know
what the relevant part of the context is; we might also be able to look up
the information more easily, but I'm not sure.       

<SG>
I also don't see your concerns with the duties. We only have duties now, so
that we CAN express your examples. "if the user plays a movie, then she must
pay 5 dollars at the end of the month" --> permission= play, asset = a movie,
duty = pay, object (of duty) = 5 dollars, constraint (of duty) = by the end
of the month. I the duty is not fulfilled then the permission is not granted.
Does that make sense?


<VW>
I thought a duty, as written in the current draft, had to be some sort of
payment, so you couldn't have a duty be an action such as giving attribution.
I'm also a bit confused about the role of constraints.  I thought the
intuition was as follows: if an agent exercises a permission that is
associated with a duty d and the constraints associated with d hold, then d
must be performed.  Your example seems to suggest the following: if an agent
exercises a permission that is associated with a duty d then d must be
fulfilled while the constraints hold (e.g., while today's date <= 30/6/2006).
So suppose an agreement gives Alice permission to print a file f and, if she
prints it more than 100 times, then she has to pay 5 dollars.  We'd write
this as permission=print, asset = f, duty = pay, object (of duty) = 5
dollars, and constraint (of duty) = number_of_copies_by_consumer <= 100.
Yes?

Best,
Vicky          
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060603/bc8c5ba5/attachment.html