- From: Renato Iannella <r@iannel.la>
- Date: Fri, 24 Apr 2020 22:23:43 +1000
- To: "public-odrl@w3.org" <public-odrl@w3.org>, Adam Retter <adam@evolvedbinary.com>
- Cc: "Garmendia, Jone" <Jone.Garmendia@nationalarchives.gov.uk>, "Lawrence, Faith" <faith.lawrence@nationalarchives.gov.uk>, "Janes, Andrew" <andrew.janes@nationalarchives.gov.uk>, "Whittam Smith, Benedict (Refinitiv)" <benedict.whittamsmith@refinitiv.com>
- Message-Id: <3206D201-1869-41CF-976B-4503447F2576@iannel.la>
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