You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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!
The text was updated successfully, but these errors were encountered: