search

w3c / poe

Permissions & Obligations Expression WG
Other
23 stars 18 forks source link

Mechanism for specifying constraints #161

Closed riannella closed 7 years ago

riannella commented 7 years ago

@aisaac

  1. I was a bit surprised the detail of the mechanism for specifying constraints (in section 3.8 and others). There are many, many hidden semantics beyond the use of simple resource from that mechanisms. For example, when odrl:event is used in a constraint, the value that should actually be checked is the end time of that event. And this sort of interpretation varies from one resource/operand to the other. E.g. for odrl:purpose, there’s no such implicit indirection. I think I can personally live with it, but that’s maybe because I don’t have to implement a constraint processor for now ;-) I’m really wondering whether this mechanism would be considered good, compared to other mechanisms such as SWRL or perhaps SHACL. Is there any POE constraint processing systems implemented, or being implemented? If not, then I would suggest to put constraints in their own separate POE ‘module’ (a separate document and vocabulary), so that they don’t stand in the path of moving the basic POE model towa rds Recommendation status.
simonstey commented 7 years ago

+1

There are many, many hidden semantics beyond the use of simple resource from that mechanisms. For example, when odrl:event is used in a constraint, the value that should actually be checked is the end time of that event. And this sort of interpretation varies from one resource/operand to the other.

well well well ;)

riannella commented 7 years ago

How would the Information Model be updated to handle "SHACL-based" ODRL Constraints?

riannella commented 7 years ago

I think we need to update the definition of each constraint left operand in the Vocab to make sure it is clearly defined/described. We say this in the IM, so we just need to check that in the vocab. So, for example, we should say how "event" is used with the operators.

aisaac commented 7 years ago

An update of the definition of each constraint left operand in the Vocab would help. But I'm not sure it would solve everything. Indeed as you say I could find some info in the IM about these operands. But it really didn't feel natural at all. Like, the first time I see an operand I would think "oh but what does this thing stands for exactly?" and then when finding an example later I would think "oh, ok actually when they say X they mean the beginning of X" and then when encountering another operand Y I would realize that the 'semantic precision' is defined in a quite different way. So I think something should be done in the IM too. I'm sorry I can't be more precise in my feedback. The matter is awfully complex, and the POE WG deserves praise for trying to tackle it. But that's also why I'm suggesting to move the whole constraint thing to another companion spec. That would also give the opportunity to replace the entire companion spec by something more appropriate if one is found later, without having to jeopardize the core POE standard.

About SHACL I was thinking of linking to the SHACL expression of the constraint from e.g. a Permission, like this

"permission": [{ "target": "http://example.com/game:9090", "action": "odrl:play", "shaclConstraint": ":shaclExpression" }]

Where :shaclExpression of the constraint could be either a document URI, or a literal that is formed by the constraint. Whatever the SHACL expression is. Maybe a Shapes graph, or a SPARQL query with some encapsulation. Sorry I'm not a SHACL expert...

On 05/05/17 03:35, Renato Iannella wrote:

I think we need to update the definition of each constraint left operand in the Vocab to make sure it is clearly defined/described. We say this in the IM, so we just need to check that in the vocab. So, for example, we should say how "event" is used with the operators.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/161#issuecomment-299351700, or mute the thread https://github.com/notifications/unsubscribe-auth/AAnprR3B4rSdADAUXgbWyCRSB30Bzgkkks5r2nz4gaJpZM4NNr9a.

riannella commented 7 years ago

We tried to make them feel natural with the left/rightOperand+ operator properties. And operators are important. So "gt" and "lt" mean different times for an "event" rightOperand.

I think the key point here is that ODRL is aimed at expressing a policy - not enforcing it.

So I can imagine that an ODRL policy would drive more detailed and enforceable rules at a specific implementation level.

Take "compensate" with constraint "payAmount" of $5.00. That ODRL policy expression would be used to inform a "payment system" to make the payment, or verify the payment was made. That "payment system" interface is not in our scope.

The same for "purpose = eduction" - we can express this, but we have now way pf providing any further details.

If we took out constraint expressions, then we would not meet one of the fundamental needs of ODRL.

We also have a legacy XML world (yes, not all the world is into SemWeb ;-)

aisaac commented 7 years ago

I reckon the effort to make them feel natural, but what is natural for a couple of elements is less so when it's put in the perspective of what is natural for other elements.

I'm not asking to remove the constraint expression from POE altogether: just trying to isolate it from a much less debatable core. In fact while the current constraint mechanism is for expression not for enforcement, some sub-community may prefer to develop an expression that also works for enforcement (i.e. constraints with sound formal semantics and implemented checkers). It will be a much easier affair if the current mechanism does not stand in the way of such effort. (but again this can be done by just giving a different status to the constraints from the rest of the POE recommendations, not removing them entirely).

On 18/05/17 05:17, Renato Iannella wrote:

We tried to make them feel natural with the left/rightOperand+ operator properties. And operators are important. So "gt" and "lt" mean different times for an "event" rightOperand.

I think the key point here is that ODRL is aimed at expressing a policy - not enforcing it.

So I can imagine that an ODRL policy would drive more detailed and enforceable rules at a specific implementation level.

Take "compensate" with constraint "payAmount" of $5.00. That ODRL policy expression would be used to inform a "payment system" to make the payment, or verify the payment was made. That "payment system" interface is not in our scope.

The same for "purpose = eduction" - we can express this, but we have now way pf providing any further details.

If we took out constraint expressions, then we would not meet one of the fundamental needs of ODRL.

We also have a legacy XML world (yes, not all the world is into SemWeb ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/161#issuecomment-302289291, or mute the thread https://github.com/notifications/unsubscribe-auth/AAnprYGcrvEzrh3H80Nd6-qPctNcFtr_ks5r67g2gaJpZM4NNr9a.

riannella commented 7 years ago

Supporting enforcement mechanisms is outside our scope: https://www.w3.org/2016/poe/charter

riannella commented 7 years ago

Another way: A community can also define a new Rule subclass, that uses their own constraint semantics.

aisaac commented 7 years ago

Yes enforcement is out of the scope, it's fine. I was not urging that POE should provide semantics or algorithms for enforcing constraints. Rather, acknowledging that this is a complex issue, and that some patterns currently chosen for expressing constraints are debatable, I was suggesting to

(NB: the part in questions are mostly 3.8 in https://www.w3.org/TR/2017/WD-odrl-model-20170223/ and 4.19/4.20/4.21 in https://www.w3.org/TR/2017/WD-odrl-vocab-20170223/)

The suggestion to move stuff to its own module would also make it easier to refer to first ideas of formal expression and enforcement, if some people work on it. Even if it's outside the charter, I see there's work happening on 'evaluators' and it looks like a good first step for enforcement...

riannella commented 7 years ago

To be frank, I think the the WG would not agree to take out the entire constraint mechanism and put it into a separate NOTE.

aisaac commented 7 years ago

I haven't said it should be aimed to be a NOTE. It could be something closer to a REC, as the group sees fit. My point is that if for some reason there are problems with this new spec, possibly causing it to be refused as a REC, then that wouldn't impact the other 'core' spec.

riannella commented 7 years ago

If, and when, there are "problems with this new spec", then the WG will make some decisions.

But there are no obvious issues with constraints in this expression language.

aisaac commented 7 years ago

OK, fair enough. This can be closed then.

On 19/06/17 05:19, Renato Iannella wrote:

If, and when, there are "problems with this new spec", then the WG will make some decisions.

But there are no obvious issues with constraints in this /expression/ language.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/161#issuecomment-309329333, or mute the thread https://github.com/notifications/unsubscribe-auth/AAnprc7GHujXF0aHgQJXj130Bk_pL8fJks5sFejUgaJpZM4NNr9a.