Re: Guidance on using ORDL for Archival Records

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> 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>
> *Sent:* 21 April 2020 14:29
> *To:* Whittam Smith, Benedict (Refinitiv) <
> benedict.whittamsmith@refinitiv.com>
> *Cc:* public-odrl@w3.org <public-odrl@w3.org>; Garmendia, Jone <
> Jone.Garmendia@nationalarchives.gov.uk>; Lawrence, Faith <
> faith.lawrence@nationalarchives.gov.uk>; Janes, Andrew <
> 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
>
>