opendata-swiss / dcat_ap_ch Goto Github PK

Property: all properties of DCAT-AP that are not included in DCAT-AP CH
Class: all classes of DCAT-AP that are not included in DCAT-AP CH
Conformance Problem: Data receivers(e.g. opendata.swiss) who have DCAT-AP-CH as a reference should still be able to pass through well formed DCAT-AP catalogues, even if some properties or classes are not directly defined in DCAT-AP CH. In particular, data exported toward data.europe.eu should match the import of a data provider who chooses to use further DCAT-AP classes or properties.
This issue has been discussed and clarified here: SEMICeu/DCAT-AP#198
Proposal:

• Data receivers' requirements (https://dcat-ap.ch/releases/2.0/dcat-ap-ch.html#provider-requirements) should be adapted and explained with an example.

Possible consequences on opendata.swiss:

• Check how opendata.swiss could fulfil this requirement consistently. One possibility could be for opendata.swiss to distinguish on import of a data catalogue between data, that is stored and further processed on its platform and the original data that should be kept and stored for export to the data.europe.eu. (see input from @metaodi below)

Par. 2.3 Multilingualism
First bullet point

Property: dct:publisher
Class: dcat:Catalog and dcat:Dataset
Conformance Problem: DCAT-AP 2.0.0 recommends a vocabulary for the publisher
Details: "The Corporate bodies NAL must be used for European institutions and a small set of international organisations. In case of other types of organisations, national, regional or local vocabularies should be used"
Proposal: A vocabulary has been proposed: https://www.dcat-ap.ch/vocabulary/publishers/20210623.html: the entries for it have been extracted via a tool from the names entered in dct:publisher on https://ckan.opendata.swiss

Property:dcat:theme
Class: dcat:Dataset
Conformance Problem:

• The DCAT-AP makes the use of EU category vocabulary mandatory
• custom Swiss categories must also be turned into a skos:CoceptScheme (controlled vocabulary)

Details: The EU vocabulary to use is this: http://publications.europa.eu/resource/authority/data-theme

Proposal:

• change the range to make EU categories manadatory
• use https://dcat-ap.ch/vocabulary/themes as controlled vocabulary for the Swiss categories

Property: dcat:landingPage
Class: dcat:Dataset
Implementation Problem:The implementation on opendata.swiss does not conform this DCAT since dcat:landingPage is implemented as an rdfs:Literal instead of a foaf:Document
Details: .Implemented:dcat:landingPage: "https://swisstopo/index", DCAT-AP CH conformant: dcat:landingPage:<https://swisstopo/index>
Proposal:Change the implementation on opendata.swiss so that it conforms to DCAT-AP-CH

Properties: dct:modified
Classes: Dataset, Distribution
Ist: The actual guidance about when should a new value for dct:modified should be set is insufficient. https://dcat-ap.ch/releases/2.0/dcat-ap-ch.html#dataset-modification-date
Soll: The eCH-Working Group defines clearer criteria which defines which actions should be counted as a change to the dataset or to the resource.

Property: dcat:format
Class: dcat:Distribution
Conformance Problem: DCAT-AP differs in the requirement level of this property: it is recommended wheras dcat:mediaType is optional
Proposal: Adapt the usage note and change the requirement level to recommend

Property: rdfs:seeAlso
Class: dcat:Dataset
Conformance Problem: rdfs:seeAlso is a custom Swiss property to express relationships between datasets. DCAT already includes properties for this purpose, however. DCAT gives the choice between dct:relation and dcat:qualifiedRelation. In order to conform to DCAT, one of those properties MUST be used instead.
Proposal: Abondon the property and use DCAT vocabulary dct:relation or dcat:Relationship instead.

Property: dct:publisher
Class: dcat:Dataset
Conformance Problem: Currently DCAT-AP-CH allows more than one publisher per dataset, but DCAT-AP 2.0.0 allows only one publisher
Proposal: change the cardinality so that it conforms to DCAT-AP

In the German DCAT-AP 2.0 standard the attribute dct:references is used to link to their "Musterdatenkatalog", a catalog of reference datasets. The goal is to provide a way to find similar datasets across different portals.

E.g. "Baumkataster" has the following reference dataset: https://musterdatenkatalog.de/def/musterdatensatz/gruenflaechen/baumbestandBaumkataster

If this property is adapted, we need to make a note about its implementation. We could either create a new Swiss-specific "Musterdatenkatalog" or use https://musterdatenkatalog.de of Bertelsmann.

Links

• And then this (and similar dataset can be found using this URI: https://opendata.schleswig-holstein.de/dataset?reference=https://musterdatenkatalog.de/def/musterdatensatz/gruenflaechen/baumbestandBaumkataster
• See example SPARQL for Germany

Description

• Description of dct:reference in the German specification: https://www.dcat-ap.de/def/dcatde/2.0/spec/#datensatz-referenziert
• Notes about its use in the convention handbook: https://www.dcat-ap.de/def/dcatde/2.0/implRules/#verweis-auf-referenzobjekte

Property: dct:mediaType
Class: dcat:Distribution
Conformance Problem: The media type must use IANA media types as a controlled vocabulary. Media types should be provided as URIs.
Details:

• DCAT-AP CH Version 1 did not specify how the IANA media types should be given:It should stated "Der Wert des Elements "dcat:mediaType" muss einem MIME Type gemäss IANA entsprechen:
  http://www.iana.org/assignments/media-types/media-types.xhtml".
• Since there were no examples this has been misunderstood when implementing it on opendata.swiss

Proposal:

• Adapt the usage note of the property in DCAT AP CH to explicitly demand that the IANA Media Type should be provided as an URI.
• Correct the implementation on opendata.swiss.

Property:dcat:byteSize
Class:dcat:Distribution
Implementation:as Intenger dcat:bytSize: 1234
Conformance to DCAT-AP-CH: dct:byteSize is demanded as rdfs:Literal typed as xsd:decimal in both DCAT-AP CH and DCAT-AP. So the example should be implemented as dcat:bytSize: "1234"^xsd:decimal
Conformance to DCAT-AP: DCAT-AP-CH conforms to DCAT-AP in this regard
Proposal: Change the implementation on opendata.swiss

Property: dct:rights
Class: dcat:Distribution, dcat:Catalog
Conformance Problem: The property is described and implemented incorrectly. It is not meant to replace dct:license but to add an information on the legal framework and thus complement dct:license
Details: See here https://theodi.org/article/publishers-guide-to-the-open-data-rights-statement-vocabulary/ for how to use dct:rights.
Proposal: Refactor defintion of dct:rights and adapt to DCAT-AP by making dct:rights recommended and dct:license mandatory

Properties: dcat:downloadURL

Classes: Distribution

Ist: In DCAT-AP-CH v1 the defined cardinality is "1", whereas in DCAT-AP it's "n"

Soll: Adapt to DCAT-AP and define cardinality as "n" in DCAT-AP-CH v2. Check possible implementation issues on opendata.swiss

Report on the SEMIC Webinar on Identifiers (17.3.2022)

About: SEMIC invited the European national portals to a webinar about the future use of identifiers in DCAT-AP: "DCAT-AP webinar on identifiers"

There had several proposals. We could vote at the beginning for between 2 meaning of identifiers:

• identifiers are meant to identify within catalogs
• identifiers are provided by the publishers of the datasets and are meant to identify the source of the dataset

The second option was adopted since 90% of the participants voted for that option

After that several Proposals were presented:

Proposal 1: DCAT-AP recommends that all datasets have exactly one dct:identifier

-> We already have that dct:identifier as 1:n on the dataset class: so maybe we should change that to 1:1

Proposal 2: The identifier should come with its own metadata: since dct:identifier is a literal, it can't by itself connect to the original datasource. Therefore it is recommended to add a adms:identifier so that the dct: identifier can be set into context:

dct:identifier "dek-gs-3@kanton-thurgau";
adms:identifier [
  skos:notation "dek-gs-3@kanton-thurgau" ;
  dct:creator <https://opendata.swiss/organization/kanton-thurgau> ; ] ;

there can be more adms:identifier, but at least one of those should further describe dct:identifier

-> we don't have adms:identifier on the dataset class yet, so we should consider to add this.

Proposal 3: The dct:identifier should be the IRI of the dataset:

<https://data.tg.ch/catalog/datasets/dek-av-23> a dcat:Dataset ;   
  dct:identifier "https://data.tg.ch/catalog/datasets/dek-av-23";
  adms:idetifier [
    skos:notation "https://data.tg.ch/catalog/datasets/dek-av-23";
    dct:creator <https://opendata.swiss/organization/kanton-thurgau>

-> We should consider to add this to the usage note, but it seems difficult to implement this: currently many Swiss datasets don't have a URI and if the have one, it is not the dct:identifier of the dataset.

There was a fourth proposal, but that one was not very well received by the community. The idea was that harvesters should also add an adms:identifier
with dct:creator the dataportal that did the harvesting.
I have especially asked for guidance on how to implement Proposal 3 and someone else asked for that as well.
There will be a next Webinar on the topic. And I will mention it here, so that eCH Fachgruppen memeber, that are interested to attend will be able to ask SEMIC for an invitation.

Property: DCAT-AP properties that are not specified in DCAT-AP CH
Class: DCAT-AP classes that are not specified in DCAT-AP CH
Conformance Problem: Currently all mandatory and recommended classes and properties from DCAT-AP are defined in DCAT-AP-CH. Portal managers (“data receivers”) and data publishers (“data providers”) need guidance on what it means for them if a class or property is specified in DCAT-AP but not in DCAT-AP CH: can they use it, will the data portal support it?
Proposal:

• Include all mandatory and recommended classes and properties of DCAT-AP in DCAT-AP CH and state that in the conformance note: https://www.dcat-ap.ch/releases/2.0/dcat-ap-ch.html#provider-requirements. This way can data providers (e.g. federal offices, cantons, cities,…) be certain that if they use DCAT-AP CH as only reference they will still have valid data catalogues
• Explain with a note that more classes and properties of DCAT-AP (optional classes) can be added to data catalogues and that data receivers (i.e. opendata.swiss) will have to pass them through (for instance to data.europa.eu) as well formed DCAT-AP catalogues, even if some properties or classe are directly defined in DCAT-AP CH (see #119)

Possible consequences on opendata.swiss

• Check integration of new classes/properties
• Data receiver which use DCAT-AP-CH as a reference should still be able to pass through well formed DCAT-AP catalogues, see #119

Property: schema:image
Class: dcat:Dataset, dcat:Distribution
Conformance Problem: schema:Image is a custom Swiss property to include thumbnails for datasets and distributions. In DCAT there is a discussion about this topic: w3c/dxwg#1357. In order to stay aligned with DCAT this discussion has to be followed. In case DCAT adds similar vocabulary, it might be necessary to switch to the DCAT vocabulary in the future.
Proposal: Follow the discussion on DCAT development regarding adding a thumbnail property

Class: dcat:Distribution
Conformance Problem:

• In DCAT a distribution (https://www.w3.org/TR/vocab-dcat-3/#Class:Distribution) is defined as "A specific representation of a dataset. A dataset might be available in multiple serializations that may differ in various ways, including natural language, media-type or format, schematic organization, temporal and spatial resolution, level of detail or profiles (which might specify any or all of the above). " and in the Note below it is mentioned:
  "As a counter-example, budget data for different years would usually be modelled as different datasets, each with their own distributions, since all distributions of one dataset should broadly contain the same data. ", see [DCAT Class:Distribution]
• In contrast to this the current DCAT-AP CH explicitly encourages the usage of distributions to model a dataseries, see here: https://www.dcat-ap.ch/releases/2.0/dcat-ap-ch.html#Class:Distribution
• But it is also stated (https://www.w3.org/TR/vocab-dcat-3/#Class:Distribution) "Nevertheless, the question of whether different representations can be understood to be distributions of the same dataset, or distributions of different datasets, is application specific. Judgement about how to describe them is the responsibility of the provider, taking into account their understanding of the expectations of users, and practices in the relevant community. "

Details:

• In a discussion with DCAT-AP about how the Swiss property dct:coverage on dcat:Distribution can be expressed with DCAT-Vocabulary, see here: SEMICeu/DCAT-AP#197 we were told that modeling dataseries with distributions of a dataset is considered an antipattern and the reference above was mentioned in that regard.
• In DCAT Version 3 dcat:DataSeries (https://www.w3.org/TR/vocab-dcat-3/#Class:Dataset_Series) will be added, that might be the best way to model dataseries
• Properties for distributions on the other hand include also in DCAT Version 3 only resolution but not any sort of content coverage (https://www.w3.org/TR/vocab-dcat-3/#Property:distribution_spatial_resolution, https://www.w3.org/TR/vocab-dcat-3/#Property:distribution_temporal_resolution)
• Distributions are expressed with an RDF graph, that is unordered. Therefore it is not the best fit to model a Dataseries, that usually does have an order,
• This issue is related to #79

Proposal:

• Follow DCAT Version 3 and DCAT-AP
• Revise the usage note on dcat:Disttribution to not encourage the modeling of a Dataseries with Distributions
• As soon as the dcat:DataSeries is available in DCAT-AP it should be added it to DCAT-AP CH
• For opendata.swiss there should be a gradual phase out of the usage of Distributions to model dataseries, that is supported by documentation on how else this can be done

Property: dct:issued
Class: dcat:Dataset
Implementation: visiblity of datasets with dct:issued in the future
Conformance to DCAT-AP CH: not conformant to DCAT-AP CH since the usage note on dct:issued says, that datasets with a future relase date should not be published
Details: Currently it is possible to set a datasets visibilty to published regardless of whether the release date of that dateset is in the future or not.
Proposal: Correct implementation on opendata swiss: a dataset's visibility should not be published if the release date is in the future.

Property: dct:accrualPeriodicty
Class: dcat:Dataset
Conformance Problem: DCAT-AP demands the use of the EU vocabulary as a MUST
Details: EU vocabulary: http://publications.europa.eu/resource/authority/frequency
Proposal: restrict the range to the usage of the EU vocabulary and change the implementation on opendata.swiss

Property: dct:coverage
Class:dcat:Dataset
Conformance Problem:

• on dcat:Dataset this Swiss custom property is violating the principle that custom properties should not replace available DCAT properties. In this case the DCAT properties dct:spatial and dct:temporal are able to completely replace dct:coverage on dct:Dataset.

Proposal:

• Remove dct:coverage as property of dcat: Dataset

Property: dct:publisher
Class: dcat:Catalog and dcat:Dataset
Conformance Problem: Contradiction in the Definition
Details: Example models this with rdfs:Descripton, but Range says foaf:Agent
Proposal: remove the contradicting example and correct implementation on opendata.swiss

Property: dct:license
Class: dcat:Distribution
Conformance Problem: Currently in DCAT-AP CH dct:license is optional on dcat:Distribtuion. This does not conform to DCAT-AP where it is recommend.
Details:

1. In DCAT-AP "recommended" means "a sender SHOULD provide the information for that property if it is available" (DCAT-AP Version2.0.0, Section 2 "Terminology used in the DCAT Application Profile", see https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/dcat-application-profile-data-portals-europe/distribution/dcat-ap-200-pdf)
2. Also for datausers the data is not of value without usage conditions. And dct:rights cannot replace dct:license but just complement it, see #110

Proposal:
There are two proposals:

• because of 1. and 2. above dct:license should not only be recommended but mandatory on dcat:Distribution.
• Since usage conditions are so important, a controlled vocabulary for the licenses is proposed: https://www.dcat- ap.ch/vocabulary/licenses. This vocabulary will help dataproviders to enter the licenses correctly and it will help data portals to validate the provided licenses. The vocabulary follows the German approach, see http://dcat-ap.de/def/licenses,

Property: dct:spatial
Class: dcat:Dataset
Conformance Problem: The requirement level of this property in DCAT-AP CH is "optional" which is weaker than the requirement level in DCAT-AP where it is "recommended".
Details: When overwriting the requirements of a property, DCAT-AP CH must make sure that if metadata conforms to these changed requirements, it will also conform to the original requirements of DCAT-AP. This means in practice that the requirements in DCAT-AP CH may become stricter, but not less strict.
Proposal: Change the requirement level to "recommended"

Property:dct:issued, dct:modified
Class: dcat:Dataset, dcat:Distribution
Implementation: implemented as xsd:datetime
Conformance to DCAT-AP-CH: not conformant with DCAT-AP-CH that demands this to be xsd:date
Conformance to DCAT-AP: conformant witb DCAT-AP that gives the choice of either xsd:date or xsd:datetime
Details: dct:issued and dct:modified are demanded as rdfs:Literal typed as xsd:date in DCAT-AP CH, but implemented as rdfs:Literal typed as xsd:datetime on opendata.swiss. This implementation does not conform to DCAT-AP CH, but it does conform to DCAT-AP. Therefore it would be an option to adapt the definition of those properties to the DCAT-AP specification in order to solve this non-conformance of opendata.swiss to DCAT-AP CH.
Proposal: change DCAT-AP-CH and allow also for xsd:datetime

Property: dct:availability
Class: dcat:Dataset
Implementation: To be discussed, but to make it clear that it is not a guaranteed sevice, implemented as a CV with a list of brought Availability measures tbd, (e.g. shortTerm (1 year), midTerm (5 years), longTerm (10 years)).

Conformance: For real world applications it is important to quickly understand how long a dataset will stay available to quickly decide if it can be used in a (data-) project. The goal is to provide a data provider statement regard the long-term availability of the provided dataset. This should be made conform to the efforts on the DCAT-AP level, see below.

Property: multiple properties, for example title, description...
Class: -
Ist: DCAT-AP CH does not provide any guidance regarding which language are a must and which not. It just enables multilingualism.
Soll: To increase to usability of data and provide clearer guidance for data publisher at every level it should be clearly stated which language are a must. It can also be diferntiated for different federal levels. For instance: "DE and FR obligatory only for the federal level."

Property: all properties of dcat:Catalog except dcat:dataset
Class: dcat:Catalog
Implementation: There is no import of the catalog class into opendata.swiss
Conformance to DCAT-AP-CH: Metadata for dcat:Catalog is currently not imported to opendata.swiss and also not exported from opendata.swiss. Since there are mandatory properties on the catalog class, this hurts DCAT-AP conformance as well
as DCAT-AP CH conformance.
Proposal:opendata.swiss should implement a catalog class and consider to preserve the structure of the imported data catalogs so that this structure is available on export.

Since usage conditions (Nutzungsbedingungen, Lizenzen) are so important, we will propose a controlled vocabulary for dct:license. Important inspiration sources may be http://dcat-ap.de/def/licenses and Chapter 5.4 "Licence vocabularies" from DCAT-AP.

A first draft was elaborated:
https://www.dcat-ap.ch/vocabulary/licenses

Business rules, like for instance "actors of the federal level should only use terms of use", can be defined where needed.

Property: dct:language
Class: dcat:Catalog, dcat:Dataset, dcat:DIstribution
Conformance Problem: DCAT-AP 2.0.0 demands the use of the EU vocabulary for the language, while DCAT-AP-CH demands the ISO 2 letter code
Details: This is the EU vocabulary for the language: https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/language
Proposal: Switch to European Language vocabulary

Property: dct:rights, dct:license, dct:format, dcat:mediaType, dct:issued, dct:modified, dcat:landingPage, dcat:byteSize,
Class: dcat:Catalog, dcat:Dataset, dcat:Distribution
Conformance Problem: DCAT-AP CH uses the requirement level "conditional" for specifying the requirements of its classes and properties instead of the requirement level "recommended" that is used and also defined by DCAT-AP. While this may not be an obstacle regarding conformance to DCAT-AP, it makes it harder to compare the requirement levels. Since DCAT-AP CH does not give a definition of "conditional", the reason for that deviation from DCAT-AP terminology remains unclear.
Proposal: Drop support of conditional and replace it with DCAT-AP's "recommended".

Property:dct:identifier
Class:dcat:Dataset
Conformance Problem: The current definition of this property in DCAT-AP CH is very application dependent: it states how the field content should also be used in rdfs:seeAlso and what the application should do to keep the data portal consistent. The Application profile DCAT-AP CH should not include details on how to implement this in a specific data portal (e.g. opendata.swiss), it should focus on providing guidance to Swiss data portals and catalogues.
Proposal: Align to the dcat-ap recomendations. See here: https://joinup.ec.europa.eu/release/dcat-ap-how-use-identifiers-datasets-and-distributions.

Property: dcat:format
Class: dcat:Distribution
Conformance Problem: DCAT-AP makes the use of the EU file type vocabulary mandatory for this property
Details: EU-filetype vocabulary url: http://publications.europa.eu/resource/authority/file-type. It is encouraged to contribute additional file types. A discussion has been started on the file types we currently use on opendata.swiss with [email protected]. There is a plan to enhance their file type vocabulary and to discuss further with the stakeholders about their needs regarding file types
Proposal: Adapt definition and stay in discussion with [email protected].

Property:dct:language
Class:dcat:Catalog
Conformance Problem:dct:language has the requirement level "recommended" in DCAT-AP. In DCAT-AP-CH it is only "optional"
Proposal: upgrade requirement level

To my knowledge there is currently no way to describe attributes of a dataset (e.g. columns of a CSV). This would include the following information (minimal):

• name of the attribute
• description of the attribute
• datatype/allowed values of the attribute

On http://data.stadt-zuerich.ch we provide this information on a dataset level (i.e. it does not differ between distributions).

Example: Daten der Verkehrszählung zum motorisierten Individualverkehr (Stundenwerte), seit 2012

Property: dct:format
Class: dcat:Distribution
Implementation: implemented as an rdfs:Literal, Example dct:format:"CSV"
Conformance: this does not conform to DCAT-AP where a controlled vocabulary should be used: http://publications.europa.eu/resource/authority/filetype
Proposal: wait for DCAT-AP CH to resolve this and then implement it on opendata.swiss

Property: dct:coverage
Class:dcat:Dataset and dcat:Distribtution
Conformance Problem:

• on dcat:Distribution there is no DCAT property to replace dct:coverage. But this is because Distribution properties all relate to resolution, format, size, language, etc. that is to properties that refer to the same content in different physical representations. On opendata.swiss dct:coverage is used to model dataseries as distributions of a dataset. But this considered bad practice in DCAT-AP, see #112

Proposal:

• Gradually phase out dct:coverage on dcat:Distribution and encourage the use of dcat:DataSeries (https://www.w3.org/TR/vocab-dcat-3/#Class:Dataset_Series) as soon as it is ready to be added to DCAT-AP CH. This has to be done in correspondence with #112

Changed Proposal: Watch what happens on DCAT-AP and DCAT regarding the modeling on Series of Data, since this seems to be a topic where there is some movement in the DCAT community.

Please be aware of the following used and automatically created Controlled Vocabularies:

Organisations: https://register.ld.admin.ch/opendataswiss/org
Category: https://register.ld.admin.ch/opendataswiss/category
Licences: https://ld.admin.ch/vocabulary/TermsOfUse

They were created and used because of the lack of any missing list so far.

Please make sure that the CV are accessible through dereferencing in the final version.

See http://dcat-ap.ch/vocabulary/licenses/terms_by, vs. https://ld.admin.ch/vocabulary/TermsOfUse/Provide-the-Source while using the Content Header: Accept: text/turtle

Property:dct:spatial
Class:dcat:Dataset
Conformance Problem

• in DCAT-AP locations names must be provided as URIs and if possible controlled vocabularies should be used. the usage note does not make that clear
• the remark on polygons is outdated

Proposal:

• improve usage note and demand the use of controlled vocabularies
• employ controlled vocabularies about Swiss locations
• add example for points, bounding boxes and polygons

Property: 'dct:issued'
Class: ´dcat:Dataset'
Implementation: in the implementation on opendata.swiss a dataset can be set to published despite the fact that the release date is in the future.
Conformance: This is not conformant to DCAT-AP CH since the usage note on dct:issued says: "In a data portal, the dataset will only be publicly displayed if it has an issued date and if that date is not in the future."
Proposal:

• Remove this statement above from the usage note since DCAT-AP CH is a standard to describe metadata and no guidebook on when or how to publish that metadata.The decision on when to publish the dataset should be left to the data portal.

Property: dcat:keyword, dcat:theme, dct:spatial, dct:temporal
Class: dcat:Dataset
Conformance Problem: these properties are optional in DCAT-AP CH but recommended in DCAT-AP
Proposal: make them recommended in DCAT-AP CH

Property: -
Class: dcat:Dataservice
Implementation: Actually is dcat:Dataservice not a part of DCAT-AP CH. This class is becoming increasingly fundamental to reference correctly elements such as SPARQL Endpoints, REST-API, WFS services… Few other countries have already introduced this class. https://docs.dataportal.se/dcat/en/#dcat%3ADataService, https://data.norge.no
Conformance: dcat:DataService is an optional class of DCAT-AP 2.0.1
Proposal: Introducing the class dcat:Dataservice with following properties:

Vorschlag dctDataService.xlsx

Property:dcat: themeTaxonomy
Class:dcat:Catalog
Conformance Problem:dct:themeTaxonomy has the requirement level "recommended" in DCAT-AP. In DCAT-AP-CH it is only "optional"
Proposal: raise requirement level

Property: dct:availability
Class: dcat:Dataset
Implementation: implemented as a CV with a list tbd, (e.g. Testing, Draft, Published).

Conformance: For real world applications it is important to quickly understand at which maturity level dataset is published to quickly decide if it can be used in a (data-) project. The goal is to provide a data provider statement regard the maturity of the provided dataset. With the goal to also allow to quickly distribute testing and draft dataset for early feedback and to allow an overall agile data modelling process. This is a non-normative extension to the current DCAT.