OAI-PMH repository plugin extended to allow export of DC extended elements

Hello,

although not having much experience with PHP and programming in general I think/hope I somehow made it to extend the OAI-PMH repository plugin in such a way that it is now possible to export also the Dublin Core Extented element refinements as well as stand-alone elements).

As a starting point I used the short manual that comes with the plugin.

After that I studied the OaiDc.php file in the /metadata folder of the plugin and used it as a template.

Furthermore I tried to follow the Guidelines for implementing Dublin Core in XML as close as possible.

Here is the result: https://gist.github.com/3187492 (every piece of code written by me has a comment starting with NEW)

Some Examples of the output can be found here:

List one complete test record

List All Records

One unsolved issue concerns the Open Archives XML namespace and schema for the output format which is currently tailored to the Dublin Core Simple Fields and completely excludes the DC extended fields. I think I have to create a new one but I still have to look into that.

It would be great if you can have a look at this and tell me if I'm on the right track here or not.

Regards, Matthias Einbrodt

Neat!

I believe you're right to be concerned about the namespace and schema: the oai_dc metadata format is set up to be just simple Dublin Core. Since it's the one format all repositories and harvesters are guaranteed to understand, you probably don't want to mess with it.

Other times I've looked into this, it's appeared that there's no "standard" metadata prefix or top-level namespace for qualified Dublin Core (see this now-very-old listserv thread for example).

Thanks for sharing your work. It looks like it should work pretty well, when separated from the oai_dc format. The de v listserv is probably a better audience for stuff like this, though.

Hello John,

thanks for your answer. I re-published the thread in the dev-list

Regarding the top-level namespace for qdc I found the thread you posted very helpful and I'm thinking why not just duplicating this approach? As far as I understood it, this should also solve all the issues regarding the namespace of the qualified and unqualified DC-element nested within the container element.

Best regards, Matthias