Data Service - topic category

[bfrichet3]

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

[andrea-perego]

@bfrichet3 , the issue you are raising was discussed in https://github.com/SEMICeu/GeoDCAT-AP/issues/23 .

I quote below the relevant points of the discussion:

These properties were already supported as optional in the first version of GeoDCAT-AP, and in the defined mappings, although it may be not so visible in the specification. The rationale was to be inclusive, and support possibly relevant metadata elements, even if not required in INSPIRE and/or ISO 19115.

[...]

To be noted however that in ISO 19115-1 the elements topic category and spatial resolution are supported both for datasets and for services, but that standard doesn't fall under the scope of GeoDCAT-AP.

So, probably it is worth keeping them in the GeoDCAT-AP vocabulary description, as done in the current draft (for possible use in GeoDCAT-AP records created directly in RDF).

ISO 19115-1 is indeed not covered by the GeoDCAT-AP mappings. However, support may be added in the future, and then we should have to re-include these metadata elements.

[bfrichet3]

Dear Andrea,

I hope you are all right and I thank you for your quick answer.

I take note of your remark concerning ISO 19115-1 and potential future developpements of GeoDCAT AP. In this case I assume that for the moment the existing API tool does not populate that proprety in the Data Service class.

Regards,

Benoît

[bertvannuffelen]

@bfrichet3, in addition to @andrea-perego answer to your concrete question on the motivation of inclusion of the property (which is optional b.t.w. (*)), I want to draw attention to maybe a difference in expectation you might have on GeoDCAT-AP.

The introduction of GeoDCAT-AP is

GeoDCAT-AP is an extension of the DCAT application profile for data portals in Europe (DCAT-AP) for describing geospatial datasets, dataset series, and services. Its basic use case is to make spatial datasets, dataset series, and services searchable on general data portals, thereby making geospatial information better findable across borders and sectors. For this purpose, GeoDCAT-AP provides an RDF vocabulary and the corresponding RDF syntax binding for the union of metadata elements of the core profile of ISO 19115:2003 and those defined in the framework of the INSPIRE Directive of the European Union.

Despite there is an important binding between INSPIRE (ISO) metadata description GeoDCAT-AP is an independent metadata standard, being a profile of DCAT-AP. So your expectation that GeoDCAT-AP is a RDF rewording of the INSPIRE(ISO) specification is wrong. What GeoDCAT-AP facilitates is that the information expressed in INSPIRE(ISO) catalogue can be represented as a W3C DCAT catalogue. The mapping from INSPIRE(ISO) to GeoDCAT-AP can be to a large extend automated (see the XSLT), but still decisions have to be made for your specific context. The other way around (turning a GeoDCAT-AP specification into a INSPIRE(ISO)) has not been formally explored. According to my knowledge I expect for that direction much more challenges, mostly because DCAT offers many options (e.g. almost every property can appear at the level of Dataset/Distribution/Data Service) and that some practices of DCAT(-AP) might not be compatible with the expectations of INSPIRE regulation. So if you goal is to create a DCAT based editor which structures can be converted to INSPIRE accepted XML structures, then GeoDCAT-AP is for sure a good start, but it won't be sufficient.

As @andrea-perego mentions if the community feels there need to improve support for extensions or new evolutions in the INSPIRE(ISO), then we are fine to explore them.

(*) On optional properties in DCAT(-AP) profile. These properties are given firm semantics, so if you do need to express e.g. a topic-category for a data service then you have to use this one (unless you locally explicitly want to diverge from it). However there is no must to include them in an editor. If you decide locally not to collect data of that property, then this is really fine. So you can decide not to include the property in your local ecosystem.

[bfrichet3]

Dear @bertvannuffelen ,

Thank you for your answer. When I created the issue I wanted to put emphasis on some elements which seemed quite unconsistent to me. Just for your own information, we want to make GeoDCAT AP from INSPIRE/ISO records but we want DCAT records to reflect the plenty of INSPIRE metadata.

1) As you probably know, the definition of ISO 19115 topic category is the following (https://standards.iso.org/iso/19139/resources/gmxCodelists.xml): "high-level geographic data thematic classification to assist in the grouping and search of available geographic data sets.". The ISO 19115 clearly states that such a proprerty applies to dataset and not service.

In my opinion, it was quite strange tocreate a GeoDCAT AP proprety (i.e. topic category) with an unapplicable ISO/INSPIRE element.

2) In a broader way I am sure it's technically possible to create such propreties but my question would be "what is the sens of such a proprety?" if a data service gives access to many dataset then the service has probably a lot of themes, maybe all of them. The proprety wouldn't be so useful to summarize the described service. In my opinion such propreties are semantically pointless.

Regards,

Benoît