Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification welcomed on the next steps for the GeoDCAT-AP 3.0.0 pilot #1

Open
NielsHoffmann opened this issue Dec 10, 2024 · 0 comments

Comments

@NielsHoffmann
Copy link

In the meeting of 20 november 2024 on the GeoDCAT-AP 3.0.0 pilot is was suggested to use this repository to post issues regarding the pilot itself. So here goes...

During that meeting a number of organisations brought forward some similar issues. Some of them are currently logged as issues in either the GeoDCAT-AP or the iso-19139-to-dcat-ap github repositories, but I don't believe all issues are logged there.

I would very much welcome some clarification on the timeline and approach for the pilot going forward. How do we envision discussing (and hopefully resolving) the issues and what would be the result of that process?

Apart from the 'practical' issues we are encountering during the testing phase in this pilot I think there are two underlying 'architecture' discussions I would like clarification on.

  • The design of the SHACL Files.
    It seems that from the 2.2 release to the 3.0 release of the shacl files of the core DCAT-AP profile a switch has been made from using separate files for the various 'compliance levels' to using one massive file. Apart from the fact that there seem to be some inconsistencies in this switch I can't find any documentation on the rationale about this switch. To me it would make more sense to maintain separate files, but if there is certain reasoning behind this switch, I would like that documented properly.

  • A shared vision on the pupose and goals of the iso-19139-to-dcat-ap xslt.
    Implementing parties seem to approach the transformation from iso to dcat in slightly different ways. For example in the core Geonetwork-opensource implementation they 'modularized' the transformation file in order to support different profiles as efficiently as possible. In doing so it is not feasable to keep the implementations in sync. I imagine other parties face similar challenges.
    So from that perspective I would like to have clear 'guidelines' what we are trying to achieve with the iso-19139-to-dcat-ap xsl. Do we aim it to be a 'reference implementation', or simply an 'example' how the transformation could be performed?

Happy to elaborate, or split those questions into separate issues for targeted discussion.
I'm hoping for a nice joint effort to create the best possible GeoDCAT-AP profile we can achieve!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant