Clarify vocabulary requirements for access rights

[streino]

GeoDCAT-AP 3.1.0 mentions two different vocabularies for access rights: INSPIRE-LPA and EUV-AR.

As DCAT-AP already defines the use of EUV-AR for access rights, and GeoDCAT-AP is an extension of DCAT-AP, how are the two vocabularies supposed to be articulated in GeoDCAT-AP, in order to both maintain compatibility with DCAT-AP and support mapping from INSPIRE?

GeoDCAT-AP version 3.1.0 suggest different articulations:

• Section 7.2 suggests extension, i.e. using the INSPIRE-LPA vocabulary in addition to the EUV-AR vocabulary:

  

• Sections 7.6 to 7.9 suggest override, i.e. using only the INSPIRE-LPA vocabulary (in the context of INSPIRE):

  

• Section 10.3.3 suggests reuse, i.e. using only the EUV-AR vocabulary:

  

• In a recent discussion about rights, it was suggested "[to] keep dct:accessRights for the access classification (PUBLIC/NON_PUBLIC) at Dataset [level]", suggesting the reuse of EUV-AR as well.

I find it difficult to reconcile the different quotes above, but the two most likely rules I could come up with are:

1. Use EUV-AR in non-INSPIRE context, and INSPIRE-LPA in INSPIRE context.
   If this rule is correct, my impression is that GeoDCAT-AP would break compatibility with DCAT-AP in INSPIRE context. GeoDCAT-AP being an extension of DCAT-AP, my understanding is this should not happen.

2. Use EUV-AR in non-INSPIRE contexts, and EUV-AR extended with INSPIRE-LAP in INSPIRE contexts.
   If this rule is correct, how should the two vocabularies be articulated in INSPIRE contexts? I could imagine using EUV-AR terms when synonymous to INSPIRE-LAP (e.g. no limitations on public access == PUBLIC => PUBLIC) and INSPIRE-LAP when more specific ((e.g. Article 13(1)(a) ⊂ NON_PUBLIC => Article 13(1)(a)), but this still means some level of incompatibility with DCAT-AP.

It would be helpful to clarify what is(are) the expected vocabulary(ies) in the INSPIRE context, and to ensure the various sections mentioned above all provide complete and consistent information.

[jakubklimek]

The intention was indeed the first one:

Use EUV-AR in non-INSPIRE context, and INSPIRE-LPA in INSPIRE context.
If this rule is correct, my impression is that GeoDCAT-AP would break compatibility with DCAT-AP in INSPIRE context. GeoDCAT-AP being an extension of DCAT-AP, my understanding is this should not happen.

The EUV-AR in DCAT-AP and GeoDCAT-AP is RECOMMENDED, not MUST, so it is possible to use INSPIRE-LPA instead. It is currently not possible to use both, as the access rights property has a [0..1] cardinality.

I admit that it is not crystal clear what to do to fully satisfy both INSPIRE and DCAT-AP in this case.

The options I see are:

1. Find a mapping from INSPIRE-LPA to EUV-AR and use only EUV-AR - however, this does not seem very likely to be satisfactory, as the codelists seem to be quite different in contents, therefore this would result in information loss
2. Create a new property to be used with INSPIRE-LPA - this would enable publishers to use both codelists and preserve all information
3. Escalate to DCAT-AP a request to lift the cardinality constraint for access rights - however, it would require clarification on the fact that multiple items from the EUV-AR cannot be used at once.

Just to clarify, the two vocabularies currently look like this:
EUV-AR:
Here it is in the same GitHub Markdown table format, with Valid since and Valid until excluded:

Code	Label	Definition
CONFIDENTIAL	confidential	Information that is not disclosed. Usage note: Disclosure of this data could cause damage to interested parties such as public administrations and businesses. It may refer to personal and professional information as well as to information in the context of business, commerce or trade.
NON_PUBLIC	non-public	Not publicly accessible for privacy, security or other reasons. Usage note: This category may include resources that contain sensitive or personal information.
NORMAL	normal	Publicly accessible. This concept has been used in the schemas of IMMC, the Interinstitutional Metadata Maintenance Committee, as the predecessor of the current concept ‘public’.
PUBLIC	public	Publicly accessible by everyone. Usage note: Permissible obstacles include registration and request for API keys, as long as anyone can request such registration and/or API keys.
RESTRICTED	restricted	Only available under certain conditions. Usage note: This category may include resources that require payment, resources shared under non-disclosure agreements, resources for which the publisher or owner has not yet decided if they can be publicly released.
SENSITIVE	sensitive	Sensitive non-classified (SNC) information, information whose unauthorised disclosure could cause damage to the Commission or other interested parties such as businesses, companies, intellectual property or personal data but which is not EU classified information.

INSPIRE-LPA:

Label	Definition
no limitations to public access	There are no limitations on public access to spatial data sets and services.
public access limited according to Article 13(1)(a) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect the confidentiality of the proceedings of public authorities, where such confidentiality is provided for by law.
public access limited according to Article 13(1)(b) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect international relations, public security or national defence.
public access limited according to Article 13(1)(c) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect the course of justice, the ability of any person to receive a fair trial or the ability of a public authority to conduct an enquiry of a criminal or disciplinary nature.
public access limited according to Article 13(1)(d) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect the confidentiality of commercial or industrial information, where such confidentiality is provided for by national or Community law to protect a legitimate economic interest, including the public interest in maintaining statistical confidentiality and tax secrecy.
public access limited according to Article 13(1)(e) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect intellectual property rights.
public access limited according to Article 13(1)(f) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect the confidentiality of personal data and/or files relating to a natural person where that person has not consented to the disclosure of the information to the public, where such confidentiality is provided for by national or Community law.
public access limited according to Article 13(1)(g) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect the interests or protection of any person who supplied the information requested on a voluntary basis without being under, or capable of being put under, a legal obligation to do so, unless that person has consented to the release of the information concerned.
public access limited according to Article 13(1)(g) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect the interests or protection of any person who supplied the information requested on a voluntary basis without being under, or capable of being put under, a legal obligation to do so, unless that person has consented to the release of the information concerned.
public access limited according to Article 13(1)(h) of the INSPIRE Directive	Public access to spatial data sets and services would adversely affect the protection of the environment to which such information relates, such as the location of rare species.

[streino]

Thank you @jakubklimek for providing all the extra context and clarifying intent.

My feedback on the options:

• Option 1 seems like the better option in theory, if a mapping is indeed possible. Or could EUV-AR simply be extended with the INSPIRE-LPA article terms? It may not be problematic that some terms overlap in scope, as INSPIRE records will use INSPIRE terms, and non-INSPIRE records won't; so selection process is clear and there's no loss of information.
• Option 2 seems like the less desirable solution, as it would create a field identical in purpose and definition (declaring access rights), only different in the vocabulary it accepts. It's also less robust since it could introduce discrepancies between the multiple declarations of access rights.
• Option 3, unless option 1 is preferred (and doable), seems like the most practical one. It is however vulnerable to the same robustness issue as option 2.

[bertvannuffelen]

Maybe an alternative variant from Option 1 is that one looked to this from a policy side perspective.
Given the revision of the policy, one could see here also an opportunity to take this mapping as a the outcome of the obligatory Interoperability Assessment: i.e. one aligns the generic accessibility notions with specific directive notions.

So for me this is an excellent place where juridical alignment with a coordinated data support could happen.

On the side, the HVD expects PURIs for licences and rights; this property is strongly related with that; yet it is different. Namely the default licence CC-BY 4.0 is probably connected to PUBLIC/"no limitations to public access". From the moment there is any kind of restriction then maybe the CC-BY-4.0 is not anymore applicable.
Legal experts (cfr those that created https://data.europa.eu/licensing-assistant/licences?locale=en&license_id=CC-BY4.0) may provide a harmonised view/perspective.

Option 2 and Option 3 are essentially data specification mitigating actions to avoid such (mapping) coordination.

The reason why I am in favor of opening to a legal/policy discussion is that in the past there were also remarks on the EUV_AR list and its usage. And that can only be answered by legal/policy foundation.

ps. A quick look at the values may suggest a mapping:

• "no limitations to public access" -> "PUBLIC"
• most other -> "RESTRICTED" but "SENSITIVE" could be in some cases

Indicating that the EUV_AR is a more abstract formulation of the INSPIRE article 13.