Which seem to be reasonably popular, we use them to modify the internal CKAN schema to match the DCAT standard.
We're looking into specifying additional field mappings in this plug-in so that the oaipmh fields show up in the appropriate fields according to the dcat standard.
Our idea is that if we provide is as an opt-in feature-flag/configuration item, it will be a backwards-compatible change, and there might be potential to avoid creating a fork.
This may also potentially be a large enough change that a simple fork is warranted.
Any thoughts?
And is this something you'd consider merging back (once we've developed it, and have a clearer idea of the scope)
Hi @metaodi ,
We currently use the following plug-ins: https://github.com/ckan/ckanext-scheming https://github.com/ckan/ckanext-dcat
Which seem to be reasonably popular, we use them to modify the internal CKAN schema to match the DCAT standard.
We're looking into specifying additional field mappings in this plug-in so that the oaipmh fields show up in the appropriate fields according to the dcat standard.
Our idea is that if we provide is as an opt-in feature-flag/configuration item, it will be a backwards-compatible change, and there might be potential to avoid creating a fork.
This may also potentially be a large enough change that a simple fork is warranted.
Any thoughts? And is this something you'd consider merging back (once we've developed it, and have a clearer idea of the scope)
Thanks, Edward