Dear @andrea-perego and team,

we found the GeoDCAT-AP in this repository and enjoyed it.

As we are also developing a DCAT-AP (called napDCAT-AP) for our project NAPCORE on National Access Points, we have a technical question to you: Did you manually create the index.html file for the ReSpec documentation page or did you use any automation? In case of the latter, it would be great if you share these automation scripts with us so that we can build on these.

Thank you so much in advance! Best,
Johannes

Some comments concerning some properties added in GeoDCAT-AP but not included in DCAT-AP.

• Section 4.1.3 Optional properties for Catalogue: some properties added correspond to metadata elements not required for discovery services (and in general for network services) in INSPIRE TG, consequently no need to add them in GeoDCAT-AP. Those properties are: +reference system, +topic category (also in ISO 19115 this metadata element is included in the class MD_DataIdentification) and +theme/category (as INSPIRE theme is not required for the services);

• Section 4.2.3 Optional properties for Catalogue Record: as Catalogue Record is used to map INSPIRE metadata elements on metadata, only +character encoding, +contact point and +identifier should be added. No need to add +publisher, +creation date, +creator, +qualified attribution and +rights holder;

• Section 4.3.3 Optional properties for Data Service: for the same reasons above, the properties +topic category and +theme/category shouldn't be added for Data Service;

• Section 4.3.3 Optional properties for Data Service: in ISO 19115 spatial resolution is a specific metadata element only for dataset. In INSPIRE TG the requirement is indeed that for services the spatial resolution shall be expressed using the gmd:abstract element. For this reason, the properties +spatial resolution and +spatial resolution as equivalent scale, angular distance, vertical distance shouldn't be added;

• Section 4.3.3 Optional properties for Data Service: in ISO 19115 language is a specific metadata element only for dataset as well, consequently the property +language shouldn't be added;

• Section 4.7.2 Optional properties for Category Scheme: generally the publication date of the vocabulary/thesaurus is required in INSPIRE TG. In a similar way, only the property +release date could be added;

• Section 5.2 Controlled vocabularies to be used: update the table according to what above if the proposals will be accepted.

Problem statement

Following DCAT 3, DCAT-AP 3 introduces properties specific to datasets in a dataset series, namely, dcat:inSeries, dcat:next, and dcat:prev (see the DCAT-AP 3 specification, §7.8).
d).

Proposal

To be aligned with DCAT-AP 3 and DCAT 3, GeoDCAT-AP 3 should include properties dcat:inSeries, dcat:next, and dcat:prev .

Is there any alignment of GeoDCAT-AP and DCAT-AP 2.0.0 planned at the moment? Specifically regarding the representation of services in DCAT-AP 2.0.0, which could be utilized in the context of GeoDCAT-AP. (#10)

INSPIRE TG Requirement C.17 states that limitations on public access (or lack of such limitations) shall be described using a combination of one instance of gmd:accessConstraints/gmd:MD_RestrictionCode element with code list value "otherRestrictions" and at least one instance of gmd:otherConstraints/gmx:Anchor pointing to one of the values from the code list for LimitationsOnPublicAccess.
The first part of the example (i.e. Resource metadata in ISO 19139) provided in the section B.6.15 Conditions for access and use and limitations on public access – Use limitation and access / other constraints is not consistent with the requirement mentioned above, as free text is not allowed for describing the limitations on public access. Consequently, the example should be revised as follows:

Resource metadata in ISO 19139:

<gmd:MD_Metadata>
  ...
  <gmd:MD_LegalConstraints>
    <gmd:useConstraints>
      <gmd:MD_RestrictionCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_RestrictionCode" codeListValue="otherRestrictions"/>
    </gmd:useConstraints>
    <gmd:otherConstraints>
      <gco:CharacterString>
        The dataset contains parts which are restricted 
        by the data providers and not to be made public. 
        For further information and specification regarding 
        the use limitations and constraints please consult 
        the file WISE_WFD_ReferenceSpatialDataSets_2020-04-02.pdf 
        which is provided together with the data.    
      </gco:CharacterString>
    </gmd:otherConstraints>
  </gmd:MD_LegalConstraints>
  ...
  <gmd:MD_LegalConstraints>
    <gmd:accessConstraints>
      <gmd:MD_RestrictionCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_RestrictionCode" codeListValue="otherRestrictions"/>
    </gmd:accessConstraints>
    <gmd:otherConstraints>
<gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1b">public access limited according to Article 13(1)(b) of the INSPIRE Directive</gmx:Anchor>
    </gmd:otherConstraints>
  </gmd:MD_LegalConstraints>
  ...
</gmd:MD_Metadata>

and consequently

Resource metadata in GeoDCAT-AP:

[] dcat:distribution [ a dcat:Distribution ;
  dct:license [ a dct:LicenseDocument ;
    rdfs:label """
        The dataset contains parts which are restricted 
        by the data providers and not to be made public. 
        For further information and specification regarding 
        the use limitations and constraints please consult 
        the file WISE_WFD_ReferenceSpatialDataSets_2020-04-02.pdf 
        which is provided together with the data.    
      """@en ] ;
  dct:accessRights <http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1b> ; 
] .

This code list has not yet been added to the INSPIRE Registry.

To be decided if any action should be taken.

Problem statement

In GeoDCAT-AP 2.0.0 dct:type on Data Service is used in three different contexts.

1. service category with "Classification of spatial data services" code list
2. service type with "Spatial data service types" code list
3. type with "Resource types" code list. (this one also appears in Dataset)

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

1. geodcatap:serviceCategory for "Classification of spatial data services" code list
2. geodcatap:serviceType for "Spatial data service types" code list
3. geodcatap:resourceType for "Resource types" code list with the domain of dcat:Resource to accomodate both for Datasets and Data Services

This 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.

ℹ️ Following discussion in #30 . See also #16 and §7 (Agent roles) for background information.

The purpose of this proposal is to provide a simple way to specify all the ISO 19115 responsible party roles used in INSPIRE, as an alternative to the use of the approach based on the W3C PROV Ontology (prov:qualifiedAttribution).

The properties to be defined should be limited to those not supported in Dublin Core and DCAT, as shown in the relevant mapping table of the GeoDCAT-AP specification - namely:

• Custodian
• Distributor
• Originator
• Principal investigator
• Processor
• Resource provider
• User

Problem statement

Following DCAT 3. DCAT-AP 3 introduces a new class dcat:DatasetSeries.

This class corresponds to the ISO 19115 / INSPIRE notion of "data set series":

https://inspire.ec.europa.eu/glossary/DataSetSeries

Until GeoDCAT-AP 2, dataset series were typed (rdf:type) as dcat:Dataset's.

For more details, see the GeoDCAT-AP 2 specification (in particular, §B.6.3).

Proposal

To be aligned with DCAT-AP 3 and DCAT 3, GeoDCAT-AP 3 should deprecate the use of class dcat:Dataset for dataset series, and replace it with class dcat:DatasetSeries.

To be decided if semantic relationships between the agent roles defined in GeoDCAT-AP and DCTERMS should be made explicit.

ℹ️ Copy-pasted from SEMICeu/Core-Location-Vocabulary#2

GeoDCAT-AP currently models spatial / temporal resolution as free text (with rdfs:comment), recognising that, at the time when the GeoDCAT-AP specification was released, no existing vocabularies provided a means to model this information.

However, this requirement has been brought to the attention of the W3C Data on Web Working Group, and a solution has been documented in the W3C Data Quality Vocabulary (DQV), as reported here:

https://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2016-May/000367.html

Basically, DQV models this information as observations / measurements of a given quality metric (which corresponds to a given type of resolution).

This solution was also included by the SDW Working Group in their best practices, and it could be readily adopted in LOCN.

This would however require the definition of two groups of individuals:

1. Those corresponding to the different types of resolution (denoting a quality metric).
2. Those corresponding to each of the different levels of resolution (denoting the measurement of a specific quality metric).

As far as the first group is concerned (i.e., the different types of resolution), these individuals can be defined in DQV as follows:

:SpatialResolutionAsEquivalentScale a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as equivalent scale,
	  by using a representative fraction (e.g., 1:1,000, 1:1,000,000)."@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .
    
:SpatialResolutionAsDistance a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as distance"@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .

This initial list can be further extended. E.g.:

:SpatialResolutionAsHorizontalGroundDistance a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as horizontal ground distance"@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .
    
:SpatialResolutionAsVerticalDistance a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as vertical distance"@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .
    
:SpatialResolutionAsAngularDistance a dqv:Metric;
  skos:definition "Spatial resolution of a dataset expressed as angular distance"@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension dqv:precision .    

The question is in which space such individuals should be defined (inside LOCN? in a separate code list - as the ones maintained by the EU Publications Office?).

The definition of individuals in the second group is however more problematic, since the level of resolution and unit of measurement are arbitrary (1:1000, 1:100, 1m, 1km, 100m, 10 decimal degrees, etc.).

Possible options include the following ones:

1. Define only the individuals corresponding to the types of spatial / temporal resolution, whereas the individuals expressing the actual resolution will be defined at the data level. This solution is not optimal, since it will result in multiple definitions of the same individuals.
2. Define individuals only for some levels of resolution and units of measurements - e.g., the most common ones. This solution may address the majority of (but not all) the cases.
3. Set up a URI space supporting arbitrary levels of resolution and units of measurements. This register will dynamically generate the corresponding individuals based on information included in their URI.

An example of the last option, including also a proposal for how these individuals could be defined, is available at:

http://geodcat-ap.semic.eu/id/resolution/

This issue serves the purpose of collecting usage evidence of the following GeoDCAT-AP supporting tools:

• GeoDCAT-AP XSLT
• GeoDCAT-AP API
• CSW-4 Web
• EPSG-XSLT
• GeoIRI
• Measurement Resolution

If you use any of these tools, or if you definitely consider using them, please let us know about the context, in which you use/plan to use them.

In the introductory webinar to the revision of GeoDCAT-AP (2024-02-20) there was a poll on this topic, and the results indicated so far that only the GeoDCAT-AP XSLT is actually being used by the community. This is why we would like to take this opportunity to collect additional usage evidence of the tools.

ℹ️ The possibility of addressing this issue in the scope of the Core Location Vocabulary is discussed in SEMICeu/Core-Location-Vocabulary#2 , from which the following issue description is taken.

For this purpose, GeoDCAT-AP v1.0 uses property dct:conformsTo.

Since dct:conformsTo is a very general property, the fact that the object is a spatial / temporal reference system is currently addressed by using dct:type with the relevant code list values from the INSPIRE Glossary, as shown in the following example:

a:Dataset a dcat:Dataset ;
  dct:conformsTo a:SpatialReferenceSystem .
  
a:SpatialReferenceSystem a dct:Standard ;
  dct:type <http://inspire.ec.europa.eu/glossary/SpatialReferenceSystem> .

Moreover, an experimental RDF representation of reference system from the OGC CRS Register has been developed, mapping additional information (as the "name" of the CRS).

It might be desirable to have a more specific property than dct:conformsTo and/or use a stronger typing rather than using dct:type with a term from the INSPIRE Glossary.

In such a case, an initial proposal for the definition of specific classes / properties is documented here:

https://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2015-July/000157.html

⚠️ The Git repository including the the mapping proposal referred to from the mail above has been moved to GitHub: https://github.com/SEMICeu/epsg-to-rdf

Moreover, the new version of the W3C Time Ontology includes a class time:TRS that could be used to type temporal reference systems.

GeoDCAT-AP makes use of qualified relations from [PROV-O] to specify responsible party roles, as an alternative to the use of specific properties (e.g., dct:publisher, dcat:contactPoint).

This approach was contributed to the W3C DXWG (see Use Case 13 in DCAT-UCR), and it has been re-used and refined in DCAT 2 as one of possible ways for specifying relationships between agents and resources in a catalogue (see §13.1 Relationships between datasets and agents and Example 41). In particular, DCAT 2 defines a new property dcat:hadRole to specify the agent role, whereas GeoDCAT-AP makes use of property dct:type for the same purpose.

Property dcat:hadRole has been adopted by DCAT-AP 2 (see SEMICeu/DCAT-AP#81), and therefore GeoDCAT-AP should be updated accordingly, possibly taking into account backward interoperability (e.g., by marking dct:type as deprecated).

The controlled vocabularies listed in §5.3 are the ones included in the first version of GeoDCAT-AP.

It is to be decided if any revision is needed.

ℹ️ Following from background discussion in #3

DCAT-AP 2 includes two properties from DCAT 2 to specify spatial and temporal resolution:

• dcat:spatialResolutionInMeters
• dcat:temporalResolution

They will therefore be eventually inherited by the future version of GeoDCAT-AP - ideally, taking into account backward compatibility.

It is worth noting, however, that dcat:spatialResolutionInMeters cannot express spatial resolution as equivalent scale, so an option would be defining a specific property in the GeoDCAT-AP namespace.

Based on the DCAT 2 approach, this property could be named

geodcatap:spatialResolutionAsEquivalentScale

or, shortly:

geodcatap:spatialResolutionAsScale

and take as value an xsd:decimal expressing the fraction. E.g.:

a:Dataset a dcat:Dataset ;
  geodcatap:spatialResolutionAsScale "0.001"^^xsd:decimal ;
.

would state that the spatial resolution of the dataset in equivalent scale is 1:1,000.

This solution can also be extended to other types of spatial resolution:

• geodcatap:spatialResolutionAsAngularDistance or, shortly, geodcatap:spatialResolutionInDegrees
• geodcatap:spatialResolutionAsVerticalDistanceInMeters (yes, that's terribly long)

The corresponding tentative definitions:

geodcatap:spatialResolutionAsScale a rdf:Property ;
  rdfs:label "spatial resolution as equivalent scale"@en ;
  rdfs:comment """Spatial resolution expressed as equivalent scale, 
    measured by using a representative fraction (e.g., 1:1,000, 1:1,000,000)."""@en ;
  rdfs:range xsd:decimal ;
 .

geodcatap:spatialResolutionInDegrees a rdf:Property ;
  rdfs:label "spatial resolution as angular distance"@en ;
  rdfs:comment """Spatial resolution expressed as angular distance, 
    measured in decimal degrees."""@en ;
  rdfs:range xsd:decimal ;
 .

geodcatap:spatialResolutionAsVerticalDistanceInMeters a rdf:Property ;
  rdfs:label "spatial resolution as vertical distance"@en ;
  rdfs:comment """Spatial resolution expressed as vertical distance, 
    measured in metres."""@en ;
  rdfs:range xsd:decimal ;
 .

• in B.6.4 note, last bullet, dcat:endpointURL is mentioned twice - it should be dcat:endpointURL and dcat:endpointDescription
• in Example 40 bad quotes are used - “ instead of "

In this example: https://github.com/SEMICeu/GeoDCAT-AP/blob/gh-pages/releases/examples/dataset.ttl

in the following property, I think you are missing that it is dct:Location

dct:spatial [ dcat:bbox "<gml:Envelope srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84">gml:lowerCorner-31.285 27.642</gml:lowerCorner>gml:upperCorner34.099 70.075</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral,
"POLYGON((-31.285 70.075,34.099 70.075,34.099 27.642,-31.285 27.642,-31.285 70.075))"^^gsp:wktLiteral ] ;

Review originally submitted in #16 (comment) by @AntoRot

A couple of comments linked to this topic:

1. In the table given in the section B.6.16, listing the mappings for responsible party roles, the RDF property dct:creator could be also mapped with the role originator as well as with the role author defined in ISO 19115.
2. Concerning the metadata point of contact, as INSPIRE TG states that the only role to be considered is pointOfContact of ISO 19115 code list CI_RoleCode, only dcat:contactPoint should be used in GeoDCAT-AP without using prov:qualifiedAttribution in this case. In the example 39 both dcat:contactPoint and prov:qualifiedAttribution are instead used for the metadata contact point.

Although RDF datatypes exist for WKT and GML (they are defined in GeoSPARQL), an XML / RDF datatype for GeoJSON is missing.

To address this issue, GeoDCAT-AP v1.0 uses the URL of the corresponding IANA media type (namely http://www.iana.org/assignments/media-types/application/geo+json), but this solution is not optimal, and the definition of a specific datatype might be considered. In such a case, the question is whether this should be done in the framework of GeoDCAT-AP or of the Core Location Vocabulary.

About this issue, see also SEMICeu/Core-Location-Vocabulary#2

At the time of the release of GeoDCAT-AP v1.0 (December 2015), GeoJSON provided support to arbitrary coordinate reference systems (see the original specification).

In the new specification (RFC 7946), standardised in the framework of IETF, this is no longer the case, and the only supported coordinate reference system is CRS84 (i.e., WGS84 lon/lat) - see RFC 7946, Section 4.

Because of this, the use of GeoJSON in GeoDCAT-AP might need to be reconsidered - at least by including a caveat, and some guidance on when and how to use it.

The W3C DXWG is considering relaxing the domain of dcat:keyword and dcat:theme for the revised version of DCAT. These proposals are documented in w3c/dxwg#121 and w3c/dxwg#123 , respectively.

In such a case, they could also be used for services.

The GeoDCAT-AP specification could be revised accordingly, taking nonetheless into account backward compatibility.

This issue is meant to provide a checklist of the revisions needed to align GeoDCAT-AP with the INSPIRE Metadata Technical Guidelines, version 2.1.3:

https://inspire-mif.github.io/technical-guidelines/metadata/metadata-iso19139/

Related issues:

• #72

See SEMICeu/DCAT-AP#54

The usage note for dct:accessRights says in §4.12.3:

This property refers to information that indicates whether the Dataset is open data, has access restrictions or is not public. A controlled vocabulary with three members (:public, :restricted, :non-public) will be created and maintained by the Publications Office of the EU.

A code list with those values have been actually published by the OP, so the usage note should be updated accordingly.

See also SEMICeu/DCAT-AP#159

For this purpose, GeoDCAT-AP v1.0 uses property locn:geometry, because none of the reference vocabularies were supporting a more specific approach.

The situation has not changed, so the question is whether it is worth addressing this issue by defining appropriate classes and/or properties, and, in such a case, whether this should be done in the framework of GeoDCAT-AP or of the Core Location Vocabulary.

A proposal is outlined in SEMICeu/Core-Location-Vocabulary#2

This issue is meant to provide a checklist of the revisions needed to align GeoDCAT-AP with:

• DCAT-AP 3.0.0: https://semiceu.github.io/DCAT-AP/releases/3.0.0/
• DCAT 3: https://www.w3.org/TR/vocab-dcat-3/

Related issues:

• #71
• #72
• #73
• #75

ℹ️ Parent issue: #71

Problem statement

Properties for class dcat:DatasetSeries should comply with both DCAT-AP 3 and the INSPIRE Metadata Regulation and Technical Guidelines.

DCAT-AP 3 supports a specific set of properties for dataset series, consisting of a subset of those of datasets, plus some specific to dataset series (see the DCAT-AP 3 specification, §7.9).

On the other hand, in INSPIRE, datasets and dataset series share the same set of metadata elements - see the Annex to the INSPIRE Metadata Regulation (Part C), and the INSPIRE Metadata Technical Guidelines (§C.2).

Proposal

To be aligned with DCAT-AP 3, DCAT 3, and the INSPIRE Regulation and Technical Guidelines, in GeoDCAT-AP 3 the properties of class dcat:DatasetSeries should correspond to the union of:

• the properties associated with class dcat:Dataset in GeoDCAT-AP 3, and
• the properties supported for class dcat:DatasetSeries in DCAT-AP 3.

The W3C DXWG is considering extending the scope of DCAT to resources different from datasets (services included). This proposal is documented in w3c/dxwg#172.

The GeoDCAT-AP specification could be revised accordingly, taking nonetheless into account backward compatibility.

References to ISO 19115:2003 should be replaced by references to ISO 19115-1:2014:
https://www.iso.org/standard/26020.html

B.6.10 of GeoDCAT-AP 2.0.0 refers to "draft" of GeoSPARQL 1.1.

GeoSPARQL 1.1 has been released since, so the references need to be rephrased.

Dear

I want to report an unexepected proprety of the Data Service class of the GeoDCAT AP model. As I read that here (https://semiceu.github.io/GeoDCAT-AP/releases/#data-service-topic-category) one is invited to use the dct:subject proprety in order to express the ISO 191115 category of a Data Service.

As you probably know the European Regulation 1205/2008 states that metadata describing datasets should contain such an element but not the metadata describing services (moreover I think adding such an element in the ISO 19139 file of a service would go against the schemas).

Did you add that attribute on purpose or is that a mistake?

Regards,

Benoît

ℹ️ Following discussion in #16 & #30

Currently, GeoDCAT-AP defines only 1-to-1 mappings from the ISO 19115 / INSPIRE responsible party roles to the corresponding properties in DCTERMS and DCAT.

Should we consider supporting 1-to-many mappings, so to ensure a wider coverage of responsible party roles?

NB: This issue is partially related to the proposal of defining properties for the unmapped roles - see #32

The dct:Location in Example 35 has multiple dcat:bbox attributes (to show off the possible encodings). But dcat:bbox has the cardinality 0..1 in dct:Location:

The W3C DXWG is considering relaxing the domain of dcat:landingPage for the revised version of DCAT. This proposal is documented in w3c/dxwg#122.

In such a case, dcat:landingPage could also be used for services.

The GeoDCAT-AP specification could be revised accordingly, taking nonetheless into account backward compatibility.

Dear GeoDCAT-AP team,

I know DCAT-AP 3.0 has only been out a couple of days but are there any plans to align GeoDCAT-AP with the new version of DCAT-AP (and by extension, DCAT-3)? And if so, what would roughly be the timeframe?

I'm working on a cataloguing project focussing on environmental datasets. Our principal reference model is DCAT-AP in order to be compatible with various national and European data catalogues, but we also require the specific scope of GeoDCAT-AP to align with INSPIRE-related requirements for some datasets. We have several use cases for the new DatasetSeries in DCAT-AP and would welcome being able to remain fully compatible with both profiles.

Dear,

I hope you are all fine.

I have a question about two unexisting propreties of the Dataset class. As you know, on the one hand licence and access rights propretries are not listed as recommanded or optional propreties of the Dataset class. On the other hand there are listed as recommande/optional propreties of the Distribution class.

At the federal belgian administration we are very interested by creating and publishing (geo)DCAT AP files by using original INSPIRE/ISO metadata records: it is our paradigm to use XML content and to follow INSPIRE/ISO ways of assambling metadata. The European Regulation 1205/2008 states that Limitations on public access (mapped to GeoDCAT AP access right) and Conditions for access and use (mapped to GeoDCAT AP licence) characterize the datasets (and not the particular files that one can download).

Furthermore, I cannot see the meaning of different licences or use limitations for different "phyical embodiments" of the same dataset in different formats to reuse the terms of the Distribution's definition.

So my question is: what were the specific reasons to exclude these two propreties from Dataset and to add them in the Distribution class: access rigjhts is even included in the DCAT AP profile as optional proprety so I can assume that there was a purpose to that choice.

Regards,

Problem statement
The generic property dct:subject is used for specific code list "Topic categories in accordance with EN ISO 19115"​
(see B.6.8.1 Topic category and keyword in datasets and dataset series)​.

• Correct assignment of usage notes, labels and required code lists rather difficult, as well as validation​
• not in line with guidelines of SEMIC Style Guide​
  • Reuse of a property with terminological adaptations or​
  • Reuse of a property with semantic adaptations.​
• Even more problematic in a cross-profile environment - incompatible requirements can be easily made​

Proposal
Introduce subproperty of dct:subject​ geodcatap:topicCategory for "Topic categories in accordance with EN ISO 19115" code list​.

Section B.4.1 Overview of bindings for GeoDCAT-AP Core: add also dcat:DataService as domain for the property dct:title;

Section B.6.4 Resource locator - *On-line resource: the property mapped to the value "download" in ISO 19115 – CI_OnlineFunctionCode should be dcat:downloadURL;

Section B.6.4 Resource locator - *On-line resource: concerning the service protocol, the URIs referenced in the INSPIRE register "Protocol values" should be used.

As explained in the email report of 23 May 2016, the Data Quality Vocabulary (DQV) models conformance by using dct:conformsTo (as done in Geo/DCAT-AP). The relevant section uses GeoDCAT-AP as an example:

https://www.w3.org/TR/vocab-dqv/#ExpressConformanceWithStandard

This approach was also reported in the Spatial Data on the Web Best Practices published by the joint W3C/OGC Spatial Data on the Web WG, by using a GeoDCAT-AP-related example (see section on spatial metadata.

However, DQV does not provide a solution to model test results different from "conformant" (e.g., "not conformant", "not evaluated"). The rationale is explained in a note to the same section:

Finer-grained representation of conformance statements can be found in the literature, and applications with more complex requirements may implement them, including for example the requirement of representing 'non-conformance' tested by specific procedures. The GeoDCAT Application Profile, for example, suggests a "provisional mapping" for extended profiles, which re-uses the PROV data model for provenance (see Annex II.14 at [GeoDCAT-AP]). Such patterns come however at the cost of having to publish and exchange representations that are much more elaborate. They will also have to be aligned with the result of another ongoing efforts on data validation and the reporting thereof, as currently discussed around SHACL, for example. We have thus decided to postpone addressing these requirements for now.

Therefore, there is not, at the moment, an alternative solution to the one defined in GeoDCAT-AP.

In https://semiceu.github.io/GeoDCAT-AP/releases/#agent-roles a number of agent roles are presented. A question arises when considering that there could be a more strict definition or expectation of a role within a specific context.

For instance, a distributor is a role about distributing a resource. That is clear for a Distribution as this is a precise specific instance of a Dataset. For a Dataset the semantics become a bit more fuzzy: is the distributor agent responsible for the distribution of all Distributions associated with a dataset?

Assessing the impact of the agent-roles and associating them with a preferred DCAT class could be discussed.

It is to be decided whether a definition of Resource (in the sense of dcat:Resource) should be included.

The proposed definition is the DCAT2 one:

A Resource is a dataset, data service, or any other kind of resource documented in a catalogue.

Having such definition (even though class dcat:Resource will not explicitly included) would help scope references to this notion inside class and property descriptions. Without it, resource may be intended not as "any type of resource documented in a catalogue" but in its far broader RDF sense - i.e., "All things described by RDF are called resources, and are instances of the class rdfs:Resource. This is the class of everything." [RDF-SCHEMA], §2.1.

If such definition will be included, it would be desirable that future versions of DCAT-AP be aligned accordingly.

§2 Terminology defines recommended classes and properties inconsistently. Quoting:

Recommended class: a sender of data SHOULD provide information about instances of the class; a sender of data MUST provide information about instances of the class, if such information is available; a receiver of data MUST be able to process information about instances of the class.

Recommended property: a receiver MUST be able to process the information for that property; a sender SHOULD provide the information for that property if it is available.

They should be aligned.

This code list has not yet been added to the INSPIRE Registry.

To be decided if any action should be taken.

In https://semiceu.github.io/GeoDCAT-AP/releases/#optional-properties-for-catalogue (and more specific https://semiceu.github.io/DCAT-AP/releases/3.0.0/#Distribution.rights) there is a max-cardinality of 1 for rights. When mapping our ISO INSPIRE records we create multiple rights statements. This is because each statement in stored in the ISO records as an embedded statement and not as an external linked webpage.

Proposal: relaxing the max-cardinality for rights.

As part of the GeoDCAT-AP alignment with DCAT 3 and DCAT-AP 3, Dataset Series is being investigated.
In the open data (DCAT-AP) community, Dataset Series is being used just as a grouping element for Datasets, which hold majority of the relevant metadata, and therefore only few metadata options for Dataset Series are available in DCAT-AP.

However, in the Technical Guidance on Implementation of INSPIRE Metadata, a Dataset Series can have the same metadata description as a dataset.

In order to keep the GeoDCAT-AP specification concise and to avoid unnecessary mappings, we are investigating, how Dataset Series is actually being used in the INSPIRE community. Whether it is too being used just as a group of datasets, or whether the full range of available metadata is being used meaningfully.

We therefore ask the INSPIRE community to contribute their experience with usage of Dataset Series metadata in this issue. Please state whether you use Dataset Series just as a group of datasets, or, if not, which metadata elements are being used and with what meaning to the Series and to the contained datasets.

Problem statement

Following DCAT 3, DCAT-AP 3 introduces a set of versioning properties, replacing the corresponding ones in earlier versions of DCAT-AP (see the DCAT-AP 3 specification, §A.1).

In particular:

• dcat:hasVersion replaces dct:hasVersion (deprecated).
• dcat:isVersionOf replaces dct:isVersionOf (deprecated).
• dcat:version replaces owl:versionInfo (deprecated).

Proposal

To be aligned with DCAT-AP 3 and DCAT 3, GeoDCAT-AP 3 should deprecate the use of dct:hasVersion, dct:isVersionOf, and owl:versionInfo, and replace them with dcat:hasVersion, dcat:isVersionOf, and dcat:version, respectively.

ℹ️ Copy-pasted from SEMICeu/Core-Location-Vocabulary#2

Currently, this information is specified in DCAT-AP by using schema:startDate and schema:endDate, respectively, following ADMS. GeoDCAT-AP v1.0 follows the same approach.

This issue has been brought to the attention of the W3C Dataset Exchange Working Group (see UC27), so a possible solution might be contributed in that context.

In the section 2. Terminology used in the Application Profile:

• a possible definition of 'Resource' can be that one given in the ISO Standard 19115-1, i.e. "Identifiable asset or means that fulfils a requirement. EXAMPLE: Dataset, dataset series, service, document, initiative, software, person or organization";

• the definition of 'Data Service' can be that one given in DCAT v. 2., i.e. "A collection of operations that provides access to one or more datasets or data processing functions". This definition is very similar to that one of "Spatial Data Service" given in the INSPIRE Directive (Art. 3), i.e. "Spatial Data Services are the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata".

Related issue: SEMICeu/DCAT-AP/issues/128

Property and class descriptions are not taking into account that the scope of the new version of DCAT includes other resource types (e.g., data services).

They should be updated accordingly, by replacing catalogue and datasets with the general notion of Resource (dcat:Resource).

If this revision will be implemented, it would be desirable that future versions of DCAT-AP be aligned accordingly.