Re: Guidance on using ORDL for Archival Records

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
________________________________
From: Adam Retter <adam@evolvedbinary.com>
Sent: 17 April 2020 17:53
To: public-odrl@w3.org <public-odrl@w3.org>
Cc: Garmendia, Jone <Jone.Garmendia@nationalarchives.gov.uk>; Lawrence, Faith <faith.lawrence@nationalarchives.gov.uk>; Janes, Andrew <andrew.janes@nationalarchives.gov.uk>
Subject: Guidance on using ORDL for Archival Records

Hi there,

I am working with The National Archives in the UK and I have been
looking into ORDL for the purpose of describing the access rights of
'members of the public' to Archival Records.

At the moment our access conditions are relatively simple. A record is
considered to have either:

1. Open Document and Open Description
2. Closed Document and Open Description
3. Closed Document and Closed Description

The "Description" is the metadata about the document, for example:
"This record contains details of some person at some time on the topic
of something", whereas the "Document" is the actual paper (or digital)
document itself.

The public 'members of the public' are only allowed unfettered access
to "Open" Descriptions and/or "Descriptions".

When Documents or Descriptions are "Closed", they have criteria about
when they will be reviewed for "Opening", or when they will naturally
transition to become "Open".

At the moment our needs are quite modest, however we want to be able
to add more complex rules in future, hence the look at ORDL.

I am looking for some guidance on whether I am using ORDL correctly or not?

I have attempted to model some examples of policies for our records.
The examples are expressed in Turtle RDF.

Firstly we have some basic actions and general policies:

# Example 1 - for Record10 which is "Open Immediatedly", and therefore
"Open Document, Open Description"
cat:read-description
  a ordl:Action ;
  ordl:includedIn ordl:read ;
  dct:description "The action of reading the description of a Document" ;
..

cat:read-document
  a ordl:Action ;
  ordl:includedIn ordl:read ;
  odrl:implies cat:read-description ; # NOTE: Reading a document
implies reading description
  dct:description "The action of reading a Document" ;
..

cat:base-records-policy
  a ordl:Set ;
  ordl:profile https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fodrl%2F2%2Fcore&amp;data=02%7C01%7Cbenedict.whittamsmith%40refinitiv.com%7Ca4a37d80908b47e8ea0c08d7e30273d3%7C71ad2f6261e244fc9e8586c2827f6de9%7C0%7C0%7C637227472001173238&amp;sdata=qv2elhTyya45yhOYccHxcnIx%2BcKqxGo47t44j%2FEIsqg%3D&amp;reserved=0 ;
  ordl:assigner cat:TNA ;
  dct:creator cat:TNA ;
  dct:description "Base policy for records of The National Archives";
..

cat:read-document-policy
  a ordl:Offer ;
  dct:creator cat:TNA ;
  dct:description "Policy for reading the record"; # e.g. Open
Document, Open Description
  ordl:inheritFrom cat:base-records-policy ;
  ordl:action cat:read-document ;
..

cat:read-description-policy
  a ordl:Offer ;
  dct:creator cat:TNA ;
  dct:description "Policy for reading the description of a record"; #
e.g. Closed Document, Open Description
  ordl:inheritFrom cat:base-records-policy ;
  ordl:action cat:read-description ;
..

Then we have some concrete examples of describing policies for each record:

# Example 1. For Record10 which is "Open Immediately", and therefore
"Open Document, Open Description"
cat:record10-policy
  a ordl:Offer ;
    dct:description "Open Immediately" ;
    ordl:inheritFrom cat:read-document-policy ;
    ordl:permission [
    a ordl:Permission ;
    ordl:target cat:Record10 ;
  ] ;
..

# Example 2. For Record30 which is "Closed whilst access is reviewed"
and therefore "Closed Document, Closed Description"
cat:record30-policy
  a ordl:Offer ;
  dct:description "Closed whilst access is reviewed" ;
  ordl:inheritFrom cat:read-document-policy ;
  ordl:prohibit [
    a ordl:Prohibition ;
    ordl:target cat:Record30 ;
  ] ;
..

# Example3 . For Record60 which is "Closed until" and considered
"Closed Document, Open Description"
cat:record60-policy
  a ordl:Offer ;
  dct:description "Closed until 2099" ; # TODO is there a better way
to hold the year?
  ordl:inheritFrom cat:read-document-policy ;
  ordl:conflict perm ;
  ordl:prohibit [
    a ordl:Prohibition ;
    ordl:target cat:Record60 ;
    ordl:constraint [
      a ordl:Constraint ;
      dct:description "Record Opening Date" ;
      ordl:leftOperand ordl:dateTime ;
      ordl:operator ordl:le ;
      ordl:rightOperand "2099-01-01"^xsd:date ;
    ] ;
  ] ;
  ordl:permission [
    a ordl:Permission ;
    dct:description "Open Description" ;
    ordl:action cat:read-description-policy ; # TODO does this
override the prohibition of  cat:read-description-policy which is
inheited above, as we also used `ordl:conflict perm` above?
    ordl:target cat:Record60 ;
  ] ;
..

The question I have are:

1. Do these examples look sensible in the way that we have used ORDL?
2. In Example 3, is there a better way to express the 2099 years as
opposed to writing it in the description?
3. In Example 3, whilst the ordl:prohibit blocks reading the document
(as that action is inherited) and blocks reading the description (as
that action is implied in the inherited action), does the
ordl:permission correctly override that to just allow reading the
description?


Thanks for your time. Adam.

--
Adam Retter
Director @ Evolved Binary

Received on Tuesday, 21 April 2020 13:11:35 UTC