odrl:target

[joshcornejo]

a rule might be the same for several odrl:Asset / odrl:AssetCollections, but it is not advisable to group them all under a single (new) odrl:AssetCollection. As such it would be good to have a sequence of odrl:Asset as acceptable input.

ex:RuleEx               a odrl:Permission;
            odrl:target ex:AssetA, ex:AssetB.

[riannella]

You can have multiple targets. See https://www.w3.org/TR/odrl-model/#composition

[joshcornejo]

Oh - missed this (also the action seems to be 'multiple') so that covers both of my tickets.

[joshcornejo]

2.7 Policy Rule Composition "The Policy SHOULD then be processed into its normative atomic equivalent."

This has had me thinking all morning (and one of the reasons i find JSON-LD as the tangible language for examples so frustrating, since it uses mostly implicit anonymous nodes).

In RDF:

ex:Prohibition1                 a odrl:Prohibition;
                      odrl:target ex:Asset1, ex:Asset2;
                terms:description "some example prohibition".

ex:Prohibition1 is now an RDF node that has 2 atomic equivalent (or possible evaluation paths, one per asset). This means that for evaluation I have at least two choices:

1. unravel ex:Prohibition1 into 2 atomic rules (ex:P1Asset1 / ex:P1Asset2) and have some reference back that links ex:Prohibition1 (for traceability).
2. have an internal mechanism that allows me to keep track each of the atomic equivalents when they are evaluated.

[riannella]

I think as a "should" it can allow implementors to decide if they have alternate mechanisms to store/query policies with the same outcomes. For example, I can put ex:Prohibition1 into my favourite graph database and happily query for all the prohibitions related to ex:Asset1

[joshcornejo]

I have been thinking about this for a while, it would need to be a labelled graph where the edges are the constraints (plus a 'result' if you want to optimise querying), as you will need to keep the validity of the actions (e.g. below the ex:TimeLimitConstraint is a simple constraint, but a more complex logical constraint could be is 'one time only in a 12 month period') per target.

ex:TimeLimitConstraint          a odrl:Constraint;
                 odrl:leftOperand odrl:dateTime;
                    odrl:operator odrl:lteq;              
                odrl:rightOperand "2025-01-01T00:00:00.0000000Z"^^xsd:dateTime;

ex:ActionURI                    a odrl:Action;
                      odrl:action odrl:play, odrl:execute, odrl:distribute;
                  odrl:refinement ex:TimeLimitConstraint. #for simplicity this is another URI

ex:PermissionEx                 a odrl:Permission;
                    terms:created "2024-06-01T18:33:36.9180000Z"^^xsd:dateTime;
                      odrl:target ex:Asset1, ex:Asset2;
          somenamespace:actionRef ex:ActionURI;  
                terms:description "permission with multiple actions".

[joshcornejo]

this can be closed