- From: Andrea Cimmino <andreajesus.cimmino@upm.es>
- Date: Mon, 30 Sep 2024 16:29:13 +0200
- To: Joshua Cornejo <josh@marketdata.md>
- Cc: public-odrl@w3.org
- Message-Id: <41CFEC55-2E5F-4E05-B5A6-EF9C73EA5F96@upm.es>
Hello Joshua,
It appears that you are extending the semantics of odrl:Operator (in this case otime:between) to determine that leftOperand and RightOperand will be times, and compared against an implicit property that is not specified anywhere by the constraint. This implies a deeper level of understanding of general semantics by the users (and implementors).
The property is specified in the ontological extension we have developed mentioned in the paper, and also, referenced in the @context of the policy. This is how usually ontologies are extended. I agree with you that this requires digging into an ontological extension, but usually this is how ontologies are adapted to particular domains. Having more specific semantics precisely avoids having different interpretations of the same concept since they narrow down they way terms must be interpreted.
The definition of dateTime/date/xsd is a bit of a red herring (not sure why odrl:timeInterval doesn’t work in your case with the appropriate xsd definitions?).
Probably it may work, but as I mentioned, the goal of that policy was to show case the extensibility feature of the tool not to model this particular use case without using an extension. In any case, I do not see the problem in the way the policy does it currently, both options seem fair to me.
I have already implemented the three I considered most taxing (odrl:isA, odrl:hasPart, and odrl:isPartOf) the following 3 (odrl:isAllOf, odrl:isAnyOf, odrl:isNoneOf) are simpler to calculate within the constraint, and the final 6 are the easiest.
I have an MVP evaluator (there is more complexity than the operations and constraints) only consuming standard odrl:Agreement as input, also implemented authZen (the new OIDC standard) as one of the interfaces for authorisation to make sure it works in the real world.
IMHO as a consumer of a system, any extension (ODRE) should fully implement the baseline (ODRL), otherwise there are risks of divergence and ‘doing things many ways and now we need many mappings’.
ODRE allows you to implement what you need, and IMHO there are certain terms in ODRL that will act differently depending on the specific scenario and to avoid such difference more specific semantics are needed. For instance, your mentioned that your implementation for odrl:isA checks whether an instance is rdf:type or rdfs:subClassOf however in the ontology of ODRL that is not the definition of the operator, it states "A set-based operator indicating that a given value is an instance of the right operand of the Constraint.”. This can be interpreted as you did, which I think is a good interpretation, but also in other ways. For instance, if a string value isA datetime which as RDF encodes datatypes will not work since there is no use of rdf:type or rdfs:subClassOf. The goal of ODRE is not to provide you a close implementation of ODRL, but instead, the means to allow you to implement the case you need. Also, it is difficult to provide an implementation that is compliant with such abstract operator. IMHO it would be better to have a specific operator named isAOwlClass and implement that particular behavior.
Btw, I think is really cool you aligned with authZen.
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:53, Joshua Cornejo <josh@marketdata.md> escribió:
>
> Hi again,
>
> I don’t have the background into what you are trying to implement, but my points:
>
> It appears that you are extending the semantics of odrl:Operator (in this case otime:between) to determine that leftOperand and RightOperand will be times, and compared against an implicit property that is not specified anywhere by the constraint. This implies a deeper level of understanding of general semantics by the users (and implementors).
> The definition of dateTime/date/xsd is a bit of a red herring (not sure why odrl:timeInterval doesn’t work in your case with the appropriate xsd definitions?).
> I have already implemented the three I considered most taxing (odrl:isA, odrl:hasPart, and odrl:isPartOf) the following 3 (odrl:isAllOf, odrl:isAnyOf, odrl:isNoneOf) are simpler to calculate within the constraint, and the final 6 are the easiest.
> I have an MVP evaluator (there is more complexity than the operations and constraints) only consuming standard odrl:Agreement as input, also implemented authZen (the new OIDC standard) as one of the interfaces for authorisation to make sure it works in the real world.
> IMHO as a consumer of a system, any extension (ODRE) should fully implement the baseline (ODRL), otherwise there are risks of divergence and ‘doing things many ways and now we need many mappings’.
>
> Regards,
> ___________________________________
> Joshua Cornejo
> marketdata <https://www.marketdata.md/>
> 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 11:40
> To: Joshua Cornejo <josh@marketdata.md <mailto:josh@marketdata.md>>
> Cc: <public-odrl@w3.org <mailto:public-odrl@w3.org>>
> Subject: Re: ODRL enforcement implementation
> Resent-From: <public-odrl@w3.org <mailto:public-odrl@w3.org>>
> Resent-Date: Mon, 30 Sep 2024 10:40:48 +0000
>
> 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 <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 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.
Received on Monday, 30 September 2024 14:29:22 UTC