Actions (Permission/Prohibition and Duty) - editorial issues

[nitmws]

Going over the definitions of Actions for Permission-Prohibition and for Duty in Vocab Editor's Draft I see these issues should be solved, correcting typos and minimal changes are not included. It covers also the raised issue of the use of RFC2119. (TOC numbers are based on the Vocab Editor's Draft of 11 May)

Permission-Prohibition

• Use (4.12.1): remove "the" in Note: ... by the narrower actions.
• Archive (4.12.6) change Note to: Temporal constraints may be used for temporal conditions
• Semantics of Distribute (4.12.11), Move (4.12.18) and Reproduce (4.12.23): quite clear is Move: the (only) copy of the asset goes from A to B, nothing remains at A. Reproduce covers only making a copy of the asset but nothing about the use of this copy. If the use of the copy should be defined by another constraint we would tell that in a Note. (Practical note: is a realistic to define a constraint for such a common action like creating a copy? I guess not Assignee can guarantee that the provided digital asset will only be moved and never copied.) And what exactly is Distribute? Something like moving a reproduced copy from A to B (or many Bs)? These three actions need reconciled semantics.
• Modify (4.12.17) Definition ... to update existing content ... : "updating" is a specific purpose of modifying digital data - it is more constraining than "modify" on its own. I suggest to replace it by "change".
• Translate (4.12.29) explains in the Note that a "new derivative Asset" is created. By that I suggest to make Translate a narrower term of Derive.

Duty

• Compensate (4.14.3) Definition: "... for use of the Asset". ODRL actions vocab has two top concepts: "use" (= for a licensed use) and "transfer" (for handing over ownership) with "give" (for free) and "sell" as narrower concepts. Therefore I suggest: "... for using or selling of the Asset"
• Delete (4.13.4.): The semantics leave it open WHEN the copies have to be removed in a generic way like "... of the Asset after it has been used". And the Notes must say "... the Asset must be deleted." as this is required by the definition.
• Obtain Consent (4.14.9): the definition should outline how the consent should be obtained, the current definition could be interpreted as wide open but then it is also unclear and could be interpreted differently easily.
• Uninstall (4.14.11): The semantics leave it open WHEN the program has to be uninstalled. Should have a similar Note as Delete.
• Watermark (4.14.12) - Note: embed a link to what - and how??

[vroddon]

Partially implemented in Revision: 28689e1

@nitmws All the points have been implemented, except the following:

• Obtain Consent (4.14.9): the definition should outline how the consent should be obtained, the current definition could be interpreted as wide open but then it is also unclear and could be interpreted differently easily.

NOTE DONE - UNCLEAR

• Watermark (4.14.12) - Note: embed a link to what - and how??

NOT DONE. What should we do then?

• Semantics of Distribute (4.12.11), Move (4.12.18) and Reproduce (4.12.23): quite clear is Move: the (only) copy of the asset goes from A to B, nothing remains at A. Reproduce covers only making a copy of the asset but nothing about the use of this copy. If the use of the copy should be defined by another constraint we would tell that in a Note. (Practical note: is a realistic to define a constraint for such a common action like creating a copy? I guess not Assignee can guarantee that the provided digital asset will only be moved and never copied.) And what exactly is Distribute? Something like moving a reproduced copy from A to B (or many Bs)? These three actions need reconciled semantics.

NOT DONE - UNCLEAR

[riannella]

obtainConsent - I don't think we can say how this is obtained - as there are too many different ways - we can really only say that it must be obtained. The example says you could use a consenting Party (to contact) for example.

watermark - I am not sure the note make sense. I recommend we remove the note.

reproduce - is like a copy function (but does not necessarily mean exact copies always)
distribute - is making such copies widely available (eg for sale) to the public
(you typically need both in music contracts, for example)

I propose updated definitions for:
reproduce - The Assigner permits/prohibits the Assignee(s) to make duplicate copies the Asset (with note: Copies may not be exact and my be partial copies)
distribute - The Assigner permits/prohibits the Assignees to supply the Asset(s) to the public
(with note: this action may require other actions to make duplicate copies of the Asset.)
(so this latter one is purposely semantically different than others, see #101, being for the public )

move is one of the original terms when operating-system level actions, like install, were in vogue.

[nitmws]

re @riannella

• obtainConsent: I think a minimal requirement of "obtaining a documented consent" would help as in the legal context documentation of actions is essential.
• watermark: I support to remove the note
• reproduce: I agree to the outlined change of the definition. But how to express what may/not be done with the duplicate of the copy? Such a duplicate is not made without any purpose. And: I disagree to the note as it tends to overlap with the Actions derive and transform.
• distribute - a note with my news industry hat: distribution is there primarily supplying the Asset(s) to business partners and not the public. A practical note: "distribute" should include the permission to create duplicates of the copy held by the Assigner, else distribution would not be possible - and we should include this in the definition.
• move: you see no need to change anything? I support that.

[riannella]

obtainConsent

• what about "...verifiable consent..." ?

reproduce

• use a constraint? reproduce 1000 copies, recipient =uni students ?
• ok, remove note.
• updated definition: "The Assigner permits/prohibits the Assignee(s) to make duplicate copies the Asset in any material form"
• this also means I can reproduce a digital audio file onto a vinyl record.

distribute

• if you wanted both actions (reproduce and distribute) then you would simply add both to the Rule? Even though a single party could do both, they are seperate actions still. In my music use case, one party could do the reproduction (eg audio to vinyl 1000 copies) and another org does the distribution (eg sony).
• updated definition: "The Assigner permits/prohibits the Assignees to supply the Asset to third-parties"
• add a note: "it is recommended to use nextPolicy to express the allowable usages by third-parties.

[vroddon]

Implemented by commit 86da7ad

• note of watermark removed
• updated definitions for distribute and obtainConsent
• added note to distribute

I dont close just in case @nitmws has further comments.