Re: clarification needed in a case of 'constraint of a rule' vs 'refinement of an action' ?

IMHO,

 

I have not had many examples of constraints on rules to think about, but you can think about them as follows (Nicoletta’s diagram for context):

 

 

I see it as a cascade:

 
A constraint on a rule short circuits evaluation (allows you to save time if the constraint is not met without going further). I think this will be relatively ‘simple’. 
For example, where the odrl:LeftOperand is odrl:DateTime or odrl:Event (time based) / or odrl:DeliveryChannel (‘location based’) , if the conditions are not met – you can say this rule is inactive. 

 
Refining the action/target/function tells you how / what / who things can be done.
For example, an odrl:LeftOperand as above will tell you when a specific action can be performed (other actions might be listed as part of the same rule to be evaluated). I have assumed that you have (I like the term) a “State of the World” (more mundane than deontic state, but anyway, it is an input, a new State of the World - deontic state - will be the output) that tells you that for this instance of an evaluation/validation, you have (as an example, a specific) action to test from the perspective of the odrl:Assignee (you can articulate 1:1 rules for everything, but it is likely that sophistication will grow and you will group by asset/assignee, then list of actions in a rule) and you can ignore the actions listed but not performed. Otherwise, you will also have many rules to test (which can turn inefficient and hard to manage). 

 

Not sure what level of complexity your solution will handle and your KPI, but I think you can parallelise evaluation (e.g. in C# a ConcurrentBag that separates the 4 – constraints, refinements on function/target/action – first fail, short circuit).

 

Hope others agree with this, as I am not yet working on the evaluator (there are other beasts to tame).

 

Regards,

 

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain

 

From: Sridhar Krishnamurthy <ksridhar@amagi.com>
Date: Monday 13 May 2024 at 09:51
To: <public-odrl@w3.org>
Subject: clarification needed in a case of 'constraint of a rule' vs 'refinement of an action' ?
Resent-From: <public-odrl@w3.org>
Resent-Date: Mon, 13 May 2024 08:51:37 +0000

 

I beg to seek a clarification regarding
How do we decide in some cases to choose between
'a constraint to a rule' vs 'refinement of an action' ?

------------------------

Let us consider the example 13 in https://www.w3.org/TR/odrl-model/#constraint-rule

(A)

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:6163",
    "profile": "http://example.com/odrl:profile:10",
    "permission": [{
       "target": "http://example.com/document:1234",
       "assigner": "http://example.com/org:616",
       "action": "distribute",
       "constraint": [{
           "leftOperand": "dateTime",
           "operator": "lt",
           "rightOperand":  { "@value": "2018-01-01", "@type": "xsd:date" }
       }]
   }]
}

------------------------

what would be the reason that prevents us from expressing the same thing as

(B)

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:6163",
    "profile": "http://example.com/odrl:profile:10",
    "permission": [{
       "target": "http://example.com/document:1234",
       "assigner": "http://example.com/org:616",
       "action": [{
          "rdf:value": { "@id": "odrl:distribute" },
          "refinement": [{
              "leftOperand": "dateTime",
              "operator": "lt",
              "rightOperand":  { "@value": "2018-01-01", "@type": "xsd:date" }
          }]
       }]
   }]
}

thanks and regards



DISCLAIMER: The contents of this email, including any attachments that it may contain, are privileged and confidential information, and may also constitute as proprietary, and are intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by email and delete the original message. Unintended recipients are strictly prohibited from copying, disclosing, and/or distributing such contents in any manner or form. Opinions, conclusions, and other information in this transmission that do not relate to the official business of Amagi, including all its affiliates, shall be understood as neither given nor endorsed by it. Any statements made herein that are tantamount to contractual obligations, promises, claims or commitments shall not be binding on the Company unless expressly and specifically stated as otherwise, or followed by written confirmation, by an authorized signatory of the Company.