- From: Sridhar Krishnamurthy <ksridhar@amagi.com>
- Date: Fri, 17 May 2024 12:38:28 +0530
- To: Joshua Cornejo <josh@marketdata.md>
- Cc: Víctor Rodríguez Doncel <vrodriguez@fi.upm.es>, public-odrl@w3.org
- Message-ID: <CAML7Ke_OSnTNRbUMBEkgg7NLC8WOeO+eub5MsxC4Zgqsn93MXw@mail.gmail.com>
Respected Sirs,
Please see two comments below:
On Wed, May 15, 2024 at 4:04 PM Sridhar Krishnamurthy <ksridhar@amagi.com>
wrote:
> Respected Victor and Joshua,
>
> Thank you once again for the patience shown in answering the questions.
> Will take some time to imbue them and will get back to you if necessary.
>
> thanks and regards
>
>
>
>
> On Wed, May 15, 2024 at 12:25 PM Joshua Cornejo <josh@marketdata.md>
> wrote:
>
>> The specification for Constraints (
>> https://www.w3.org/TR/odrl-model/#constraint)
>>
>>
>>
>> All the language around Constraint / Refinement instantiation is
>> singular, e.g:
>>
>>
>>
>> An Action *MAY* include the refinement property to
>> indicate a Constraint/Logical Constraint that narrows the semantics of the
>> Action operation directly.
>>
>>
>>
>> As such, in my interpretation, an action can have one-and-only one
>> odrl:refinement/odrl:constraint, this is modelled:
>>
>>
>>
>> ns:uriAction a *odrl:Action*;
>>
>> *odrl:action odrl:play;*
>>
>> *odrl:refinement* ns:uriRefinement.
>>
>>
>>
>> But, if this was just the use of formal language and it could be 1-or
>> more, it can be modelled as:
>>
>>
>>
>> ns:uriAction a *odrl:Action*;
>>
>> *odrl:action odrl:play;*
>>
>> *odrl:refinement* ns:uriRefinement1,
>>
>> ns:uriRefinement2.
>>
>> And you have 2 independent refinements acting on odrl:play.
>>
>>
>>
>
Comment 1:
----------
The para soon after the Constraints section at
https://www.w3.org/TR/odrl-model/#constraint
has the following statement
...A Logical Constraint will refer to existing Constraints as its operands.
When multiple Constraints apply to the same Rule, Action, Party/Asset
Collection, then they are interpreted as conjunction and all *MUST* be
satisfied.
This indicates (as you also said) that multiple constraints/refinements can
be
specified and they are considered to be AND'ed together without the need
for a
Logical Constraint.
This is akin to the answer that Victor suggested
i.e.
"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"
}]
}]
Comment: 2
----------
An observation on the first constraint above is that it would be better
to also specify the dataType property and its value. May be this could be
the mime-type of the 'text/calendar'.
Please do correct me if the above observations are incorrect.
thanks and regards
> Regards,
>>
>> ___________________________________
>>
>> *Joshua Cornejo*
>>
>> *marketdata <https://www.marketdata.md/>*
>>
>> embed open standards
>>
>> across your supply chain
>>
>>
>>
>> *From: *Sridhar Krishnamurthy <ksridhar@amagi.com>
>> *Date: *Wednesday 15 May 2024 at 07:09
>> *To: *Joshua Cornejo <josh@marketdata.md>
>> *Cc: *Víctor Rodríguez Doncel <vrodriguez@fi.upm.es>, <public-odrl@w3.org
>> >
>> *Subject: *Re: How can recurrent temporal constraints be expressed ?
>> *Resent-From: *<public-odrl@w3.org>
>> *Resent-Date: *Wed, 15 May 2024 06:09:34 +0000
>>
>>
>>
>> Respected sir,
>>
>>
>>
>> Can you elaborate on the line
>>
>>
>>
>> >>
>>
>> The language of refinements is singular, but being triples, (I assume)
>> there shouldn’t be a problem.
>>
>> <<
>>
>> thanks and regards
>>
>>
>>
>> On Tue, May 14, 2024 at 6:59 PM Joshua Cornejo <josh@marketdata.md>
>> wrote:
>>
>> 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
>> <https://www.w3.org/TR/odrl-vocab/#term-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
>> <https://www.w3.org/TR/odrl-vocab/#term-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
>> <https://www.w3.org/TR/odrl-model/#constraint> is singular, but being
>> triples, (I assume) there shouldn’t be a problem.
>>
>>
>>
>> Regards,
>>
>>
>>
>>
>>
>> ___________________________________
>>
>> *Joshua Cornejo*
>>
>> *marketdata <https://www.marketdata.md/>*
>>
>> 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"
>> <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
>>
>>
>> *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.
>>
>
--
**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.
Received on Friday, 17 May 2024 07:08:46 UTC