no longer outputting dcterms fields?

[DigExpCon]

We aggregate data for a DPLA hub and harvest from our partner sites quarterly. I am harvesting records again for a July ingest, but our partners' Omeka Classic sites no longer have dcterms fields in their data. Nothing has changed in the sites' set of plugins or configuration that I know of. Did something change in the last Omeka Classic update? What do we need to do to get those fields back at the OAI endpoint?

[zerocrates]

Do you have an example accessible endpoint or request?

Official support inside this plugin for returning "qualified" records is rather new actually (well, the qdc format is new, the RDF format has existed for a while but few seem to use it)... is it possible that these sites have upgraded the plugin and previously had manually enabled dcterms output somehow, perhaps with a modified older version?

I'd have to see some more information to be sure of what's happening but there's no relevant change that I can think of on the Omeka side, and if anything the only changes here at this plugin should be beneficial for QDC/dcterms output.

[DigExpCon]

Actually, I think it is an issue with how our harvester is set up. This request for qdc works fine:
https://prlibrary.cvlcollections.org/oai-pmh-repository/request?verb=ListRecords&metadataPrefix=oai_qdc

But the harvester is collecting oai_dc, which omits the fields. Sorry for the bother! (But thanks for the quick reply.)

[zerocrates]

It's definitely possible that they previously had some modified version and now have the "regular" 2.2 version of the repository: that version added the oai_qdc output format.

[DigExpCon]

Well it does seem like something has changed. I think the aggregator used to harvest just oai_dc, as all the XSLT transforms are written assuming oai_dc:dc records, not oai_qdc:qualifieddc. So it must have previously harvested just oai_dc that included all the dcterms fields.

…

On Thu, Jun 27, 2019 at 3:14 PM John Flatness ***@***.***> wrote: It's definitely possible that they previously had some modified version and now have the "regular" 2.2 version of the repository: that version added the oai_qdc output format. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#29?email_source=notifications&email_token=AJTPB6HUHIXM3W4LUNACB2DP4UUUXA5CNFSM4H3725U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYYMXEY#issuecomment-506514323>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJTPB6B7IR5AQ3QC3AM7TADP4UUUXANCNFSM4H3725UQ> .

-- Babi Hammond Digital Experience Consultant Colorado State Library

[zerocrates]

It seems quite likely that they changed versions of the plugin, then. Of course only the actual people running the installations could tell you for sure.

This "official" version has never supported outputting dcterms elements inside the oai_dc format, as that format is defined by the standard to only contain the base DC elements. QDC in OAI-PMH is a little bit of a Wild West scenario, with a fairly wide range of one-off solutions various organizations came up with to support it, although I actually haven't seen the "just put it in oai_dc" strategy too often. Perhaps this was a change to the plugin at these installations that was previously coordinated with your hub, then, and it was mistakenly overwritten by a maintainer of the site upgrading to the latest version of this plugin.

I assume that it would be a pretty trivial change to support the "qualifieddc" container element in your workflow, though. This would probably be preferable to a local "fork" of sorts.

[DigExpCon]

You are correct: the earlier version of the plugin had been modified. We’ll just rewrite the transforms for the qdc. Thanks again.

…

On Jun 27, 2019, at 4:08 PM, John Flatness ***@***.***> wrote: It seems quite likely that they changed versions of the plugin, then. Of course only the actual people running the installations could tell you for sure. This "official" version has never supported outputting dcterms elements inside the oai_dc format, as that format is defined by the standard to only contain the base DC elements. QDC in OAI-PMH is a little bit of a Wild West scenario, with a fairly wide range of one-off solutions various organizations came up with to support it, although I actually haven't seen the "just put it in oai_dc" strategy too often. Perhaps this was a change to the plugin at these installations that was previously coordinated with your hub, then, and it was mistakenly overwritten by the site upgrading to the latest version of this plugin. I assume that it would be a pretty trivial change to support the "qualifieddc" container element in your workflow, though. This would probably be preferable to a local "fork" of sorts. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.