Rename accessLevelComment to rights

[philipashlock]

Several other issues have been aimed at better aligning the schema with DCAT (eg #350, #335, #272, #217) and this is another. In DCAT, the rights property can be used to refer to both intellectual property rights as well as rights regarding other access policies. It's range is defined by DublinCore RightsStatement and the more specific property in DublinCore that this aligns with is accessRights, but since they both use the same range defined by DublinCore and it makes sense to continue to align with DCAT, it seems like we should just stick with rights even if it's slightly less specific.

In Dublin Core, RightsStatement is defined as:

A statement about the intellectual property rights (IPR) held in or over a Resource, a legal document giving official permission to do something with a resource, or a statement about access rights.

In Dublin Core, accessRights is defined as:

Definition: Information about who can access the resource or an indication of its security status.
Comment: Access Rights may include information regarding access or restrictions based on privacy, security, or other policies.

We currently define accessLevelComment as:

An explanation for the selected “accessLevel” including instructions for how to access a restricted file, if applicable, or explanation for why a “non-public” or “restricted public” data asset is not “public,” if applicable.

My recommendation is to rename the field to be compatible with Dublin Core and DCAT (i.e. use rights), but to keep our definition and guidance essentially the same. The only thing I would suggest is that we could expand or clarify the definition to include any other details about use rights and restrictions that might be specific to this dataset if they're not already covered by the explanation for accessLevel e.g.:

This may include information regarding access or restrictions based on privacy, security, or other policies. This should also serve as an explanation for the selected “accessLevel” including instructions for how to access a restricted file, if applicable, or explanation for why a “non-public” or “restricted public” data asset is not “public,” if applicable.

[gbinal]

This makes sense to me.

Here's what it would look like: https://gist.github.com/philipashlock/21ff607527863fba200b#file-pod-schema-v1-1-draft-example-json-L4

[gbinal]

This issue is addressed in the following commit to the v1.1 metadata branch:

dab4706

[dsmorgan77]

Reviewing the DCAT spec, I don't think this is correct. DCAT only uses rights to describe intellectual property rights, and the property either belongs at the catalog level or at the distribution level.

dct:license, which is a sub-property of dct:rights, can be used to link a distribution to a license document. However, dct:rights allows linking to a rights statement that can include licensing information as well as other information that supplements the licence such as attribution.

[philipashlock]

@dsmorgan77 in DCAT, rights is defined by the dct:RightsStatement class which comes from Dublin Core and is described as:

A statement about the intellectual property rights (IPR) held in or over a Resource, a legal document giving official permission to do something with a resource, or a statement about access rights.

(emphasis mine)

As I mentioned before, this is a slightly broader definition than accessRights which seems like the main use case we'll have, but as the part I put in bold indicates, RightsStatement does specifically call out this use. In other words, rights is synonymous with RightsStatement which is used not only for intellectual property rights but also access rights and supplemental information associated with them.

The fact that this is broader than license information is also noted in the usage notes for rights in DCAT:

dct:license, which is a sub-property of dct:rights, can be used to link a distribution to a license document. However, dct:rights allows linking to a rights statement that can include licensing information as well as other information that supplements the licence such as attribution.

(emphasis mine)

Since accessRights also has a range of RightsStatement I reused the same language from accesRights for the additional sentence in our documentation.

As far as I understand (based on feedback from @jpmckinney) while the DCAT documentation does associate rights and license with Catalog and Distribution rather than the Dataset it doesn't restrict them from being used there since it doesn't specify a limited domain for those properties. I do think that we could emphasize this more in the documentation though - that when you specify the license and rights for a dataset you're applying those to each distribution.

[dsmorgan77]

I agree that rights is synonymous with RightsStatement and I understand the range issue. But I think that what you're saying is that both license and accessRights are subproperties of 'rights'.

I do not agree with your interpretation of the DCAT language. accessRights is not information the supplements the license, it's separate and different from license.

My point here is that assigning the term rights when we mean accessRights is imprecise.

[philipashlock]

@dsmorgan77 I agree that historically, we used accessLevelComment more like the limited definition of accessRights rather than the broader use of rights but since rights includes our use case and we currently have no way of accommodating the other use cases of rights, I don't see any harm in moving to this broader definition. I agree it would be imprecise if we only used rights as defined by accessRights and I do think that will be the primary use, but we don't have to be limited to that use case.

I never said that accessRights would supplement the license, I said that rights can which I quoted directly from the DCAT docs.

[philipashlock]

I think rights associated with things like HIPPA and FERPA probably make more sense with rights than accessRights since they're both about protecting rights for your data as well as limiting your rights for not only accessing but using data about other people

[rebeccawilliams]

I agree with @dsmorgan77 that accessRights would be the more precise field name to address what accessLevelComment has been used for, namely security and privacy protections.

FWIW, license and accessRights are listed as DCMES refined elements of rights here, which jives with my understanding that there needed to be a way to distinguish between legal reuse rights and legal access rights.

Are there reasons why DCAT did not also include the accessRights field? This is all I turned up.

Are there cons to renaming accessLevelComment to accessRights here other than that DCAT does not currently also use that field? Is that con enough?

[philipashlock]

@rebeccawilliams When it's the definition you need accessRights is more precise which can be seen as a 👍, but it's also more limiting which can be seen as a 👎 since it might not accommodate use cases we'd want to cover. I think accessRights may actually be a narrower definition than we need

Something like the NCES Data Usage Agreement is a good example that's about usage rather than access and the usage isn't about intellectual property as would be covered by license

Here's another example:

Federal law and regulations require that research data collected by the U.S. Department of Justice or by its grantees and contractors may only be used for research or statistical purposes. The applicable laws and regulations may be found in the United States Code, 42 USC Section 3789g(a), the Code of Federal Regulations, 28 CFR 22, and 62 F.R. 35044 (June 27, 1997) (The Federal Confidentiality Order). Accordingly, any intentional identification or disclosure of a person or establishment may violate federal law as well as the assurances of confidentiality given to the providers of the information.

[philipashlock]

There's also a related discussion in #222 where it does seem like the original intent of accessLevel and the clarification provided by accessLevelComment was to cover both access restrictions and usage restrictions which to me seems like an argument that accessRights might be too restrictive. I also think it makes sense to have license more focused on specific licenses for intellectual property rather than use it to cover more nuanced rights as you might with rights

[dsmorgan77]

These are good use cases. Usage notes, terms of use, and/or usage restrictions (like @philipashlock's reference of the NCES Data Usage Agreement), as I pointed out in #222, actually aren't able to be documented anywhere in the schema today.

As you noted in your original proposal, the definition of accessRights states

Access Rights may include information regarding access or restrictions based on privacy, security, or other policies.
IMHO, terms of use like the NCES Data Usage Agreement are basically "other policies", so I think accessRights still works here...and aligns with the proposal's changes to the definition of the field.

Totally agree that license should be clearly focused on intellectual property.

[rebeccawilliams]

If the NCES example didn't include the reuse permissions beyond our agreed IP scope of license I would think accessRights would apply here, but since it does, I reluctantly think the broader defined rights field would be the right call here.

Given the current accessLevel option of Restricted Public, I think there might be additional examples like this where the broader rights field is more useful, though I wonder if AccessLevel should be revisited in another thread at another time. [In an ideal world Non-Public (or Private) datasets would require an accessRights input and Restricted Public would have a broader rights input available if applicable for cases like this NCES example].

👍 on rights for this at this time.

[dsmorgan77]

👍 on revisiting how we deal with rights more generally at a later date and 👍 on living with what we have for this version (rights).

[gbinal]

Great. Thanks everyone for helping to tighten this up. With the original change now merged in as part of v1.1 metadata update, I'm going to go ahead and close this issue.

Project Open Data is a living project though. Please continue any conversations around how the schema can be improved with new issues and pull requests!