Re: Guidance on using ORDL for Archival Records

Nice modelling Ben ;-)

A few comments:
1 - the operator for the 2099 year constraint should be odrl:gteq
2 - need to make it clear who is obliged to perform the Duty in cat:P3v2 - I would add an odrl:assignee of cat:TNA
3 - using AssetCollection is a good way define the Target - could also consider using some exisiting standard terms for the left/right Operands (eg dcmi:Type and dcmi:Description)

Cheers - Renato


> On 21 Apr 2020, at 23:11, Whittam Smith, Benedict (Refinitiv) <benedict.whittamsmith@refinitiv.com> wrote:
> 
> Hi Adam,
> 
> Thanks for your interest in ODRL. 
> 
> 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.
> 
> 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.
> 
> Also, I wouldn't split the read action, because you might then need to do the same for print, scan, or entity-extract ... Instead, I'd split the asset - the record - so we have two assets: the description and the whole record. I work with datasets, and we're often creating assets by segmenting datasets using constraints.
> 
> Then the simplest permission - example 1 - looks so:
> 
> cat:P1  a                odrl:Permission ;
>             odrl:action  odrl:read ;
>             odrl:target  cat:Record10 ...
> 
> The next - example 3, with access only to the description:
> 
> cat:P2  a                odrl:Permission ;
>             odrl:action  odrl:read ;
>             odrl:target  [   a                        odrl:AssetCollection ;
>                                   odrl:source        cat:Record60 ;
>                                   odrl:refinement  [    a                           odrl:Constraint ;
>                                                                  odrl:leftOperand   cat:contentType ;
>                                                                  odrl:operator         odrl:isA ;
>                                                                  odrl:rightOperand  cat:Description
>                                                              ] 
>                               ] .
> 
> The third state (example 2), where nothing can be read, does not need a permission - or a prohibition. 
> 
> But you can model "future permissions." If it's automatic and doesn't require a review we can construct a permission that only becomes valid on or after 2099 so:
> 
> cat:P3  a                      odrl:Permission ;
>             odrl:action        odrl:read ;
>             odrl:target        cat:Record60 ;
>             odrl:constraint  [    a                           odrl:Constraint ;
>                                           odrl:leftOperand   odrl:dateTime ;
>                                           odrl:operator        odrl:eq ;
>                                           odrl:rightOperand "2099-01-01T00:00Z"^^xsd:dateTime
>                                      ] .
> 
> If the record requires review, then we might use a duty to model this. Again, the permission only becomes valid once the duty is fulfilled:
> 
> cat:P3v2  a            odrl:Permission ;
>             odrl:action  odrl:read ;
>             odrl:target  cat:Record60 ;
>             odrl:duty    [   a                odrl:Duty ;
>                                   odrl:action  cat:ClearForRelease
>                               ] .
> 
> Then we can simply gather the permissions into a single offer:
> 
> cat:O1  a                        odrl:Offer ;
>              odrl:assigner     cat:TNA ;
>              odrl:permission cat:P-1 , cat:P-2 , cat:P-3 .
> 
> Others will likely have different opinions. Modelling, huh! Hope this helps,
> 
> Ben

Received on Friday, 24 April 2020 12:24:12 UTC