Re: ODRL enforcement implementation

Hi Andrea, Joshua, all.

Andrea - I think it was your colleague Juan who presented this work at 
the NXDG workshop in SEMANTiCS conference recently. I did not have a 
chance to discuss this aspect, so hopefully this email conveys it.

In ODRL, when considering implementation/verification, the constraints 
can be seen as a rule over the triple where the action is the subject, 
and the left operand is the predicate and the right operand is the 
object. The operator then describes what is the valid combination of 
predicate and subject. Note that I'm not saying this is how it always 
is, just that it helps (me) to think about how to write implementations 
for ODRL validation.

So when you defined a new constraint in this form: <time> <between> 
<time> - there is a loss of semantic information as this triple is not 
attached to the subject action. That is, it isn't clear from the 
constraint *which datetime is being referenced*.

Consider a graph of the form: <action> <datetime> <value> - the defined 
constraint does NOT have any semantics defined through which it can 
determine whether to assess this triple or not as the left operand is 
now a value rather than a predicate. That is, <datetime> predicate is 
not present in the constraint at all.

Instead, a more explicit and IMHO correct expression would be of the 
form <odrl:dateTime> <otime:between> <interval> where the interval can 
be defined using the TIME ontology standard (preferably) or as a list of 
two datetime instances (start and end).

So given a graph of the form: <action> <datetime> <value> - the 
implementor sees a rule matching <datetime> and then checks whether 
<value> satisfies the operator (between) and right operand (interval) in 
the constraint.

Regards,
Harsh



On 30/09/2024 11:40, Andrea Cimmino wrote:
> Dear Joshua,
> 
> Thanks for your email and questions, your suggestions are really welcome.
> 
> Bear in mind that the implementation and the examples in the repository 
> are used to test different features and therefore you may find policies 
> with both operators as constants that may not make sense in real world 
> scenarios. Others, like the one you are mentioning are meant to show how 
> it is possible to extend ODRL with domain specific operands and 
> operators and make the implementation aware of these extensions. In this 
> case, otime:between checks whether the current time is between the left 
> and right operand time marks, this time dimension is expressed as hour, 
> minutes, and seconds. Of course, there could be other ways of 
> representing the idea of a time range, but again, this is an example on 
> how ODRL and the implementation can be extended with new behaviors. For 
> instance, in xsd already exist a datatype for time duration.  The 
> approach you suggested, thanks for the feedback, is actually interesting 
> and seems promising for a specific time case.
> 
> However, I would like to highlight a few points. The usage of 
> odrl:dateTime introduces two dimensions, a date and a time, the example 
> policy you mentioned is actually meant to check a time range without the 
> date dimension. This makes not possible to use the operand odrl:dateTime 
> since, according to the ontology, it follows the xsd:date or 
> xsd:dateTime datatypes which do not allow to express uniquely time. 
> Actually, we cannot compare a xsd:dateTime value and a xsd:time value 
> since the later does not have a date making impossible to compare its 
> value with the former one. Due to this reason, we showcase how to extend 
> ODRL to overcome this limitation by defining a policy with a new operand 
> that operates only with the time dimension and has more domain specific 
> semantics. We are sure this is not the only way of achieving this 
> result, but our goal was to show that is possible to extend the ontology 
> and behavior of the implementation.
> 
> About the operators, you are right, there are some we are not 
> implementing because they are too abstract and there is (or we do not 
> find it) a general way to implement them and make them work for any 
> application domain. The odre library allows practitioners to implement 
> them depending on their specific use cases, however, we believe it would 
> be better to define more specific sub operators to avoid implementations 
> having different interpretations of these operators. This suggestion is 
> also aligned with good ontological practices, for instance, those 
> defined in the LoT methodology. A good example of this is precisely the 
> fact that we need otime:between, we could have set two constraints 
> specifying odrl:dateTime is greater than and less than two 
> rightOperands. However, these operators, odrl:gt and odrl:lt, would 
> compare a xsd:datetime value with a xsd:time value  which is not 
> possible. The semantics of odrl:lt and odrl:gt are too abstract. We, as 
> humans, can understand that /less than/ between two numbers behaves in a 
> certain way and /less than/ between two dates behaves in a different way 
> but ontologically speaking there should be defined two sub operators of 
> less than called (maybe) numeric less than and datetime less than since 
> from the implementation point of view they are achieved differently (we 
> have a more in depth discussion about this issue, and others, in the 
> article). Due to this reason, we really implemented only the comparison 
> operators trying to be as more flexible as possible with the datatypes 
> they compare but recognizing the need of more specific domain 
> semantics. In particular, the implementation supports values in numeric 
> datatypes of datetime but for instance if you try to compare two time 
> periods the implementation does not supports it, since /less than/ 
> between two periods is not a trivial comparison. However, odre gives you 
> extension mechanisms to include this new use case, and this is the 
> essence of the example policy you mentioned.
> 
> About your las comment, "From the document, it seems to be mixing the 
> “context” with policy definition, IMHO – that isn’t necessary and has 
> the potential to introduce significant security risks downstream 
> (authorisation models clear-cut separate definition from state).”  I’m 
> not sure to understand your point, I will try to answer as better as I 
> can but please if I do not solve your question let me know.  As it is 
> now endowed ODRL operands can be values or terms from the ontology. 
> There is no specific mechanism to hide values in the policies besides 
> the usage of the operands that are terms from the ontology. We also 
> address this in the article by allowing to express policies mixing RDF 
> and another language, like a templating one, so policies can have data 
> dynamic values that do not appear explicitly in the policy but that are 
> injected in the enforcement moment. An example can be found in the 
> article, in Listing 2 or any above. For instance, in Listing 2 we 
> specify a policy that compares tokens without knowing the value of the 
> user token; in this example we could apply the same strategy to the 
> reference token known by the machine and have a policy that actually 
> shows no values.
> 
> Best regards,
> Andrea C.
> 
> UNIVERSIDAD POLITÉCNICA DE MADRID <https://www.upm.es/>
> 
> Dr. Andrea Cimmino Arriaga
> 
> Profesor Permanente Laboral
> 
> Departamento de Sistemas Informáticos,
> Ontology Engineering Group
> 
> Campus Sur de la UPM.
> 
> C. de Alan Turing, s/n.28031,Madrid,Madrid SPAIN
> 
> ✉ andreajesus.cimmino@upm.es <mailto:andreajesus.cimmino@upm.es>
> 
> ✆ +34 671 09 06 24 <tel:+34-671-09-06-24>
> 
> Aviso / Disclaimer <https://www.upm.es/disclaimer> 🌳 🌳 Piensa antes de 
> imprimir.
> 
> 
>> El 30 sept 2024, a las 11:35, Joshua Cornejo <josh@marketdata.md 
>> <mailto:josh@marketdata.md>> escribió:
>>
>> Hi Andrea,
>> Checking and picking one example out of several from your github:
>>        "constraint": [{
>> *"leftOperand": { "@value": "06:55:00", "@type": "xsd:time" },*
>>            "operator": "otime:between",
>>            "rightOperand":  { "@value": "23:55:00", "@type": "xsd:time" }
>>        }]
>> I don’t understand the purpose of thisodrl:LeftOperandinstance that 
>> looks like a value for the definition of a “range constraint” ( I 
>> assume that’s the purpose based on the definition of the 
>> operatorotime:between)?
>> If you are representing a range:
>> …
>>        "and": {
>> **"@list": [
>> **{ "@id": "http://example.com/p:odre/Codre1" 
>> <https://urldefense.com/v3/__http://example.com/p:odre/Codre1*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jKg1gMNG$>},
>> **{ "@id": "http://example.com/p:odre/Codre2" 
>> <https://urldefense.com/v3/__http://example.com/p:odre/Codre2*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jI5xlX4Z$>}
>>             ]
>>        }
>> …
>>   {
>>      "@type": "Constraint",
>>      "uid": "http://example.com/p:odre/Codre1" 
>> <https://urldefense.com/v3/__http://example.com/p:odre/Codre1*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jKg1gMNG$>,
>> *           "*leftOperand*": "*dateTime*",*
>>            "operator": "odrl:gteq",
>>            "rightOperand":  {*"@value": "06:55:00", "@type": "xsd:time"*}
>>        }
>> …
>>   {
>>      "@type": "Constraint",
>>      "uid": "http://example.com/p:odre/Codre2" 
>> <https://urldefense.com/v3/__http://example.com/p:odre/Codre2*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jI5xlX4Z$>,
>> *           "*leftOperand*": "*dateTime*",*
>>            "operator": "odrl:lteq",
>>            "rightOperand":  {*"@value": “23:55:00", "@type": "xsd:time"*}
>>        }
>> You could also define a new operator odre:inRange and have your 
>> constraint be:
>>        "constraint": [{
>>            "leftOperand": “dateTime”,
>>            "operator": "*odre*:*inRange*",
>>            "rightOperand":  {< here define your range object, 
>> descendant from odrl:RightOperand >}
>>        }]
>> This simplifies the policy, but it has the extra step of creating a 
>> model that defines how odre:inRange is evaluated by others who want to 
>> implement it.
>> The examples also seem to be implementing only odrl:eq, odrl:lt, 
>> odrl:gt, odrl:lteq, odrl:gteq & odrl:neq (none of the other 6 operators?)
>> From the document, it seems to be mixing the “context” with policy 
>> definition, IMHO – that isn’t necessary and has the potential to 
>> introduce significant security risks downstream (authorisation models 
>> clear-cut separate definition from state).
>> Regards,
>> ___________________________________
>> *Joshua Cornejo*
>> *marketdata 
>> <https://urldefense.com/v3/__https://www.marketdata.md/__;!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jAvocg-E$>*
>> embed open standards
>> across your supply chain
>> *From:*Andrea Cimmino <andreajesus.cimmino@upm.es 
>> <mailto:andreajesus.cimmino@upm.es>>
>> *Date:*Monday 30 September 2024 at 09:41
>> *To:*<public-odrl@w3.org <mailto:public-odrl@w3.org>>
>> *Subject:*ODRL enforcement implementation
>> *Resent-From:*<public-odrl@w3.org <mailto:public-odrl@w3.org>>
>> *Resent-Date:*Mon, 30 Sep 2024 08:41:15 +0000
>>
>> Dear Community,From Universidad Politécnica de Madrid (UPM) we are 
>> pleased to present our ODRL enforcement proposal, we would like to 
>> share with you the GitHub organization 
>> <https://urldefense.com/v3/__https://github.com/ODRE-Framework/ODRE-Framework__;!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jEYhM8_F$> where you will find our python and java implementations for enforcing ODRL policies. These implementations are the proof-of-concept of the recently submitted research to the Computers & Security journal, in the case you might be interested you can have a look at our pre-print of this article <https://urldefense.com/v3/__https://arxiv.org/abs/2409.17602__;!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jAW3zQtJ$>.Any feedback or comment or new idea is more than welcome, also any collaboration.
>> Many thanks in advance.
>> Best regards,
>> Andrea C.
>>
>> *Image removed by sender. UNIVERSIDAD POLITÉCNICA DE MADRID* 
>> <https://www.upm.es/>
>>
>> *Dr. Andrea Cimmino Arriaga*
>>
>> /Profesor Permanente Laboral/
>>
>> Departamento de Sistemas Informáticos,
>> Ontology Engineering Group
>>
>> Campus Sur de la UPM.
>>
>> C. de Alan Turing, s/n.28031,Madrid,Madrid SPAIN
>>
>> ✉andreajesus.cimmino@upm.es <mailto:andreajesus.cimmino@upm.es>
>>
>> ✆+34 671 09 06 24 <tel:+34-671-09-06-24>
>>
>> Aviso / Disclaimer <https://www.upm.es/disclaimer> 🌳🌳 Piensa antes 
>> de imprimir.
>>
> 

-- 
---
Harshvardhan J. Pandit, Ph.D
Assistant Professor
ADAPT Centre, Dublin City University
https://harshp.com/

Received on Monday, 30 September 2024 11:43:51 UTC