Re: Guidance on using ORDL for Archival Records

Thanks, Alapan. I'm so happy to see people working with ODRL.

Some of the ODRL Prohibition cases I recall were:

 For example: a publisher may need to restrict publication in certain countries due to sub-rights--"No publishing in China"

 Another example: a Publisher may wish to express a restriction use of published material for generating Machine-learning models.

The information below is from my earlier notes:

RightsML 1.0 Example: Exclude a country from licensing (photo)

The Business Scenario
XYZ is a global news agency, licensing images directly to customers around the world. Customers are permitted to license the images in all countries except where the use is specifically denied for a specific country.

A Specific Business Case
XYZ Images distribute an image to customers in all countries except China, and grants customers permission to license the image in all countries except China, in return for an agreed fee.

The License as Natural Language Expression
XYZ Images is the assigner and permits that a photo referencing this policy (by e.g. its embedded metadata) is distributed (in the news industry sense) to any country except China. This photo may also be sold in any country except China.

The License as RightsML/ODRL Expression

<o:policy uid="http://gimages.info/cv/policy/1 <http://gimages.info/cv/policy/1>"
    type="http://w3.org/ns/odrl/vocab <http://w3.org/ns/odrl/vocab>#set"
    xmlns:o="http://w3.org/ns/odrl/2/ <http://w3.org/ns/odrl/2/>"
    xmlns:ov="http://w3.org/ns/odrl/vocab <http://w3.org/ns/odrl/vocab>#"
    xmlns:rml="http://iptc.org/std/RightsML/2011-10-07/ <http://iptc.org/std/RightsML/2011-10-07/>"
    xmlns:foo="http://example.com/RightsMLvocabulary <http://example.com/RightsMLvocabulary>" >
    <o:permission>
      <o:asset uid="*" relation="ov:target"/>
      <o:action name="rml:distribute"/>
      <o:constraint name="ov:spatial" operator="ov:neq" rightOperand="iso3166:CN"/>
      <o:party id="gim" uid="http://companyreg.com/gim <http://companyreg.com/gim>" function="ov:assigner"/>
      <o:party id="cli1" uid="http://companyreg.com/client1 <http://companyreg.com/client1>" function="ov:assignee"/>
    </o:permission>
    <o:permission>
      <o:asset uid="*" relation="ov:target"/>
      <o:action name="ov:sell"/>
      <o:constraint name="ov:spatial" operator="ov:neq" rightOperand="iso3166:CN"/>
      <o:party idref="gim"/>
      <o:party idref="cli1"/>
    </o:permission>
</o:policy>


Required and/or Special Resources
- A vocabulary of country names







> On Apr 21, 2020, at 10:30 AM, Alapan <alapan@gmail.com> wrote:
> 
> I can comment on prohibitions as I introduced them - although I have not kept close track of ODRL for a while.
> 
> For an example - let’s take a document which we want to the user to be able to read but not print.
> 
> If we only have the permission model; there is a grey case where a system that could interpret unspecified restrictions as allow if possible, or because it has no technical means to enforce (as opposed to prohibit if not specified). 
> 
> The idea for the prohibition was to have explicit restrictions that could also be used to evaluate whether the enforcement mechanism could enforce such prohibitions and if not; not enable the system for usage. 
> 
> It also allowed for some use cases of allow everything except A B and C.
> 
> Hope this helps
> 
> Alapan
> 
> On Tue, Apr 21, 2020 at 10:15 Whittam Smith, Benedict (Refinitiv) <benedict.whittamsmith@refinitiv.com <mailto:benedict.whittamsmith@refinitiv.com>> wrote:
> Hi Adam,
> 
> Yes, I think prohibitions were originally introduced into ODRL to help sharpen the granularity of permissions. 
> 
> They've developed a little since then with the introduction of their odrl:remedy property, which can be useful when modelling regulations. But I think prohibitions in ODRL (and conflict resolution) still need a little more TLC before really coming into their own.
> 
> Ben
> 
> 
> 
> 
> From: Adam Retter <adam@evolvedbinary.com <mailto:adam@evolvedbinary.com>>
> Sent: 21 April 2020 14:29
> To: Whittam Smith, Benedict (Refinitiv) <benedict.whittamsmith@refinitiv.com <mailto:benedict.whittamsmith@refinitiv.com>>
> Cc: public-odrl@w3.org <mailto:public-odrl@w3.org> <public-odrl@w3.org <mailto:public-odrl@w3.org>>; Garmendia, Jone <Jone.Garmendia@nationalarchives.gov.uk <mailto:Jone.Garmendia@nationalarchives.gov.uk>>; Lawrence, Faith <faith.lawrence@nationalarchives.gov.uk <mailto:faith.lawrence@nationalarchives.gov.uk>>; Janes, Andrew <andrew.janes@nationalarchives.gov.uk <mailto:andrew.janes@nationalarchives.gov.uk>>
> Subject: Re: Guidance on using ORDL for Archival Records
>  
> Thanks for your reply Ben, I have some further comments/questions
> inline below...
> 
> > If I'm reading your description correctly you have three "states" to cover:
> >
> > 1) Records in which both the description and the content can be read
> > 2) Records in which the description can be read but not the content
> > 3) Records in which neither the description nor the contents can be read
> >
> > Also, records can change state, either through the passage of time, or through a review.
> 
> Yes that's about right. We actually model records as immutable, so we
> have versions of records, when the state changes we generate a new
> version of the record which describes the new state.
> 
> 
> > I like to keep things really simple if I can. So I'm going to try and satisfy these requirements without recourse to inheritance, conflict resolution, or prohibitions. I don't think we need them. ODRL is a closed world - if a permission to do something doesn't exist, you can't do it.
> 
> Simple is good! I am wondering why ODRL would need Prohibitions at all
> if it is a closed world? Are they needed to refine the granularity of
> Permissions?
> 
> 
> > Instead, I'd split the asset - the record - so we have two assets: the description and the whole record.
> 
> I need to give this some thought. I am not sure it is easy for us to
> split the asset.
> 
> At the moment the asset has two things, aspects: 1. abstract concept
> (the enduring form of the record), this has no description, and 2) one
> or more descriptions of the record (Where each one is a revision of a
> past one). The issue is that "the physical record" i.e. "the document"
> is modelled by a manifestation, as we may have one or more
> manifestations of a record through time also.
> 
> Perhaps some of our ODRL policies should refer to a description of the
> record, whilst some should refer to a manifestation of a record.
> 
> Your approach is certainly appealing though...
> 
> 
> --
> Adam Retter
> Director @ Evolved Binary
>