On a odrl:refinement over an Action / Asset Collection / Party Collection

[joshcornejo]

In the examples (14), in JSON we have the following

       "action": [{
          "rdf:value": { "@id": "odrl:print" },
          "refinement": [{
             "leftOperand": "resolution",
             "operator": "lteq",
             "rightOperand": { "@value": "1200", "@type": "xsd:integer" },
             "unit": "http://dbpedia.org/resource/Dots_per_inch"
          }]
      }]

When transformed to TTL:

              odrl:action ex:URI_23244A;
ex:URI_23244A a odrl:Action;                      // <== this node is not an Action
              rdf:value odrl:print;
              odrl:refinement ex:URI_23245A.
ex:URI_23245A a odrl:Constraint;
              odrl:leftOperand odrl:resolution;
              odrl:operator odrl:lteq;
              odrl:unit "http://dbpedia.org/resource/Dots_per_inch"^^xsd:string;
              odrl:rightOperandReference ex:URI_23246R. // not included

The class of md:URI_23244A surfaces (implicit in JSON, hidden under the opening "[{" ).

When the example is swapped from an odrl:action to either odrl:target or odrl:function, it becomes confusing:

// ----------------------------------------------------------------
              odrl:target ex:URI_23244A;
ex:URI_23244A a odrl:AssetCollection;            // <== this is not an AssetCollection
              rdf:value ex:SomeAssetCollection;  // <== this is the collection
              odrl:refinement ex:URI_23245A.
// ----------------------------------------------------------------
              odrl:function ex:URI_23244A;
ex:URI_23244A a odrl:PartyCollection;            // <== this is not an PartyCollection
              rdf:value ex:SomePartyCollection;  // <== this is the collection
              odrl:refinement ex:URI_23245A.
// ----------------------------------------------------------------

From the diagram, the issue is:

[riannella]

When you transform Example 14 to turtle, you would get:

<http://example.com/policy:6161>  a odrl:Offer ;
  odrl:profile <http://example.com/odrl:profile:10> ;
   odrl:assigner <http://example.com/org:616> ;
   odrl:target <http://example.com/document:1234> ;
  odrl:permission [
    odrl:action [
      rdf:value odrl:print ;
      odrl:refinement [
        odrl:leftOperand odrl:resolution ;
        odrl:operator odrl:lteq ;
        odrl:rightOperand "1200"^^xsd:integer ;
        odrl:unit "http://dbpedia.org/resource/Dots_per_inch"^^xsd:string
        ]
      ] ;
  ] .

[joshcornejo]

That's the compressed syntax with anonymous nodes and leaves the node rdf:Class hidden (not clear if i had multiple nodes pointing at the same refinement for example), can we use the extended syntax (that's what comes out of the library, and that will tell me what is that I need to add when there is a refinement)

[vroddon]

odrl:print is an instance of the class odrl:Action.

If you need the object of an RDF triple referring to "printing", using that URI ("odrl:print") is enough and simple.
If you need to say more things about that fact of printing, we need another RDF resource, subject of other triples that refine it. Indeed, the first and foremost of such triples is the fact that we still referring to the printing action (odrl:print).
We do this by means of the rdf:value, as illustrated in the example above.
Indeed, in Turtle or in JSON-LD we can have such a resource fully anonymous, if you like it.

This is succintly explained in Section 2.5.4 of the ODRL model. Is the 'note' in that section enough (and the examples above in that section)? Or do you think it needs further clarification?

[joshcornejo]

The actions are a bit of a red herring. I am not talking about the property that points at the action, I am concerned about the "wrapper" class for the refinements. I think it needs further clarification, ideally in "fully qualified domains" as that is what the libraries need to add triples (even if you can then output "succinct").

As I explained above (copy/paste again), I have a refinement for an AssetCollection or a PartyCollection, odrl:target or odrl:function are not "pointing at " an AssetCollection or PartyCollection, they are "pointing at something else" and that "something else" now has an "rdf:Value".

// ----------------------------------------------------------------
              odrl:target ex:URI_23244A;         // <== the diagram says this is "pointing at an AssetCollection"
ex:URI_23244A a odrl:AssetCollection;            // <== this is not an AssetCollection
              rdf:value ex:SomeAssetCollection;  // <== this is the collection
              odrl:refinement ex:URI_23245A.
// ----------------------------------------------------------------
              odrl:function ex:URI_23249A;       // <== the diagram says this is "pointing at a PartyCollection"
ex:URI_23249A a odrl:PartyCollection;            // <== this is not an PartyCollection
              rdf:value ex:SomePartyCollection;  // <== this is the collection
              odrl:refinement ex:URI_23245A.
// ----------------------------------------------------------------

In other words: If I was building the SHACL for the classes that are the target for odrl:refinement - they are "not currently defined".

[vroddon]

The class you are looking for is odrl:Action (if the refinement is of an Action).
Please note that the odrl:action property, has defined as rdfs:range the Action class. This means, according to the RDFS semantics, that "any object in a triple where odrl:action is the property, has class odrl:Action".
We can explicitly declare that, if you like, but knowing that it can be inferred, it can be omitted.

In the examples you post, from the odrl:target property, we can infer that ex:URI_23244A is an odrl:Asset (or any of its subclasses, as odrl:AssetCollection). Therefore, in your examples, you do well by saying that ex:URI_23244A is a odrl:AssetCollection: in this case there was an ambiguity.

[riannella]

I think the rdf:value properties should be odrl:source properties.

[joshcornejo]

Forget the action example ...

@riannella @vroddon I believe we might be talking about different things, I will elaborate the example further with a couple of diagrams.

Somewhere, someone defines an asset collection:

md:some_catalog terms:accessRights odrl:distribute,
                                    odrl:use;
                 terms:accrualPeriodicity prov:freq-N;
                 terms:created "2024-08-22T14:08:23.0000000Z"^^xsd:dateTime;
                 terms:description "this is an example of a catalog"@en;
                 a odrl:AssetCollection,
                   fibo-fnd-acc-aeq:FinancialAsset,
                   dcat:Catalog;
                 owl:versionInfo "1.0"@en;
                 prov:generatedBy "someone@bank.ba"^^xsd:anyURI;
                 prov:version "1.0"@en;
                 dprod:informationSensitivityClassification md:public.

Now we move to the policy creation under ODRL:

• According to the diagram odrl:target should point at an odrl:AssetCollection (or action or partycollection).
• My policy user has two rules: a permission and a prohibition, the permission refines md:some_catalog, the prohibition doesn't.

The permission's target:

       odrl:target ex:URI_23244A;         // <== this is pointing at a **REFINEMENT** to an AssetCollection

The prohibition's target:

       odrl:target md:some_catalog;         // <== this is "pointing" at an AssetCollection

So ex:URI_23244A is not an AssetCollection, and the refinement should not be part of the asset's triples, because the ex:URI_23245A is a property of the refinement in the permission and not a property of the asset itself.

ex:URI_23244A a odrl:AssetCollection;            // <== this is not an AssetCollection
              rdf:value md:some_catalog;         // <== this is the collection
              odrl:refinement ex:URI_23245A.

I would argue that odrl:target md:some_catalog; is an abstraction that is a shortcut and "hiding" an intermediate node because it is not required, but it could also be represented:

[riannella]

When you say:
odrl:target ex:URI_23244A; // <== this is pointing at a **REFINEMENT** to an AssetCollection
How can this be?
The range of target is Asset ?

[joshcornejo]

The target might be defined in writing as an odrl:AssetCollection, but when you have 2 rules pointing at the same asset, with different requirements (one refinement, one not) and you lay it in a graph (as above) that the range comes into question.

I aim to show in the diagrams above: that it isn't in the range of an asset in the graph. There is a node that in a "single rule JSON" can look like it is implicit, but not in FQN RDF with multiple rules and different refinements on an element (in this example an AssetCollection.

To start, I hope we agree that ex:constraints is not a property of the odrl:AssetCollection, that is a requirement specified by a rule ex:some_permission within a policy, other rules within the same policy (ex:some_prohibition) could have different requirements (or not) and address the same asset.

When you output the RDF that includes an asset and a policy, in the example above ex:some_catalog doesn't have ex:constraints as properties (otherwise ex:some_prohibition should also consider them?)

As per the example above, this is a DCAT catalog:

ex:some_catalog terms:accessRights odrl:distribute,
                                    odrl:use;
                 terms:accrualPeriodicity prov:freq-N;
                 terms:created "2024-08-22T14:08:23.0000000Z"^^xsd:dateTime;
                 terms:description "this is an example of a catalog"@en;
                 a odrl:AssetCollection,
                   dcat:Catalog;
                 owl:versionInfo "1.0"@en;
                 prov:generatedBy "someone@bank.ba"^^xsd:anyURI;
                 prov:version "1.0"@en;
                 dprod:informationSensitivityClassification md:public.

And we can create a policy:

ex:policy   terms:created "2024-10-05T06:41:47.0000000Z"^^xsd:dateTime;
            terms:creator "some UUID"^^xsd:anyURI;
            terms:description "Example of an Offer"@en;
            terms:valid md:uri:225b96258645:23241I;
            a odrl:Offer;
            owl:versionInfo "0.1"@en;
            odrl:conflict odrl:prohibit;
            odrl:permission ex:demo_permission;
            odrl:prohibition ex:demo_prohibition;
            prov:version "0.1"@en.

The prohibition does look like the target is just the ex:some_catalog which is an odrl:AssetCollection:

ex:demo_prohibition a odrl:Prohibition;
                    odrl:action odrl:distribute;
                    odrl:target ex:some_catalog.

But you can't "attach" the refinement to ex:some_catalog for the permission:

ex:demo_permission a odrl:Permission;
                   odrl:action odrl:play;
                   odrl:target ex:some_catalog.  // the refinement shouldn't be a 'property' of the asset
                                                 // otherwise it will be triggered by other rules

It needs a class that binds the semantics "for this rule, the target has this refinement":

ex:demo_permission a odrl:Permission;
                   odrl:action odrl:play;
                   odrl:target ex:URI_23244A;

But ex:URI_23244A is not an asset ... is the binder for the permission that says "this asset has this refinement"

ex:URI_23244A a odrl:AssetCollection;            // <== this is not an AssetCollection, nor is the target
              rdf:value ex:some_catalog;         // <== this is the target AssetCollection
              odrl:refinement ex:some_constraints.

IMHO: odrl:target / odrl:function / odrl:action should have more detailed definitions for range.