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

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

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

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.