Re: ODRL enforcement implementation

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.
 

 

 

 

 <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> 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 this odrl:LeftOperand instance that looks like a value for the definition of a “range constraint” ( I assume that’s the purpose based on the definition of the operator otime: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.
> 
>  <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.