RE: Comments on one requirement

Hi Victor,

thanks for this rich comment on the UC.01 POE requirement 11.

 

** Re section 1-4:

 

I share most of your views, see also my comments on these Requirements

-          https://www.w3.org/2016/poe/wiki/Requirements#Define_how_constraints_on_a_party_can_be_expressed 

-          https://www.w3.org/2016/poe/wiki/Requirements#Add_.22party.22_to_Constraints_Vocabulary 

My view in short:

-          the current Constraint design is not clear about the subject of the constraint, in fact one has to read the free-text semantics of a constraint vocabulary term to get it.

-          to clarify that, something to explicitly define the subject is needed. How this is done exactly I leave open at the moment.

 

The next step is how to integrate that into the Use Cases: 

I think it would be best that you create a special Use Case for this matter of “Apply a constraint to a party” and maybe as a kind of close variant also for “Apply a constraint to a specific action” (UC.01 POE requirement 9). A more generic variant would be to create a Use Case “Apply a constraint to a specific part of a policy” and to integrate both cases just mentioned.

 

I’ve created Action-14 [1] for that.

OK?

 

** Re section 5:

I share your view that “how to deal with groups” needs clarification. For IPTC’s RightsML examples we have used for groups a party without a scope – e.g. [2] – assuming that at the time of checking this entity id it must be known that it stands for a group of persons.

My aside: the definition of Party in the ODRL Model needs a review: By the current definition “The Party entity is the object of an ODRL policy that performs (or not performs) actions or has a role in a Duty” an assigner or an attributedParty cannot be a party as this entity does not perform any action and does not take any duty.

 

Best,

Michael

 

[1] https://www.w3.org/2016/poe/track/actions/14

[2] http://dev.iptc.org/RightsML-Simple-Example-Geographic 

[3] https://www.w3.org/community/odrl/model/2-1/#section-23 

 

From: Víctor Rodríguez Doncel [mailto:vrodriguez@fi.upm.es] 
Sent: Friday, June 24, 2016 6:23 PM
To: 'W3C POE WG' <public-poe-wg@w3.org>
Subject: 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