Re: is overloading of leftOperand possible using dataType pertaining to rightOperand ?

Thank you very much for your response.
I am also interested in knowing your answer for the question
This is nice. Does this mean that a new profile is not needed for such
extensions ? If so, that would be great.
that I asked in the context of your previous response
All left operands are an instance of odrl:LeftOperand.  ........ When you
are evaluating the RightOperand, now you can use the new definition of the
LeftOperand to determine what are your conditions connected to the operator
used.

regards


On Sat, Mar 16, 2024 at 3:25 PM Joshua Cornejo <josh@marketdata.md> wrote:

> Hi Sridhar,
>
>
>
> Your use case sounds very similar to something I am hoping to bring up for
> v3 and the need to establish some guidelines on what can be done
> (“action”), what can be measured (“leftOperand”) and where are standard
> entities to test against (“rightOperand”) against common ontologies (rather
> than providing just the scaffolding and leaving the implementation free).
>
>
>
> Conceptually you seem to follow what I proposed as option  2:
>
>    - your dc and lc are properties of the Asset (rather than classes),
>    and your refinement is related to the Asset (since there’s no full context,
>    not sure if that’s the purpose of the entire policy/rules).
>
>
>
> So you can have an *:Asset* with a class (I prefer lists, so you don’t
> have to ‘narrow’ to single choice for future enhancements) :*Channel*
> that is a descendant of *:RightOperand *
>
>
>
> You can then have instances (or instances as properties of the asset, more
> definition inside the class) for :VOD / etc. Subsequently you can then
> create constraints on the asset:
>
>
>
> https://www.w3.org/TR/odrl-model/#constraint-asset
>
>
>
> I want to highlight that from what I read, you are describing a use case
> for catalogue restriction (“agent adds an asset and it has a property or
> belongs to a category :VOD”) rather than an application of a restriction
> (“user can only :play asset when delivered over :VOD”). You have to be
> mindful that you could have the use case of the same :Asset belonging to 2
> categories (e.g. perhaps different ‘packages’ in your vod offering):
>
>
>
> So you have to consider your solution in context:
>
>    - are you restricting finding the asset by the categories where it
>    belongs (catalogue/composition) (i.e.. if user can’t ‘see’ the catalogue =
>    it doesn’t have a way to find the asset, you have a ‘chain’ of validation
>    for the user to reach he asset)
>    - the asset has all the attribute decorations and in isolation, it can
>    be queried by the policy engine (i.e. assets are disconnected with a full
>    ‘metadata envelope’ and distributed and your architecture ‘queries’ the
>    metadata against the policy/policies to determine compliance).
>
>
>
> Note - I think some of this is outside the specific scope of the purpose
> of the ODRL mailing list – as per my first sentence: left to the
> ‘implementer’ to decide.
>
>
>
> Hope this helps,
>
> ___________________________________
>
> *Joshua Cornejo*
>
> *marketdata <https://www.marketdata.md/>*
>
> embed open standards
>
> across your supply chain
>
>
>
> *From: *Sridhar Krishnamurthy <ksridhar@amagi.com>
> *Date: *Saturday 16 March 2024 at 08:35
> *To: *<public-odrl@w3.org>
> *Subject: *Fwd: is overloading of leftOperand possible using dataType
> pertaining to rightOperand ?
> *Resent-From: *<public-odrl@w3.org>
> *Resent-Date: *Sat, 16 Mar 2024 08:35:20 +0000
>
>
>
> Thank you for your response Sir.
>
>
>
> I need some more clarifications.
>
> Please see them as against your suggestions:
>
>
>
> On Fri, Mar 15, 2024 at 7:03 PM Joshua Cornejo <josh@marketdata.md> wrote:
>
> Hi Sridhar,
>
>
>
> All left operands are an instance of odrl:LeftOperand. You can create a
> new one that inherits from this class
>
>
>
> odrl:leftOperand odrl:deliveryChannel
>
>
>
>                 could become
>
>
>
>                 odrl:leftOperand *amg:RequiredNewLeftOperand *
>
>
>
> As long as your ontology extension declares somewhere that
>
>
>
> *     amg:RequiredNewLeftOperand* a odrl:LeftOperand
>
>
>
> When you are evaluating the RightOperand, now you can use the new
> definition of the LeftOperand to determine what are your conditions
> connected to the operator used.
>
>
>
> This is nice. Does this mean that a new profile is not needed for such
> extensions ? If so, that would be great.
>
>
>
>
>
> Alternatively (I am extrapolating from your brief example, so likely to be
> wrong):
>
>    - you could think that your dc and lc classes should inherit from a
>    single root and you can evaluate them by specialisation.
>    - your dc and lc are properties of the Asset (rather than classes),
>    and your refinement is related to the Asset (since there’s no full context,
>    not sure if that’s the purpose of the entire policy/rules).
>    - your dc and lc  are instances of AssetCollections that ‘contain’
>    your asset:
>
>
>
> VOD ----------------|
>
> STARMOVIES ------------------> Asset
>
> MOVIESNOW ----------|
>
>
>
> They probably would produce a similar output at the constraint level
> output, but in the first case, there’s no (evident direct) connection to
> the asset.
>
>
>
> Sir, with respect to this 'proposed' alternative I would like to state the
> use cases to seek more clarity.
>
> I am sorry that I did not state the use cases earlier.
>
>
>
> Use case a: An agent wants to restrict playout of an asset to VOD (video
> on demand) only.
>
> Use case b: An agent wants to restrict playout of an asset to specific
> linear channels such as STARMOVIES or MOVIESNOW.
>
>
>
> I tried to model (forgive my naivety) by addressing both of these cases
> through a single leftOperand ('deliveryChannel') and by specifying
> different 'types' of the rightOperand values through odrl:datatype (amg:dc
> for VOD and amg:lc for linear channels).
>
>
>
> The modelling was to be as follows:
>
>
>
> Example (a) :
>
>
>
> <http://example.com/policy:1010>
>     a odrl:Set ;
>     odrl:permission [
>         odrl:action odrl:play ;
>         odrl:target <http://example.com/asset:99898> ;
>         odrl:constraint [
>
>             odrl:leftOperand odrl:deliveryChannel ;
>
>             odrl:operator odrl:eq ;
>
>             odrl:rightOperand <
> http://www.amagi.com/metadata/ontologies/media/dc#_VOD> ;
>
>             odrl:dataType amg:dc ;
>
>         ];
>
>     ];
>
>     .
>
>
>
> Example (b) :
>
>
>
> <http://example.com/policy:1010>
>     a odrl:Set ;
>     odrl:permission [
>         odrl:action odrl:play ;
>         odrl:target <http://example.com/asset:99898> ;
>
>         odrl:constraint [
>             odrl:leftOperand odrl:deliveryChannel ;
>             odrl:operator odrl:isAnyOf ;
>             odrl:rightOperand (
>                 <
> http://www.amagi.com/metadata/ontologies/media/lc#_STARMOVIES>
>                 <
> http://www.amagi.com/metadata/ontologies/media/lc#_MOVIESNOW>
>             ) ;
>
>             odrl:dataType amg:lc ;
>
>         ];
>
>     ];
>
>     .
>
>
>
> The odlr:dataType was used to disambiguate values of the 'deliveryChannel'
> constraint and hence is not a property of the asset. Also STARMOVIES,
> MOVIESNOW is not an AssetCollection but rather values of the
> 'deliveryChannel'.
>
>
>
> I am sorry to take your time but would deeply appreciate your
> observation/suggestion in this regard.
>
>
>
> thanking you once again
>
>
>
>
>
> Hope this helps,
>
> ___________________________________
>
> *Joshua Cornejo*
>
> *marketdata <https://www.marketdata.md/>*
>
> embed open standards
>
> across your supply chain
>
>
>
> *From: *Sridhar Krishnamurthy <ksridhar@amagi.com>
> *Date: *Friday 15 March 2024 at 13:03
> *To: *<public-odrl@w3.org>
> *Subject: *is overloading of leftOperand possible using dataType
> pertaining to rightOperand ?
> *Resent-From: *<public-odrl@w3.org>
> *Resent-Date: *Fri, 15 Mar 2024 13:03:43 +0000
>
>
>
> Respected Madam/Sir,
>
>
>
> Given that there are just a handful of leftOperands as specified in
>
> https://www.w3.org/TR/odrl-vocab/#constraintRelationalOperators and
>
> absorbed by a profile such as
>
> https://iptc.org/std/RightsML/2.0/RightsML_2.0-specification.html
>
> is it possible to overload a leftOperand using the dataType of the
> rightOperand ?
>
> (Reference : https://www.w3.org/TR/odrl-model/#constraint-class)
>
>
>
> In the following example(s), deliveryChannel is the only leftOperand whose
>
> semantics come close to what is needed to specify
>
> (a) the delivery type or
>
> (b) linear channel (names)
>
>
>
> Example for (a) :
>
>
>
> odrl:constraint [
>
>     odrl:leftOperand odrl:deliveryChannel ;
>     odrl:operator odrl:eq ;
>     odrl:rightOperand <
> http://www.amagi.com/metadata/ontologies/media/dc#_VOD> ;
>
>     odrl:dataType amg:dc ;
> ] ;
>
>
>
> Example for (b) :
>
>
>
> odrl:constraint [
>
>     odrl:leftOperand odrl:deliveryChannel ;
>     odrl:operator odrl:isAnyOf ;
>     odrl:rightOperand (
>          <http://www.amagi.com/metadata/ontologies/media/lc#_STARMOVIES>
>          <http://www.amagi.com/metadata/ontologies/media/lc#_MOVIESNOW>
>      ) ;
>      odrl:dataType amg:lc ;
> ] ;
>
>
>
> 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.
>
>
> *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.