Comments on one requirement

Dear all,

During this week's call I had been assigned the task to further clarify 
one requirement. I'll do my best to fulfill it here.
If you have problems reading HTML in the email, please tell me and I 
will be happy to post this content somewhere else.


*1. Use case and requirement
*The requirement derived from the POE.UC.01 reads: "/Ability to express 
conditions based on the user nature (academic, commercial, etc.)/" (link 
<https://www.w3.org/2016/poe/wiki/Use_Cases#POE.UC.01_Permissions_and_obligations_for_language_resources>)

*2. Further clarification of the requirement
*The term "condition" is unclear.
I am sorry to have used this ODRL1.1 term, then defined as 
"/...exceptions that are conditional events that, if become true (or 
occur), render the Permissions as no longer valid/" (link 
<https://www.w3.org/TR/odrl/#42305>).
I propose the reformulation of the requirement as:
/
Ability to express constraints on arbitrary properties of the party. /

The requirement is very easy to satisfy with ODRL 2.1 (see Section 2.8 
of the ODRL 2.1 Model here 
<https://www.w3.org/community/odrl/model/2.1/#section-28>):

    /"//The Constraint entity indicates limits and restrictions to the
    Permission, the Prohibition and the Duty entity//" [...] /
    /"The Constraint entity contains the following attributes: /
    /name: a name that identifies the the /(sic)/left operand of the
    operation (REQUIRED)/
    /operator: an operator function (REQUIRED)/
    /rightOperand: the right operand of the operation (REQUIRED)/

There is a set of 25 names for the constraint defined in the ODRL 2.1 
Vocabulary (here 
<https://www.w3.org/community/odrl/vocab/2-1/#section-23>). *None* 
satisfies the requirement as described above.
Having this in mind, the following structure is possible by adding a new 
name ms:academicUser with the meaning: "/if the user is an academic user/".

:myPolicy a odrl:Set ; odrl:permission [ odrl:action odrl:read ; 
odrl:target ms:languageResource ; odrl:constraint [ odrl:operator 
odrl:eq ; ms:academicUser "true"^^xsd:boolean ; ] ; ] .


*3. Seeking generality*
We can advance a number of uses and consequently propose a number of new 
"requirement names" I claim this is an awkward option, and that there 
should be a general mechanism to  evaluate generic properties, of either 
the assignee, the asset and possibly external entities (context). 
Actually, the existing 25 types of restrictions are heterogenous. Please 
see the list I have elaborated below.

absolutePosition    Asset
absoluteSize        Asset
count               Context
dateTime            Context
fileFormat          Asset
industry            Context? Assignee?
language            Asset
deliveryChannel     Context
elapsedTime         Context
event               Context
media               Asset
meteredTime         Context
payAmount           Assignee
percentage          Context
product             Context
purpose             Context
recipient           Party
relativePosition    Context
relativeSize        Context
resolution          Context
spatial             Context
timeInterval        Context
systemDevice        Context
version             Asset
virtualLocation     Context

*4. Proposed solution (but not part of the discussion now)*
I propose a modification on the Constraint elements. The current 
attributes are:

  * |name|: a name that identifies the the left operand of the operation
    (REQUIRED)
  * |operator|: an operator function (REQUIRED)
  * |rightOperand|: the right operand of the operation (REQUIRED)
  * |dataType|: the datatype of the rightOperand (OPTIONAL)
  * |unit|: the units of the rightOperand (OPTIONAL)
  * |status|: the current value of the left operand (OPTIONAL)

I suggest the following modification:

  * |name|: a name that identifies the the left operand of the operation
    (REQUIRED)
  * |entity|: entity whose property is to be evaluated (REQUIRED)
  * |leftOperand|: property to be evaluated (REQUIRED)
  * |operator|: an operator function (REQUIRED)
  * |rightOperand|: the right operand of the operation (REQUIRED)
  * |dataType|: the datatype of the rightOperand (OPTIONAL)
  * |unit|: the units of the rightOperand (OPTIONAL)
  * |status|: the current value of the left operand (OPTIONAL)

Enabling thus the following

:myPolicy a odrl:Set ; odrl:permission [ odrl:action odrl:read ; 
odrl:target _*ex:AdultContent*_ ; odrl:constraint [ odrl:entity 
_*odrl:assignee*_ odrl:leftOperand *_foaf:age_* ;odrl:geq *_18_* ; ] ; ] .


Please note that I have slightly changed the RDF version. Please also 
note that this information can be very easily represented in XML and 
JSON as well.

*5. About Groups and Redundancies
*During the call, it was objected that groups are explicitly handled by 
ODRL with the "group" mechanism succintly described in Section 2.3.1 of 
the ODRL model spec (https://www.w3.org/community/odrl/model/2-1/).
It can be argued, though, that the groups may not be made explicit in 
every situation, either because of the "group" is something dynamic or 
because the number of possible "groups" is too large.
Redunancies: unfortunately, as of today, there are plenty of 
redundancies (alternative ways of expressing the same). This email seeks 
in fact to reduce redundancies by making them explicit first.

*6. Further info
*For more information, you may also want to see the "ODRL Reference 
Card" that I produced last year (link 
<http://www.lider-project.eu/sites/default/files/referencecards/Licensing-ODRL-reference-card-v3.pdf>) 
describing "how to use ODRL by publishers of language resources" or the 
paper "Digital Representation of Rights for Language Resources" 
presented in July 2015 (link 
<http://www.aclweb.org/anthology/W/W15/W15-4206.pdf>). This proposal of 
generality, however, is new and it has not been made before.

Regards,
Víctor




-- 
Víctor Rodríguez-Doncel
D3205 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
ETS de Ingenieros Informáticos
Universidad Politécnica de Madrid

Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, Spain
Tel. (+34) 91336 3753
Skype: vroddon3