Generating additional Distribution information from INSPIRE Atom feeds

[bfrichet3]

Dear Andrea,

I hope you are all fine. I would like to report a question of mine rather than a true issue.

This one concerns the way this API creates dcat:Distribution classes used to describe direct download links of datasets. The API creates these classes by using the resource locator INSPIRE metadata element (https://github.com/SEMICeu/iso-19139-to-dcat-ap/blob/master/documentation/Mappings.md#resource-metadata-specific-to-data-sets-and-data-set-series).

I have two concerns about using that metadata element to crete dcat:Distribution classes:

1. On the one hand that element is not mandatory concerning the datasets or series. TG Recommendation 1.9 of Technical Guidelines 2.0 recommends to fill such a tag with the direct download link but it is not mandatory and is never really used in the INSPIRE infrastructure. On the other hand it is mandatory to fill these direct download links in INSPIRE ATOM Feeds files which are used by the INSPIRE portal.

2. Moreover, as you may know it's almost impossible to describe ta download link on a machine readable way by using the CI_OnlineResource ISO 19139 tag (which expresses the resource locator). It is indeed impossible to specify in a machine readable way the projection system of a zip file or his format or version or if the download link gives access to the full dataset or to a smaller subset (if we are speaking about huge datasets like cadastral layers). These elements are specified on a better way inside the mandatory INSPIRE ATOM Feeds files.

So this is my question: did you consider using INSPIRE ATOM Feeds files of one dataset to create the dcat:Distribution classes of the same dataset?

As far as I see it, using ISO 19139 won't help to create well structured and understandable dcat:Distribution classes.

Regards,

Benoît

[andrea-perego]

Thanks for raising this issue, @bfrichet3 .

Extending the mapping rules to create distributions also from the INSPIRE ATOM feeds can be indeed part of future work.

There are, however, some aspects to be taken into account. The main problem is that this will require loading at runtime additional files (i.e., the relevant ATOM feeds), which will delay the transformation process, and reduce its efficiency. Moreover, timeout mechanisms should be put in place to deal with offline ATOM feeds, which will cause the transformation process to hang.

An option is to make this feature optional, e.g., by enabling / disabling it based on a parameter in the XSLT. But to address these issues effectively, some mechanisms (as the caching of ATOM feeds) should be put in place in production environments.

[bfrichet3]

Dear Andrea,

Thank you for your quick answer. I am quite aware much must be decided before implementing that but I wanted to collect your opinion about that before exploring this path with the belgian federal administrations involved in INSPIRE/DCAT AP conversion.

Regards,

Benoît