Re: How can recurrent temporal constraints be expressed ?

My extra 1c:

 

ns:uriLC1           a odrl:Constraint

                    odrl:leftOperand odrl:count;

                    odrl:operator odrl:lteq;

                    odrl:rightOperand <here goes the unit or uri>.

 

ns:uriLC2           a odrl:Constraint

                    odrl:leftOperand odrl:timeInterval;

                    odrl:operator odrl:eq;

                    odrl:rightOperand <here goes the period or uri>.

 

ns:uriRefinement    a odrl:LogicalConstraint;

                    odrl:and ns:uriLC1,

                             ns:uriLC2.

 

ns:uriAction        a odrl:Action;

                    odrl:action odrl:play;

                    odrl:refinement ns:uriRefinement.

 

For me, the wording of timeInterval has been a bit confusing (underlined - “A recurring period of time before the next execution of the action of the Rule”), so if this is not the intention, a new :LeftOperand will need to be defined to satisfy this use case.

 

Further, 
if you have a specific period, use odrl:andSequence (quote - “The andSequence operator is an example where there may be temporal conditional requirements between the operands.”)
if you need to model two different counters (e.g. do not play my asset more than 5 times in a month, with a concurrency of 1), you will need 2 rules with the action odrl:play.
 

The language of refinements is singular, but being triples, (I assume) there shouldn’t be a problem.

 

Regards,

 

 

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain

 

From: Víctor Rodríguez Doncel <vrodriguez@fi.upm.es>
Date: Tuesday 14 May 2024 at 14:24
To: <public-odrl@w3.org>
Subject: Re: How can recurrent temporal constraints be expressed ?
Resent-From: <public-odrl@w3.org>
Resent-Date: Tue, 14 May 2024 13:24:10 +0000

 

Dear Sridhar, 

My two cents:

What about using an RFC 5545 recurrent pattern?

{
 "@context": "http://www.w3.org/ns/odrl.jsonld",
 "@type": "Set",
 "uid": "example",
 "permission": [{
     "target": "asset,
    "action": "display",
    "constraint": [{
           "leftOperand": "dateTime",
           "operator": "gte",
           "rightOperand":  { "@value": "RRULE:FREQ=MONTHLY;INTERVAL=1;COUNT=1;UNTIL=2024-12-31",  }
       },{
           "leftOperand": "count",
           "operator": "leq",
           "rightOperand":  "5",
           "dct:comment": "At most 5 tims"
       }]
 }]
}

Regards
Víctor

El 14/05/2024 a las 13:55, Sridhar Krishnamurthy escribió:

Dear All,

Consider the following:

An agent wants to restrict/constrain the usage of some content to maximum 5 times in 
a given period with a frequency limit of not more than once in a month.

The questions that arise here are:

(1) Does ODRL address such restrictions or is it outside the scope ?

(2) If ODRL addresses such restrictions then

    (a) Which Common Vocabulary elements can/should be used ?
        - example: Count (https://www.w3.org/TR/odrl-vocab/#term-count)

    (b) Are there any Profiles that relate to this kind of use case ?
        (https://www.w3.org/community/odrl/wiki/ODRL_Profiles) ?

    (c) How can recurrent temporal events be addressed ?

        - recurrent events in the Calendar scope are dealt in 
          - https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.5 and
            https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.10

        - I am unable to see how these are being addressed in https://www.w3.org/TR/owl-time/
          which I hoped to use to express such constraints/refinements.

 

        - Can/Should these be handled through something like processing instructions 

          (https://www.w3.org/TR/xml/#sec-pi) ?

I may be forgiven for my questions raising from my lack of comprehensive 
understanding of specifications.

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. 



-- 
Víctor Rodríguez-Doncel
D2110 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
ETS de Ingenieros Informáticos
Universidad Politécnica de Madrid
https://cosasbuenas.es