Open jakubklimek opened 7 months ago
Posponed until the next webinar
For info, in Flanders we are mapping to a subproperty of dct:type
(related to #78 ):
Eigenschap | URI | GeoDCAT-AP | GeoDCAT-AP Vlaanderen |
---|---|---|---|
servicetype | http://data.vlaanderen.be/ns/metadata-dcat#servicetype | dct:type |
subproperty van dct:type |
servicecategorie | http://data.vlaanderen.be/ns/metadata-dcat#servicecategorie | dct:type |
subproperty van dct:type |
We had a discussion about this issue (Czech Office for Surveying, Mapping and Cadastre and Czech Environmental Information Agency) and we support the proposal - to create new subproperties of dct:type.
Problem statement
In GeoDCAT-AP 2.0.0
dct:type
on Data Service is used in three different contexts.This makes correct assignment of usage notes, labels and the required code lists rather difficult, as well as consequent validation e.g. via SHACL. The current approach is not in line with the profiling guidelines established in the context of the SEMIC Style Guide property reuse guideline Reuse of a property with terminological adaptations and Reuse of a property with semantic adaptations. Also, the approach becomes even more problematic in a cross-profile environment where incompatible requirements can be easily made.
Proposal
Introduce subproperties of
dct:type
geodcatap:serviceCategory
for "Classification of spatial data services" code listgeodcatap:serviceType
for "Spatial data service types" code listgeodcatap:resourceType
for "Resource types" code list with the domain ofdcat:Resource
to accomodate both for Datasets and Data ServicesThis approach is in line with the profiling guidelines established in the context of the SEMIC Style Guide property reuse guideline Reuse of a property with terminological adaptations and Reuse of a property with semantic adaptations. If interoperability is a concern, a data publisher can always easily materialize the subPropertyOf inference and replace the subproperties with
dct:type
.