Denote datasets as high-value datasets (HVD)

[oystein-asnes]

Userstories:

1. As a data provider (and/or national body responsible for reporting status on the availability on high value datasets) there is a need to denote datasets as HVD according to a common metadata standard accross EU (aka DCAT-AP) so that the Commission's reporting requirements can be automated as much as possible

2. As a data portal user (and possible data consumer), I need a fast and easy way of finding HVD accross memberstates, so that i don't spend my life searching for HVD on the national dataportals and/or on EDP.

Context: According to the public consultated Implementing Act of the ODD Directive (not final), High Value Datasets must be denoted as such in the data calalogs:

(5) Public sector bodies holding high-value datasets listed in the Annex shall ensure that the datasets are denoted as high-value datasets in their metadata description.

This points in the direction of possible automated reporting, using the national data portals (and/or EDP) as source.

[jakubklimek]

I agree. In addition, only saying "this is HVD" will not be enough. We need to be able to annotate the dataset at least with the HVDs data topic like "company data", etc. This would mean curating an Authority table at EU Vocabularies containing the identified HVDs topics.

[kuldaraas]

+1 from Estonia. We are about to implement the same addition in our national data portal. However, technically the question is if:

option a: to add a simple boolean element (like: "isHighValue") and assume that dcat:theme is sufficient to cover the data topic; or

option b: add a separate "HVD" element where you also need to fill the topic, effectively creating dataset descriptions with two topics.

Both of the options are with their pro's and con's - a) is easier for the creators of descriptions while might make searching for specific HVD datasets more difficult ((if the default topic vocabulary does not match with HVD topics). b) is a bit more difficult for people to fill (need to select something as opposed to just checking a checkbox), and might create some redundancy, should the "topic" and "HVD topic" overlap. But offers more for powerful searches.

Are there any other options in sight?

[bertvannuffelen]

On this topic, I would like to pitch the following idea, beyond "simple keyword annotation".

The directive Directive (EU) 2019/1024 - This page provides a high level reading - has as objective to make data in some area more accessible. It thus come with some minimum expectations. These minimum expectations are currently being defined as part of the implementing act by https://ec.europa.eu/transparency/comitology-register/screen/committees/C51600/consult?lang=en . (Maybe some of you are part of this committee).

My suggestion is to create a subprofile of DCAT-AP for HVD that captures all these requirements to create a collection of well interconnected datasets and dataservices. E.g. one of the requirement for a HVD is the presence of an API. Thus the profile could reflect this by mandatory requiring that for each HVD a dataservice exists with a public endpoint.

Personally, only adding a keyword "HVD" is very shallow and does not addresses the objectives of the directive in full. It is easy for data portal owners, but it will not guarantee that the intention of the directive has been achieved.

ps. From the high level reading, one might be even estimate that the targeted themes cover about 60% of todays' content of data.europa.eu. So just tagging makes the majority HVD, and I doubt that was the objective. I suspect that HVD is a definition with quality requirements and with content requirements.

[jakubklimek]

ps. From the high level reading, one might be even estimate that the targeted themes cover about 60% of todays' content of data.europa.eu. So just tagging makes the majority HVD, and I doubt that was the objective. I suspect that HVD is a definition with quality requirements and with content requirements.

Just to clarify, I do not suggest tagging everything that falls into HVDs theme by that HVDs theme. I suggest that publishers, who know that their dataset falls into one of the HVDs topics and are aware of the quality requirements and obligations, tag those datasets with an HVDs topic. That would not be every dataset thematically relevant to an HVDs topic.

Even if we went the way of a profile (lets say DCAT-AP-HVDS), there would have to be a property assigning an HVDs topic anyway, right?

[kuldaraas]

@bertvannuffelen could you set up an informal call to discuss the options and way forward among the experts in this thread?

[bertvannuffelen]

ps. From the high level reading, one might be even estimate that the targeted themes cover about 60% of todays' content of data.europa.eu. So just tagging makes the majority HVD, and I doubt that was the objective. I suspect that HVD is a definition with quality requirements and with content requirements.

Just to clarify, I do not suggest tagging everything that falls into HVDs theme by that HVDs theme. I suggest that publishers, who know that their dataset falls into one of the HVDs topics and are aware of the quality requirements and obligations, tag those datasets with an HVDs topic. That would not be every dataset thematically relevant to an HVDs topic.

I cannot make here a statement, as this would be part of the implementing act. Suppose they have circumscribed that every statistical dataset that is within the scope of Eurostat is a HVD, than almost all statistical datasets in data.europa.eu are HVD.

Even if we went the way of a profile (lets say DCAT-AP-HVDS), there would have to be a property assigning an HVDs topic anyway, right?

@jakubklimek , this would probably be part of the profile in my opinion. At least to make distinction between those that are part of the directive and those that apply the same quality levels and are not (yet) part of the directive.

But as you clearly stated, adding only a keyword/subject/theme would leave the HDV-responsibles on an island, as every responsible has to find out the requirements.

My proposal is that we consider as metadata community how we can support them via the metadata, so that the "dream" of a coherent, open data landscape in Europe can realized. I am aware my proposal will have limits, but I think it also brings a potential.

Relating back to the geospatial domain, that is so regulated that in principle you can use any geospatial client to process data from any country. (In the practice it holds for the technical access, but less for the content). I do not think this should be the overall ambition of the new profile, but a little more structure and alignment could make a big difference.

[bertvannuffelen]

@bertvannuffelen could you set up an informal call to discuss the options and way forward among the experts in this thread?

sure. I will check with the SEMIC team how we best organise this.

[GKStGovData]

on DCAT-AP.de we recommend dct:references to point to a related "Musterdatensatz". We suggest to link via dct:references to a HVD-URI-List as an easy option for data providers to relate their Dataset to HVD.

[oystein-asnes]

A humble attempt to further explore the spectrum between "HVD true/false" and making a dedicated application profile for HVDs.

1. Use dct:type to identify datasets as HVDs? Will solve HVD true/false, and can be further faceted by dcat:theme. Low efforts and low gain but still something to consider since it is simple (and cheap) and makes it very easy to filter HVDs without messing with keywords. Action needed: Add a HVD-concept to the dataset type authority list.

2. Use dct:conformsTo to refer to a HVD domain specification? A bit more ambitiously than true/false since it also provides information about domain and associated conditions defined by the Implementing Act. Action needed: Provide documents (with URIs) for each HVD domain specifying the conditions the HVD-dataset is compliant with.

3. Use dcat:theme to identify HVDs? Action needed: provide a thematic scheme (skos:ConceptScheme) designed for identifying the very same HVDs across MS/portals/languages

[tursics]

We should split bullet 2 in two variants:

2a. Use dct:conformsTo respectively dct:conformsTo 2b. Use dct:references

dct:conformsTo

"An established standard to which the described resource conforms." and "In this context, it is any resource that specifies one or more aspects of the cataloged resource content, for example schema, semantics, syntax, usage guidelines, file format, or specific serialization."

dct:references

"A related resource that is referenced, cited, or otherwise pointed to by the described resource." and "This property is an inverse property of Is Referenced By."

My personal view: HVD is not a standard. A dataset can't be compliant with a HVD category. So it's not a dct:conformsTo. The user of the open data portal is looking for a list of HVD compliant datasets. He/she is looking for datasets referenced by a HVD category.

[jakubklimek]

Well, ideally, there would be an HVD standard created for each HVD category. Then it would make sense to link to it using dct:conformsTo. An example of such approach can be seen in the HVD category of Company data with the STIRData project and the specification developed there. Unfortunately, that is not happening anytime soon for majority of HVD categories.

dct:references points to another dcat:Resource in a dcat:Catalog. This would assume that there is a dcat:Catalog of HVD categories as dcat:Resources. This can be done, so it is definitely a viable alternative, but IMHO it is easier to just add a code list to EU Vocabularies and use dcat:theme.

[oystein-asnes]

Agree with @jakubklimek . dct:references points to another dcat:Resource in a dcat:Catalog. In DCAT-AP the usage note for dct:ConformsTo states:

This property refers to an implementing rule or other specification.

And over at dublincore.org:

A reference point against which other things can be evaluated or compared.

Conditions for each HVD category is defined by the annex of the Implementing Act to ensure a bare minimum of interoperability across MS. If these conditions are published in a proper way, I still think dct:conformsTo is a more obvious choice.

Further standardisation is indeed needed, just as @jakubklimek says.

[sirex]

3. Use dcat:theme to identify HVDs? Action needed: provide a thematic scheme (skos:ConceptScheme) designed for identifying the very same HVDs across MS/portals/languages

-- @oystein-asnes

I think, for a rough estimate, what are HVDs, dcat:theme is enough. And it is relatively easy to do.

Once this is done, then we could move to the next step:

2. Use dct:conformsTo to refer to a HVD domain specification? A bit more ambitiously than true/false since it also provides information about domain and associated conditions defined by the Implementing Act. Action needed: Provide documents (with URIs) for each HVD domain specifying the conditions the HVD-dataset is compliant with.

-- @oystein-asnes

But in order for this to work, EU should provide RDF vocabularies for HVDs, then it will be possible to validate if a dataset dct:conformsTo HVD vocabularies or not. Of course, data itself should be available in a one of RDF serialization formats.

1. Use dct:type to identify datasets as HVDs? Will solve HVD true/false <...>

-- @oystein-asnes

I think, adding true/false HVD property for a dataset is too ambiguous and will raise too many questions from data providers. Also this will require modification to catalog software. I think in general this is a bad idea. IMHO dcat:theme and dct:conformsTo is more than enough, there is not much room for subjective interpretation and there is no need to add a special flags to catalogs.

[bertvannuffelen]

@all,

After the webinar on DCAT-AP on 25 November 2022 from 14:00 to 16:00, the informal meeting on HDV will take place. I am happy to see that the DCAT-AP community is discussing this topic, because I believe we facilitate the directive. After the webinar we can exchange ideas to address this.

One remark I already would like to make before our meeting that HDV is not solely a metadata issue, but also a policy challenge. To a large extend DCAT(-AP) will offer the metadata elements to describe a HDV, and that we can describe together, but it should be adopted and supported by the HDV policy officers. When possible, reach out to your policy officer in your EU MS to know the impact and the future on how they see HDV impacting the data landscape in their MS.

[H-a-g-L]

1. Use dct:type to identify datasets as HVDs? Will solve HVD true/false, and can be further faceted by dcat:theme. Low efforts and low gain but still something to consider since it is simple (and cheap) and makes it very easy to filter HVDs without messing with keywords. Action needed: Add a HVD-concept to the dataset type authority list.

+1 for using dct:type with a new value to be added in the https://publications.europa.eu/resource/authority/dataset-type/ list. This will satisfy the requirement in the draft Implementing Act to denote HVDs as such and support their faceting in data.europa.eu. If this sounds reasonable, I can contact my colleagues at the Publications Office asking to add the HVD Concept.

How to use dcat:theme and/or dct:conformsTo for faceting is a more complex discussion and may require a new Vocabulary (possibly to be developed by the Publications Office). However, I would consider the use of these properties as sub-levels in the sense that declaring a dataset as HVD does not exclude the possibility of specifying these.

[oystein-asnes]

I think, adding true/false HVD property for a dataset is too ambiguous and will raise too many questions from data providers. Also this will require modification to catalog software. I think in general this is a bad idea. IMHO dcat:theme and dct:conformsTo is more than enough, there is not much room for subjective interpretation and there is no need to add a special flags to catalogs.

@sirex The member states must report status to the commission and it is suggested that this can be done via metadata. We must embrace this and it is therefore important to be sufficiently ambitious and not ambiguous. Data providers should know whether their data is covered by the HVD/ODD regulation or not. Our approach to resolving this in the metadata cannot save providers from confusion here. HVD is pretty well-defined and it should be quite binary what is in or out of scope.

The dct:type approach requires a non-breaking change in one of DCAT-AP's supporting controlled vocabularies. It does not break anything, but requires a catalog software that is up to speed with the Publication Office's authority tables.

If a dataset is in or out of scope of the HVDs is not enough information for reporting purposes, but supported by a more fine grained dcat:theme vocabulary for HVDs we might be closer.

This issue may require a dedicated application profile as @bertvannuffelen suggests, but at least from a distance it looks like that will hit the different catalog software solutions harder.

[bertvannuffelen]

@sirex The member states must report status to the commission and it is suggested that this can be done via metadata. We must embrace this and it is therefore important to be sufficiently ambitious and not ambiguous. Data providers should know whether their data is covered by the HVD/ODD regulation or not. Our approach to resolving this in the metadata cannot save providers from confusion here. HVD is pretty well-defined and it should be quite binary what is in or out of scope.

I agree we should consider the reporting aspect as one of our main topic of discussion. If the report requires to provide info about X then it should be clear how X is derived from the metadata.

This issue may require a dedicated application profile as @bertvannuffelen suggests, but at least from a distance it looks like that will hit the different catalog software solutions harder.

Actually one should not shoot at the application profile, it is the directive that imposes this. The application profile I propose should be a reflection of the the needs expressed by the directive. The reason why I proposed a new application profile is that some of the datasets/data services must comply to DCAT-AP and DCAT-HDV, and some only to DCAT-AP.

Personally I do not like to mix the two together in one text. Then the motivation for DCAT-AP is EU harmonisation, and DCAT-HDV is satisfy the HDV directive. Writing complex usage notes like: "In case the dataset is subject to HDV then this attribute is mandatory and must have a value from this codelist but in case it is not subject to HDV the attribute is recommended, but with an open choice of codelist usage " is not helping the data providers and catalogue builders.

I still believe/hope that DCAT-HDV would be a subprofile of DCAT-AP: as an additional layer of quality for the metadata for those datasets/data services that are subject to HDV. Before making final statements about it I wait for the implementing act to be finalized.

[sirex]

In Lithuanian open data portal, we are planning to use dcterms:type to specify if a dataset is HVD, and dcat:theme.

The only question what URI should we use, to identify HVD type?

And is there a vocabulary for dcat:theme, that referes to HVD categories?

For example:

ex:dataset-001 a  dcat:Dataset ;
  dcterms:type  <???/HVD> ;
  .

and what URI should be used to map each HVD category?

ex:geospatial a skos:Concept ;
  skos:prefLabel "Geospatial"@en ;
  skos:exactMatch <???/Geospatial> ;
  .

ex:dataset-001 dcat:theme ex:geospatial .

What should I put in places of ????

[oystein-asnes]

@sirex The dataset type vocabulary is to be used for dct:type. If this approach is chosen, I suggest The Publication Office (with a push from @ODP-hil?) includes HVD and provides the URI you need.

The data theme vocabulary (to be used for dcat:theme) does not include geospatial. In fact, none of the HVD categories (geospatial, earth observation and environment, meteorological, statistics,companies and company ownership, mobility) does fit very well with the data theme voc. (except the close match between mobility and transport). Even with a separate AP for HVDs , a common dcat:theme vocabulary for HVDs and non-HVDs would be nice to have. Time to expand the data theme vocabulary ?

[H-a-g-L]

Thanks for the comment @oystein-asnes . @sirex I would suggest using something like:

ex:dataset-001 a  dcat:Dataset ; 
    dct:type <http://publications.europa.eu/resource/authority/dataset-type/HVD>

Hopefully the new term will be added already in the December publication of OP Authority tables although it may not yet include the skos:prefLabel for all EU languages.

As for the thematical category, I don't think the data-theme List should be revised to include specific HVD categories. The List is for top level classification and adding more specific terms will disrupt its character. If, as suggested by @bertvannuffelen, a specific HDV Application Profile will be developed, the thematic categorisation could use a new HVD Thematic List to be published by the Publications Office. Another option could be to use the INSPIRE Theme or other vocabularies still.

[init-dcat-ap-de]

After looking into the "arrangements" for HVDs, we better understand your (@bertvannuffelen) idea to create a DCAT-HVD-AP. We are still against it, for two reasons:

1. it is not feasible to force data contributors to adhere to different application profiles, especially if we want to do the reporting from the regulary harvested meta data
2. the regulation is very complex. We don't think that, even a maxed out, application profile could check for full complience. There is probably a human needed, confirming something is a HVD.

Therefor we suggest an easier approach:

dcatap:HighValueDataset, a sub-class of dcat:Dataset. One class per category as sub-class of dcatap:HighValueDataset.

Adding mandatory properties to dcatap:HighValueDataset, if

• all sub-classes (categories) have this requirement and
• the property already exists in DCAT-AP.

Adding mandatory properties to dcatap:HVD-{category}, if

• all datasets in this category have this requirement and
• the property already exists in DCAT-AP.

[jakubklimek]

@init-dcat-ap-de I agree with the approach, but I would like to point out that there are some pros and cons. Listing the HVDs subclasses in DCAT-AP means updating DCAT-AP whenever new HVDs subclasses arise. However, this approach allows us to specify further properties necessary for certain HVDs categories. The other option is the HVDs category codelist - this would decouple updating DCAT-AP from HVDs updates, but would not allow us to nicely state necessary attributes of certain HVDs datasets.

[init-dcat-ap-de]

Yes, if we want to check anything about the HVDs, I think the dcatap:HVD-{category} classes are needed, because there is, o first sight, not much overlap between those dcatap:HVD-{category}s.

[bertvannuffelen]

2. the regulation is very complex. We don't think that, even a maxed out, application profile could check for full complience. There is probably a human needed, confirming something is a HVD.

Depends on how far you want to be able to force the harmonisation. Part of the HVD requirements are about the used API structures and the used data schema's, that is by definition beyond DCAT-AP. If the implementing act imposes that the data must be accessible on an SDMX endpoint and this must adhere to a schema specified in a PDF document, then this can only be machine wise validated if there is an conformance checking system being provided. But that is beyond DCAT-AP.

Nevertheless it might be useful to consider this case, from a metadata perspective: namely how we can define usage rules of the metadata so that someone could query data.europa.eu for information so that it could do a manual check.

This is for me a usecase DCAT-AP could support. At least it should indicate if the metadata is worth to query for this case or not.

[bertvannuffelen]

1. it is not feasible to force data contributors to adhere to different application profiles, especially if we want to do the reporting from the regulary harvested meta data

Let me disagree here: datasets expressed as StatDCAT-AP are also valid DCAT-AP. Thus why should that be problematic? My intention is not to create a conflicting profile to DCAT-AP but a sub profile. So If one would annotate a dataset according to DCAT-AP-HDV one gets higher quality metadata than the one of DCAT-AP,

If the HDV directive (reporting) imposes conflicting requirements to DCAT-AP then we should discuss that. Then the directive might force us all to do extra work, and that is not my intention. My intention is to maximize the use of DCAT-AP. So your proposal goes even further then I was thinking of.

Note that as specification, DCAT-AP is not imposing any editorial flow/setup. Any change to include the HDV requirements in an existing editorial system are thus originating from HDV and not whether these are expressed as rules in DCAT-AP or as rules in a subprofile of DCAT-AP. My objective with the application profile is simply to keep the document focussed on HDV requirements and not to mix it with any other scope requirement.

[GKStGovData]

Agree that the HVDs should be mapped as best as possible in DCAT-AP, so that they can be found. Ideally, HVD reporting can also be covered by DCAT-AP.

But we should consider the implementability for data providers (also e.g. on federal level) and portal owners.

If the sub-profile DCAT-AP-HVD has additional mandatory fields compared to DCAT-AP, it can become quite complex in practice. Currently, for example, there are still no valid DCAT-AP records after validation in the EDP: https://data.europa.eu/mqa/?locale=en

We should ensure that the adopted solution is validatable from the beginning.

[bertvannuffelen]

For the community: a high-level description on HDV - https://data.europa.eu/en/publications/datastories/high-value-datasets-overview-through-visualisation

[H-a-g-L]

The new release of the dataset-type named authority table added the skos:Concept for High Value Datasets. The URI to denote it is: https://publications.europa.eu/resource/authority/dataset-type/HVD

[init-dcat-ap-de]

In preparation of the next webinar we thought about the question, what we need for High Value Datasets.

Level 1

The absolute minimum would be a way to "tag" them. Some data portals literally use the dcat:keyword "HVD" for this, but with the dataset-type https://publications.europa.eu/resource/authority/dataset-type/HVD, we have a more elegant way using dct:type. This (or something compareable) should be standardardized for DCAT-AP.

Level 2

The next level would be the ability to precisely describe the type of HVD. We know, there is an existing taxonomy:

So what we need are URIs to adress the types of HVDs and an understandig, which property should be used for it.

    http://data.europa.eu/snb/hvd/statistics
    http://data.europa.eu/snb/hvd/statistics/population
    http://data.europa.eu/snb/hvd/statistics/national_accounts
    http://data.europa.eu/snb/hvd/statistics/...
    http://data.europa.eu/snb/hvd/earth_observation_and_evironment
    http://data.europa.eu/snb/hvd/earth_observation_and_evironment/land_cover
    http://data.europa.eu/snb/hvd/earth_observation_and_evironment/elevation
    http://data.europa.eu/snb/hvd/earth_observation_and_evironment/...
    ...

Useable properties would be

• dct:type (again)
• dcat:theme, maybe combined with dcat:themeTaxonomy
• dct:references, especially, if the used URIs link to a dummy-dataset
• something new, e.g. dcatap:hvdtype (sub-type of dct:type)

Level 3

Very useful would also the ability to describe the level of conformance. Most requirements are about the actual data, not so much the provided meta data. So simply changing/adding some mandatory properties would not be enough. This is where the Data Quality Vocabulary comes into play. It allows to define metrics and dimensions for quality measurements, as shown in example 6.1.

What we would need are harmonized and URI referencable dqv:Metric's and dvq:Dimensions's. e.g. like this:

dcatap-hvd:Geospatial-Granularity-includes_uniqueid 
    a dqv:Metric ;
    skos:definition "It checks the data includes an unique identifier."@en ;
    dqv:expectedDataType xsd:boolean ;
    dqv:inDimension dcatap-hvd:Geospatial-Key_attributes ;
.

dcatap-hvd:Geospatial-Key_attributes 
    a dqv:Dimension ;
    skos:prefLabel "Key attributes"@en ;
    skos:definition "Key attributes refers to the degree to which all 
        defined key attributes are present in a particular dataset."@en ;
.

Based on this image:

Of course, the dqv:Dimension could be more specific about the the metric and the (example) areas "Key attribute", "Granularity" or "Geographical coverage" could be modelled as categories.

[jakubklimek]

@init-dcat-ap-de I agree with L1 and L2. Regarding L3 - I see a problem in "provided by data provider or some instance that confirms HVD-conformity". If we leave it to the data provider to manually fill in with no verifiable evidence, they will fill it in in the way that gives them a ✅.

I would love it if these could be checked using a clearly defined and automated procedure. That would, however, imply having technical specifications for the HVD types, including specifications of APIs for accessing the data (ideally some kind of LOD-based API) so that these can be checked in every HVD automatically. Unfortunately, these we do not have, and I do not see the benefit in the manual approach since it can be cheated very easily when it is not possible to verify the claims automatically.

[init-dcat-ap-de]

@jakubklimek I see your point. I kept it flexible for two reasons: 1) Technically it's not easy to check wether or not a geospatial dataset contains sea-frontiers. And even if you can check it, it's unclear if the absents of sea-frontiers is in conflict with the quality metrics. 2) Politics. I would prefer to create a technical solution that does not have to take in account, who is allowed to rate member state contributions as good enough.

[miroslavliska]

Thanks for the comment @oystein-asnes . @sirex I would suggest using something like:

ex:dataset-001 a  dcat:Dataset ; 
    dct:type <http://publications.europa.eu/resource/authority/dataset-type/HVD>

Hopefully the new term will be added already in the December publication of OP Authority tables although it may not yet include the skos:prefLabel for all EU languages.

As for the thematical category, I don't think the data-theme List should be revised to include specific HVD categories. The List is for top level classification and adding more specific terms will disrupt its character. If, as suggested by @bertvannuffelen, a specific HDV Application Profile will be developed, the thematic categorisation could use a new HVD Thematic List to be published by the Publications Office. Another option could be to use the INSPIRE Theme or other vocabularies still.

We are using this approach already at our new SPARQL Endpoint for National Open Data Catalog. Try prepared query - List of HVD https://opendata.mirri.tech/en/

However, this is not enough as this should be rather inferred triple. I think there is already proposed a data property r5r:hvdCategory and it is used as follows:

:myDataset r5r:hdvCategory :category .

Then it can be inferred that :myDataset dcterms:type type:HVD .

However, I am not sure what the r5r prefix is, and what are the identifiers for categories.

source: https://github.com/SEMICeu/DCAT-AP/issues?q=is%3Aissue+is%3Aopen+label%3AHVD

[jakubklimek]

@bertvannuffelen The C1 proposal in the latest DCAT-AP HVD call suggests creating r5r:hvdCategory using a codelist just for the 6 top-level HVD categories. I would suggest that this codelist contains also the lower-level classification (dataset-level), as illustrated and suggested by @init-dcat-ap-de in https://github.com/SEMICeu/DCAT-AP/issues/231#issuecomment-1437116632, i.e. not only "Geospatial", but also "Geospatial - Urban audit", etc.

Otherwise, how will we find "Urban audit" HVD datasets in data.europa.eu?

Also I am not sure to which issue this comment actually belongs, as the issue mentioned in the call is #251 - but the suggestion was made here.

[bertvannuffelen]

@all this was the first issue raised on HVD. As this thread contains distinct discussions and proposals that have been discussed in the course of the 2 webinars and resulted in a candidate release for DCAT-AP HVD, I propose to consider this issue as finalized and to be closed.