- From: Andrea Cimmino <andreajesus.cimmino@upm.es>
- Date: Mon, 30 Sep 2024 16:07:58 +0200
- To: "Harshvardhan J. Pandit" <me@harshp.com>
- Cc: Joshua Cornejo <josh@marketdata.md>, public-odrl@w3.org
- Message-Id: <05FD4833-DC95-4885-BEDA-C39DC1281C60@upm.es>
Dear Harshvardhan,
Allow me to answer by parts
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.
Yes, he was presenting why we need to extend ODRL for domain specific use cases due to the need of narrowing down certain terms in for those.
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.
Your are right, this can be a way of thinking on policies. However, for instance, for me is <operator>( <leftoperand>, <rightOperand>) —> <action> that looks more like a logic statement. However these are human constructions for understanding the policies. ODRL policies are written in RDF that actually has a way of express information as graph that has explicit and formal semantics expressed in an ontology; in this case, the ODRL ontology. Therefore, what we are speaking is just how we as humans understand the policies, but not how they actually are.
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.
IMHO I do not see any loss of semantics, the policy in RDF clearly states the action, the operand, the operators. They internal way in how implementations, or humans, handle this is just internal information and can be different depending on how the code is. The RDF policy is well written syntactically and thanks to the ontology that extends the ODRL ontology the orime:between is well defined so no semantic is loss.
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.
As I was mentioning in my previous email, I’m not against implementing a policy for a time range with intervals. That was not the scope of the policy example mentioned in the previous email but just showcase how the ODRL ontology can be extended for specific domains, and also, the implementation. Note that the way of expressing the policy that you are suggesting is just a human convention, since in RDF the policies are not expressed in such triples nor the standard (as far as I know) indicates to interpret them in such a way.
In any case, my take away is the following, there are endless ways of modeling certain scenarios (like the one we are discussing) and is not my intent to provide a pre-built solution for all the sensorios but, instead, provide a flexible tool that allows practitioners to adapt the policies to any of their modeled scenarios. In the case you mentioned, if for you works better as you explained, then the tool provides you with the necessary means to implement it behavior behind an ODRL ontology extension.
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 13:43, Harshvardhan J. Pandit <me@harshp.com> escribió:
>
> 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/ <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> <mailto:andreajesus.cimmino@upm.es <mailto:andreajesus.cimmino@upm.es>>
>> ✆ +34 671 09 06 24 <tel:+34-671-09-06-24 <tel:+34-671-09-06-24>>
>> Aviso / Disclaimer <https://www.upm.es/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> <mailto: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 <http://example.com/p:odre/Codre1>" <https://urldefense.com/v3/__http://example.com/p:odre/Codre1*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jKg1gMNG$ <https://urldefense.com/v3/__http://example.com/p:odre/Codre1*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jKg1gMNG$>>},
>>> **{ "@id": "http://example.com/p:odre/Codre2 <http://example.com/p:odre/Codre2>" <https://urldefense.com/v3/__http://example.com/p:odre/Codre2*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jI5xlX4Z$ <https://urldefense.com/v3/__http://example.com/p:odre/Codre2*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jI5xlX4Z$>>}
>>> ]
>>> }
>>> …
>>> {
>>> "@type": "Constraint",
>>> "uid": "http://example.com/p:odre/Codre1 <http://example.com/p:odre/Codre1>" <https://urldefense.com/v3/__http://example.com/p:odre/Codre1*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jKg1gMNG$ <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 <http://example.com/p:odre/Codre2>" <https://urldefense.com/v3/__http://example.com/p:odre/Codre2*22__;JQ!!D9dNQwwGXtA!Qk7TyFNIEXL3t3rAZJViyBEzKNRvC9Iz9orWsScsx80tmulvcXlJifgo07QbAqhroWsaigZ952iR7bQ1jI5xlX4Z$ <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$ <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> <mailto: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> <mailto:public-odrl@w3.org <mailto:public-odrl@w3.org>>>
>>> *Subject:*ODRL enforcement implementation
>>> *Resent-From:*<public-odrl@w3.org <mailto:public-odrl@w3.org> <mailto: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$ <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$ <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/ <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> <mailto:andreajesus.cimmino@upm.es <mailto:andreajesus.cimmino@upm.es>>
>>>
>>> ✆+34 671 09 06 24 <tel:+34-671-09-06-24 <tel:+34-671-09-06-24>>
>>>
>>> Aviso / Disclaimer <https://www.upm.es/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/ <https://harshp.com/>
Received on Monday, 30 September 2024 14:08:09 UTC