Beyond LeftOperand and interoperability

[joshcornejo]

Asset Refinements:

Definition:

Refinement property with an Asset Collection An AssetCollection MAY include a refinement property to indicate the refinement context under which to identify individual Asset(s) of the complete collection. The refinement property applies to the characteristics of each member of the collection (and not the resource as a whole). To meet this condition of identifying individual Asset(s) of the complete AssetCollection, all of the Constraints/Logical Constraints referenced by the refinement property MUST be satisfied.

Summary: An Asset Refinement provides a mechanism to pick an asset (assets??) from a set based on the "property ... of each member of a collection".

So whilst the target is odrl:AssetCollection, the odrl:LeftOperand refers to properties of the collection members.

How assets and collections are defined: Modern asset definition standards like D-CAT provide a rich hierarchy of sets that align with odrl:AssetCollection (dcat:Catalog -[:catalog]-> dcat:Catalog -[:series]-> dcat:Dataset) that contain the equivalent of an odrl:Asset (dcat:Distribution).

The image below is an attempt to consolidate odrl / dcat and dprod and how they are interrelated in practice.

A refinement for an asset refers to a property in the collection that references the asset that contains such property.

In the case of a dcat:Catalog, the following properties reference "sets" of :

ex:SomeExampleCatalog a odrl:AssetCollection, dcat:Catalog ;
           dcat:catalog ex:AnotherCatalog ;
           dcat:service ex:ThisServiceAlsoCatalog ;
           dcat:dataset ex:OneMoreCatalog ;
            dcat:record ex:TheOnlyPossibleAsset ;

To overcome this, the recommendation to introduce the concept of "target" and allow implementers to work consistently and interoperably around these multi-level hierarchies:

Example: A refinement to filter on the asset's media type that is part of a catalog

target.dataset.distribution.mediaType

Example: A refinement to filter on the asset's compressed format that is a service connected to the catalog

target.service.servesDataset.distribution.compressedFormat

This proposal has the premise that the creator of the refinement has:

1. Knowledge of the relationships amongst the collection(s) and asset(s).
2. Supporting mechanisms to make sure the odrl:LeftOperand references a property of the asset

Important Note:

It is perhaps also required to clarify if a refinement can return odrl:AssetCollection (unclear from the language used), for example target.dataset.temporal is a property of the dataset instance and a refinement would return AssetCollections, that would require their policies to be (maybe unnecessarily?) evaluated to return an odrl:Asset,

Another case is target.dataset.distribution.mediaType as a property of the distribution instance, so mixing "temporal" and "mediaType" in a single refinement seems out of scope as the reference is to properties in different assets.

Party Refinements:

tbd:

• In practice, it is usually "simpler" organisation -> user (PartyCollection<-[:partOf]-Party)
• it would be preferable that refinements could be applied to odrl:Party

Action Refinements:

tbd:

• Good idea as it semantically attaches the action with the refinement, but not sure it makes any difference from applying it as rule constraint?
• Note: these examples are impossible to "track" (example 15)