Re: What exactly is stated by Non-/Active?

Hi,

In the API tentatively specified here  
(http://odrlapi.appspot.com/apidoc/index.html) I have defined a  
validator and an evaluator. The validator is implemented (still  
improving). The evaluator is being implemented, but I have specified  
two methods:
- inform
- evaluate

The sequence of calls I understood is:

input:
- inform: Constraint1124 = satisfied
- inform: Duty12312 = satisfied
- inform: Duty12124 = not satisfied
- evaluate: policy1, policy2, policy3

output:
- policy1-rule1: active
- policy1-rule2: active
- policy2-rule1: not-active
- policy2-rule1: active

Is this correct or should I stop implementing this?

(sorry if my terminology was not precise)
Regards,
Víctor

benedict.whittamsmith@thomsonreuters.com escribió:

> Hi Renato,
>
> I agree with much of what you say. I'd only add one further  
> criterion for interoperability: that two implementations that have a  
> common understanding of the world must agree on the states of the  
> rules in a policy.
>
> Now we have nothing to say on how an implementation comes to  
> understand the world - this is likely to be domain (aka profile)  
> specific. But if two happen to agree, then they should interpret the  
> rules in a policy in the same way.
>
> This is why we need a 'standard' evaluator.
>
> It seems to me that the IM + the 'truth tables' to test against are  
> enough to build an evaluator and enforce this second level of  
> interoperability.
>
> Michael: is it only the line above that leaves you uncomfortable?
>
> Should we be saying more about how to build an evaluator? In which  
> case I like Renato's idea of a Note to Implementors.
>
> Or are you asking for greater clarity in the IM?
>
> Ben
>
> ________________________________
> From: Renato Iannella [renato.iannella@monegraph.com]
> Sent: 05 September 2017 14:37
> To: POE Public
> Subject: Re: What exactly is stated by Non-/Active?
>
>
> On 5 Sep 2017, at 20:08, Michael Steidl (IPTC)  
> <mdirector@iptc.org<mailto:mdirector@iptc.org>> wrote:
>
> I've got the feeling that members of this group have different views  
> on the role of the Non-/Active state of Rules and I raised the need  
> of a clarification of that as new Github Issue  
> #245<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_poe_issues_245&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=6zKsY0rYbamT39VLwFyiNRQq5kP9V8VfXNbeD0GwlqvjGIQo1uv383jKtxD77PlM&m=PMiwASO7bywlZnE5KU06TXcdSYNo2MGorMP681_Fo3w&s=jgeKd0zb7KUwqUz4YhaFDYUd_Lc_Yt8YgizjM_AgYXE&e=>
> I consider this as prerequisite for writing an agreed Rule Processing.
>
> Michael, thanks for your hard diligent work on this.
>
> It has been tough to understand the fluid viewpoints over this issue...
>
> But, I want to raise a bigger issue here…and that is the fundamental  
> requirement of W3C specs: interoperability.
>
> Publishing and consuming ODRL Policies is the core aspect of  
> interoperability. Two (independent) systems can interchange ODRL  
> Policies knowing they are “valid” and conform to the IM spec.
>
> All the current discussion on “Rule Processing” is stuff that  
> happens by individual implementations.
> Once a system has the ODRL Policy, then it can “evaluate” it and  
> generate valid/satisfied/fulfilled states…
> But that is only for its own use, no other party sees that.
> (And as we just saw, the state is completely “black box” contextual.  
> Another implementation with the same Policy could generate different  
> states.)
>
> I don’t want to discount “Rule Processing”, its important to some,  
> but I would argue that it is not important to all implementations.
>
> I can imagine an implementation that publishes/consumes ODRL  
> policies, loads them into a graphDB, and hits it with all kinds of  
> SPARQL queries:  “Can Billie play music file X in Australia on a  
> Wednesday?” Answer: “Only if she pays 0.005 bitcoins by Tuesday”
> Did this implementation needs these states? I am not convinced.
>
> I think that the best way forward is to focus the CR Exit Criteria  
> on validity and conformance to the ODRL IM.
> (BTW, conformance still means that a Permission is allowed, a Duty  
> must be fulfilled, a Prohibition is not allowed, and a Constraint  
> satisfied.)
>
> I would strongly recommend those that favour the Rule Processing  
> approach to document that as a NOTE for implementors.
>
> The other advantage to this approach is that we lower the barrier  
> for implementors to  address the CR criteria, thereby, enhancing the  
> opportunity for greater participation and proof to the W3C to go to  
> PR.
>
> Renato

Received on Tuesday, 5 September 2017 17:12:16 UTC