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

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.