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
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: