[Odrl-version2] Core Model: Roles, Parties and Assets

[David Martin]

Hmm - not a natural way of looking at it from our standpoint, but I can 
see that it could work for this use case.

However, we foresee that there could be many ways in which a resource 
other than the primary Asset is related to an Action, even if in the 
areas we have so far explored in depth we have only encountered a few. 
So our Usage model is completely unlimited in terms of the number of 
resources with the same or different roles that we can associate with an 
Action.

We have so far discussed a resource in which a copy of the Asset can be 
inserted by an include Action.  Another use case could involve a new 
resource which has been created by an Action of some other type.

The first of these is fairly easy to consider as a Constraint.  The 
second is more difficult.  As an example of a use case, we currently 
deal with the way some publishers express a data mining permission by 
specifying "access by crawler" to a "licensed content" Asset (eg a 
database of subscribed online journals) creating a new resource 
"downloaded licensed content".  We then have a second permission 
allowing the use of the "downloaded licensed content" (the Asset in this 
second permission) for data mining, usually with some constraints on 
retention of the downloaded data, and possibly some further permissions 
and/or prohibitions on the use of the output of the data mining process. 
So at each stage we need to identify the output of one Action so that it 
can be used as the Asset in the next Action.  That doesn't sound like a 
Constraint.

How would ODRL handle a requirement to identify a new resource that is 
created by an Action, so that it can be referred to in subsequent 
Actions?

David


In message <050D1E2F-6344-4C66-B0DA-7EF0D9705C0D at odrl.net>, 
"ri at odrl.net" <ri at odrl.net> writes
>On 10 Nov 2010, at 19:49, David Martin wrote:
>
>> Renato, I don't think it is helpful to get hung up on a particular 
>>action/usage type, or a particular use case.  "Include" isn't the only 
>>one that can involve secondary assets, and I'm sure there will be 
>>others we haven't come across yet.
>
>I am trying to better understand the use case to determine how the 
>*current* model could apply...
>
>The current ODRL model utilises Constraints to "restrict" the 
>Permissions. I am trying to ascertain if this would work in this case, 
>and future cases, where the action is about "other assets".
>
>If "include" means "The act of including other assets with the asset" - 
>by itself, this would allow you to literally include any asset with the 
>asset.
>
>If we had a (new) "resource" constraint, then we could apply this to 
>"include" and others.
>
>Example:
>
>  <o:permission>
>        <o:asset uid="urn:journal-x:article5"/>
>        <o:action name="o:include"/>
>        <o:constraint name="o:resource" operator="o:eq" 
>rightOperand="onix:thesis"/>
>        ...
>  </o:permission>
>
>
>Cheers
>
>Renato Iannella
>ODRL Initiative
>http://odrl.net
>
>
>
>_______________________________________________
>Odrl-version2 mailing list
>Odrl-version2 at odrl.net
>http://odrl.net/mailman/listinfo/odrl-version2_odrl.net
>
>
>-----
>No virus found in this message.
>Checked by AVG - www.avg.com
>Version: 10.0.1153 / Virus Database: 424/3249 - Release Date: 11/10/10
>

-- 
David Martin
david at polecat.dircon.co.uk

Address in UK
117 Percy Road, HAMPTON TW12 2JS, UK
Telephone +44 (0)20 8286 8983 (or 8979 2516, if no reply)

In Tenerife
Rambla de Santa Cruz 153, Sexto, Puerta 21, 38001 Santa Cruz de Tenerife, SPAIN
Telephone +34 922 27 23 92
Mobile (in Spain only) +34 639 742 634