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

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