I have the OAI-PMH module configured to use sites as sets. The OAI feed for one of my sites is generating incorrect URIs in the metadata - it’s using the wrong site name in the URI.
Here’s the site for which the URI issue is occurring:
https://collections.chattlibrary.org/s/obits
And the OAI feed:
https://collections.chattlibrary.org/oai?verb=ListRecords&metadataPrefix=oai_dcterms&set=obits
To use the first record in the list as an example:
URI in the OAI record: AARON, CHARLOTTE ANN · Digital Collections, Local History & Genealogy · Collections | Chattanooga Public Library
Correct URI: AARON, CHARLOTTE ANN · Chattanooga Obituary Index · Collections | Chattanooga Public Library
I’ve double checked and the above item, along with the others, are ONLY assigned to the Obits site, not the Local History site.
I’m attaching screenshots of my OAI module settings - please let me know if there is a setting I should change to resolve this. I would have thought setting “Add identifier for site repositories” to “relative site url” would do the trick, but that hasn’t helped.
This is @Daniel_KM 's module so I’m not the best expert on it, but from a quick look, it looks like for the “global” repository which you’re using here, the “Add identifier for global repository” option will just always make identifiers that link to the site you have configured in Omeka S as the “default” site. So here I assume the “localhistory” site is set as your default site and that’s why you’re getting this output.
Thank you for your reply. I changed the default site to be the site index, and this did remove “localhistory” from the URI on my obit site OAI feed. However, now the URIs appear with “api” in the segment where the site name should be. For example:
<dcterms:identifier xsi:type=“dcterms:URI”>https://collections.chattlibrary.org/api/items/155701</dcterms:identifier>
https://collections.chattlibrary.org/oai?verb=ListRecords&metadataPrefix=oai_dcterms&set=obits
I’ve tried tinkering with the module settings (“Site repositories” options, “Add identifier” options, etc) but haven’t landed on a solution. See screenshot below for my current config that’s giving me “api” in the URI. If you or @Daniel_KM can advise on correct configuration to have the OAI feed generate site-specific item URIs, I would be so appreciative. Please let me know if you need any other info from me.
Again I can only say what a cursory read of the module indicates (I wrote the Omeka Classic predecessor to this module, but not the S version you’re using here, and this is really a question specific to the integration with Omeka S), but it looks to me like there really isn’t a mode for having the module use just a site that the item belongs to in the “global” mode for these identifiers. If you turn on one of the “site url” identifier options then you have to have a specific default site selected, and that will always get used regardless of whether the item is in that site.
As long as you don’t mind the repository only having the items in a specific site, using the site-specific repositories should side-step the issue, i.e. https://collections.chattlibrary.org/s/obits/oai?verb=ListRecords&metadataPrefix=oai_dcterms
Constructing the OAI feed url in this way does meet our needs - thank you!!
Sorry to arrive late to this discussion, but we have the same issue here at NOVA FCSH (Lisbon) with the OAI-PMH module for Omeka S. It seems that this module wasn’t ported completely from Omeka C (where you have a unique domain/url). I tested some item sets in both Omeka S and C and in the latest the OAI-PMH works just fine, the items in the OAI-PMH feed all have an identifier field that has their public page (or view). Instead, in the Omeka S instance, it seems the module it’s unable to configure the list of items according to the specific site item set. If you don’t config a default website, the uri always come with an api just like CPLcollections case (even if you configure the module to present the site item sets as full url). The only way around this it’s to define a default website, but then all the items uri have the same base url, even if that item it’s not part of that site, and in that case you loose the connection of the item public page to it’s website.
