Add on ODRL Policy Example

[riannella]

To help the user understand how to use the odrl:hasPolicy (in a DCAT description) can we add a more detailed example to section 8?
For example....

---

The below example shows how to express a dataset policy where the use of <ds4242> has very specific usage rules. In this case, the dataset can be read and derivatives can be created but no commercial use of the dataset is allowed. In addition, it is a requirement to register before the permissions are allowed.

 <ds4242> a dcat:Dataset ;
 # other dataset properties here...
 odrl:hasPolicy [ a odrl:Policy ;
    odrl:permission [ a odrl:Permission ;
       odrl:action ( <http://www.w3.org/ns/odrl/2/read>
                     <http://www.w3.org/ns/odrl/2/derive> ) ];
    odrl:obligation   [ a odrl:Duty ;
       odrl:action <https://schema.org/RegisterAction> ];
    odrl:prohibition   [ a odrl:Prohibition ;
       odrl:action <http://creativecommons.org/ns#CommericalUse> ];
  ] ;
] .

[andrea-perego]

Thanks for the proposal, @riannella .

We actually have an open issue about adding examples on licences and access rights (#676). We'll include your example.

[andrea-perego]

@riannella , I've added a slightly revised version of your example via PR #1339

Could you please check and tell me if you are happy with it?

[riannella]

Some comments/feedback:

1. Why did you move the hasPolicy to the Distribution level? The policy statements are more relevant at the Dataset/Series level (ie they are not access control statements)

2. In the green NOTE, please also add [ODRL-MODEL] with [ODRL-VOCAB]

3. In the para above that (Starting with "Finally...") I never understood what this means "...in addition to the corresponding [DCTERMS] property that matches the same ODRL policy type" ?
   I do not think there are any DCTERMS that match the ODRL policy type" ?

4. After the example can you add a bit more explanatory text:

   The above example does not explicitly define the ODRL Asset, so assumes the enclosing identified entity is the subject of the policy as per https://www.w3.org/TR/odrl-model/#policy-has. In addition, the example above follows the ODRL compact policy rules as per https://www.w3.org/TR/odrl-model/#composition-compact.`

[andrea-perego]

Thanks, @riannella . Please find my replies below.

2. In the green NOTE, please also add [ODRL-MODEL] with [ODRL-VOCAB]

Done - see 1fdb9d9

4. After the example can you add a bit more explanatory text:

   The above example does not explicitly define the ODRL Asset, so assumes the enclosing identified entity is the subject of the policy as per https://www.w3.org/TR/odrl-model/#policy-has. In addition, the example above follows the ODRL compact policy rules as per https://www.w3.org/TR/odrl-model/#composition-compact.`

Done - see 1fdb9d9

1. Why did you move the hasPolicy to the Distribution level? The policy statements are more relevant at the Dataset/Series level (ie they are not access control statements)

Because rights in DCAT should be specified on dcat:Distribution - see usage note in §6.7.5 Property: license :

Information about licenses and rights SHOULD be provided on the level of Distribution. Information about licenses and rights MAY be provided for a Dataset in addition to but not instead of the information provided for the Distributions of that Dataset. Providing license or rights information for a Dataset that is different from information provided for a Distribution of that Dataset SHOULD be avoided as this can create legal conflicts.

Is this conflicting with the definition and use of ODRL policies?

3. In the para above that (Starting with "Finally...") I never understood what this means "...in addition to the corresponding [DCTERMS] property that matches the same ODRL policy type" ?
   I do not think there are any DCTERMS that match the ODRL policy type" ?

Yes, probably we need to make the text clearer and add an example.

The idea is to complement the ODRL policy, when possible, with dcterms:license, dcterms:accessRights, dcterms:rights, for systems / catalogues / agents not able to understand ODRL. Of course, the two approaches are not going to be semantically equivalent in most cases.

E.g., considering the current ODRL example, this could be specified as follows:

:ds4242 a dcat:Dataset ;
# other dataset properties...
  dcat:distribution [ a dcat:Distribution ;
# other distribution properties...
    dcterms:license <https://example.com/nc-licence> ;
    dcterms:accessRights <http://data.jrc.ec.europa.eu/access-rights/registration-required> ;
    odrl:hasPolicy [ a odrl:Policy ;
      odrl:permission [ a odrl:Permission ;
        odrl:action ( 
          <http://www.w3.org/ns/odrl/2/read>
          <http://www.w3.org/ns/odrl/2/derive> 
        ) 
      ];
      odrl:prohibition [ a odrl:Prohibition ;
        odrl:action <http://creativecommons.org/ns#CommercialUse>
      ] ;
      odrl:obligation [ a odrl:Duty ;
        odrl:action <https://schema.org/RegisterAction> 
      ];
    ] ;
  ] ;
.

[dr-shorthair]

Because rights in DCAT should be specified on dcat:Distribution

While this is strictly true in principle - rights must be associated with a transferable artefact - it is both confusing and rather burdensome in practice. Rights are more usually associated with the dataset, and rarely vary between different distributions of the same dataset. I worry that our 'principled' stance here is too troublesome in practice.

[andrea-perego]

@dr-shorthair said:

Because rights in DCAT should be specified on dcat:Distribution

While this is strictly true in principle - rights must be associated with a transferable artefact - it is both confusing and rather burdensome in practice. Rights are more usually associated with the dataset, and rarely vary between different distributions of the same dataset. I worry that our 'principled' stance here is too troublesome in practice.

Associating rights with distributions is just re-stating the approach defined since the first release of DCAT, and how this is actually implemented in practice. It would be more troublesome to change these rules.

[riannella]

I would suggest removing the usage notes for 6.7.5 (or at least making it non-normative).
dct:licence, dct:rights,and odrl:hasPolicy are declared at the Resource level so all the sub-entities can utilise them at the level that is appropriate for the business requirements.

As an example, in ODRL, we also define an Asset as a Collection, which we can assert policies over, which includes all the members of that collection (and even only some members). This maps directly to a DataSet Series and its related dataset members. (see https://www.w3.org/TR/odrl-model/#constraint-asset)

[riannella]

In relation to my feedback#3 above, I think this will create more confusion, as now there is conflict as to what are the normative rights statements. For example, the two "registration" URIs will now need to analyzed and determined to be the same thing. This will be (close to impossible) to determine for all rights statements and ODRL policies.

I recommend that the statement "in addition to the corresponding [DCTERMS] property that matches the same ODRL policy type" be deprecated.

[andrea-perego]

In relation to my feedback#3 above, I think this will create more confusion, as now there is conflict as to what are the normative rights statements. For example, the two "registration" URIs will now need to analyzed and determined to be the same thing. This will be (close to impossible) to determine for all rights statements and ODRL policies.

I recommend that the statement "in addition to the corresponding [DCTERMS] property that matches the same ODRL policy type" be deprecated.

Thanks, @riannella . I think this deserves a separate discussion on how to properly use ODRL with DCAT. I will create a new issue on this, and link to it from the spec.

[andrea-perego]

Done: #1342 & d5a791a

[andrea-perego]

I would suggest removing the usage notes for 6.7.5 (or at least making it non-normative).
dct:licence, dct:rights,and odrl:hasPolicy are declared at the Resource level so all the sub-entities can utilise them at the level that is appropriate for the business requirements.

As an example, in ODRL, we also define an Asset as a Collection, which we can assert policies over, which includes all the members of that collection (and even only some members). This maps directly to a DataSet Series and its related dataset members. (see https://www.w3.org/TR/odrl-model/#constraint-asset)

@riannella , I don't see a conflict between the usage note in 6.7.5 and your points.

The note is not preventing the specification of rights at the level of dcat:Dataset, but it requires that, also in such a case, they are still to be specified at the distribution level as per the DCAT data model (and its implementations), in order to ensure interoperability across catalogues.

How this is implemented is, of course, up to data providers. E.g., in the scenario you outline, where rights are specified at the dataset level and "inherited" by distributions (as sub-entities), the relevant statements can be automatically generated (e.g., via a SPARQL CONSTRUCT query or an inference rule).

PS: I suggest we move further discussion on this topic to a dedicated issue.

[riannella]

See #1343

[andrea-perego]

See #1343

Thanks, @riannella .

PR #1339 is now under review by the DCAT editors.