- From: Joshua Cornejo <josh@marketdata.md>
- Date: Fri, 17 May 2024 13:32:56 +0100
- To: Sridhar Krishnamurthy <ksridhar@amagi.com>, Víctor Rodríguez Doncel <vrodriguez@fi.upm.es>
- CC: <public-odrl@w3.org>
- Message-ID: <D5322B9B-CC9E-4ECE-928C-902A9DED5ED0@marketdata.md>
Hi Sridhar,
I am confused – I thought your original question was to have monthly periods (1 month) where content is accessed a maximum of 5 times, calendars sound like a different requirement altogether as I am not sure how a calendar now makes it easier.
Checking during lunch:
Unfortunately, there is only one standard ( ISO-8601 ) and is week-based or quarters of year, but if you are flexible, you could input a list of weeks when the checks are done /reset as your :RightOperand, this list starts whenever you want and finishes when the :Rule is no longer active?
Reading some pages, there is a convention “Many retail and financial systems divide ISO-8601 quarters into three segments of 4-4-5 weeks, ...”
You could also implement sets of tuples for the start/end date of each period (significantly simpler than a whole mime type) – and several optimisations can be done on dates.
Depending on the end-to-end requirement, you still can build a taxonomy for your unbound checks – similar to what Victor proposed below, which could simplify and expedite your validations.
Regards,
___________________________________
Joshua Cornejo
marketdata
embed open standards
across your supply chain
From: Sridhar Krishnamurthy <ksridhar@amagi.com>
Date: Friday 17 May 2024 at 09:59
To: Víctor Rodríguez Doncel <vrodriguez@fi.upm.es>
Cc: <public-odrl@w3.org>
Subject: Re: How can recurrent temporal constraints be expressed ?
Resent-From: <public-odrl@w3.org>
Resent-Date: Fri, 17 May 2024 08:59:25 +0000
Oh ! yes.
I just wanted to specify something containing 'text/calendar'. i did not know
the (IRI) syntax. Will read further using the link that you have provided.
thank you
On Fri, May 17, 2024 at 1:50 PM Víctor Rodríguez Doncel <vrodriguez@fi.upm.es> wrote:
Dear Sridhar,
I have never seen asing a MIME type as the data type of the RDF literal, but it is possible.
The RDF syntax spec establishes that XSD datatypes are recognized, but "Semantic extensions of RDF might choose to recognize other datatype IRIs".
Therefore, using "text/calendar" would be great, except that it is not a valid URI. Mabe something like: "mime-type:text/calendar"?
Víctor
https://www.w3.org/TR/rdf11-concepts/#dfn-recognized-datatype-iris
El 17/05/2024 a las 9:08, Sridhar Krishnamurthy escribió:
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
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 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
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.
--
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.
Received on Friday, 17 May 2024 12:33:07 UTC