Support other catalogs?

[axfelix]

Hi,

A colleague alerted me to this project last week as we were looking for a very minimal way to expose an OAI server for the records we're harvesting with https://frdr.ca, in order for us to be indexed by OpenAIRE. I've gone ahead and added a "Postgres" catalog to a fork https://github.com/axfelix/viringo since we'll be serving records directly from the DB and while I think that's a really valuable use case, I wonder if it makes sense to rename the catalog type to something other than "Postgres" since it's obviously tailored to our data structure.

Let me know what you'd like to see happen before a PR, basically, and thanks for this!

[richardhallett]

Hello,

We talked about this here at DataCite and we're happy to look at a PR to have this maintained in one location, of course with being controlled this side, if you need to make changes to your service/catalog then you are reliant on us to merge changes and rebuild docker containers.

Additionally while I did write this with some idea of supporting other services (notably at the time maybe CrossRef or other public metadata API) it is somewhat setup for our use case here at DataCite, therefore we have to ensure any changes won't affect our running service.

However if this still works for you, then yes we'd probably suggest making the service/catalog specific to your organisation, because as you said it's not generic more specific to your data structure.

Thanks for getting in touch though! We're always glad to see any of our open source work be useful to others.

[axfelix]

Great, Richard, thanks!

I've got this working in my fork to a point I'm nearly happy with (mostly going to fine-tune some of the metadata display and fix some edge cases around sets/identifiers, but the other functionality is all working) and I've taken care to refer to us as "FRDR" rather than "Postgres" throughout to avoid confusion. I should have a PR by the end of this week.

[axfelix]

Good news -- we're ready to merge upstream (only two months later than I thought, not bad). Bad news -- it looks like our fork is running behind master at this point and we'll need to sync it and add some tests. Stay tuned.