Re: Licences in ODRL

> On 21 Jan 2017, at 03:28, Phil Archer <phila@w3.org> wrote:
> That's three specific assets, not general classes of asset. What I think is needed here, though, is the inverse target method [6] that was added following issue 61 [7]. That is, I think BYTE should probably be looking at using dcterms:license to point *from* any asset that is licensed as ccBy *to* <http://dalicc.at/licence/CC-BY_4.0 and then *not* including any target info in the Policy.
> Correct?

Sure, you can do both. You can explicitly add the target Assets, or use dc:license to infer the Assets (and use the Policy for “instant licenses”).

> And am I right that we should use the odrl:Set sub class of odrl:Policy?

It depends on what the final semantics of the policy is. 
Since there is no mention of parties, then you can’t really use Offer or Agreement. So Set is the most generic.

> Now to add the Permission, which has a number of permitted actions:
> :CC-BY_4.0 a odrl:Set
>  odrl:permission [
>    a odrl:Permission;
>    odrl:action odrl:display, odrl:distribute, odrl:reproduce,
>       odrl:extract, odrl:derive, odrl:present
>  ] .

odrl:present is the parent for odrl:display, so you can leave that out.


> So far so good I hope. Now to add in the duty, and I'll start with just one of them:
> 
> :CC-BY_4.0 a odrl:Set;
>  odrl:permission [
>    a odrl:Permission;
>    odrl:action odrl:display, odrl:distribute, odrl:reproduce,
>       odrl:extract, odrl:derive, odrl:present;
> 
>       odrl:duty [
>         a odrl:Duty;
>   odrl:action odrl:attachSource
>       ]
> 
>  ] .
> 
> Hmm... odrl:attachSource is deprecated in favour of cc:SourceCode [8] but, more than that, it refers specifically to source code. Is that appropriate in an encoding of something as general as ccBY??

(We deprecated the CC terms used by ODRL - in favour of using direct CC URIs.)

CC REL defines cc:SourceCode duty as: "cc:SourceCode – when redistributing this work (which is expected to be software when this requirement is used), source code must be provided.”


>      odrl:duty [
>        a odrl:Duty;
>        dalicc:action dalicc:attachLicense
>      ]
>  ] .
> 
> OK, I don't know what the dalicc terms mean so I'll take them as read, but a question for BYTE - how does dalicc:action differ from odrl:action?

You can use cc:Notice (for dalicc:attachLicense)

> Let's add in the rest:
>       odrl:duty [
>         a odrl:Duty;
>         dalicc:action dalicc:attachLicense;
>         odrl:action [
>           a cc:Notice;
>           dalicc:action dalicc:copyrightNotice, dalicc:licenseNotice,
>           dalicc:noWarrantyNotice, dalicc:modificationNotice,
>           dalicc:creatorNotice
>         ], [
>           a odrl:attribute;
>           dalicc:action dalicc:worldwide, dalicc:royaltyFree,
>           dalicc:nonSublicensable, dalicc:nonExclusive,
>           dalicc:irrevocable
>     ]
>       ]
>  ] .

I think the last two actions are not correct Duties. They seem to be a list of actions on actions?
For example, “worldwide” should be expressed as a spatial constraint.
Irrevocable is also a Duty on the assigner not assignee.

Perhaps the use case for this example can be shared??

Renato Iannella, Monegraph
Co-Chair, W3C Permissions & Obligations Expression (POE) Working Group