Representation of records moving between sets

Skip to first unread message

John Salter

Feb 10, 2022, 8:31:14 AMFeb 10


I have a controlled-list field that is being used to generate OAI-PMH sets e.g.

setSpec: primo-A

setSpec: primo-B

setSpec: primo-C


A record will belong to either zero or one of these sets.

If a record is updated, it may move between sets e.g. from 'primo-A' to 'primo-B'.


If a record has moved between sets, must it be represented in a request for it's previous set as a 'deleted' record (e.g. removed from that set), or is set membership somehow transient?

My use-case is harvesting specific records from our institutional repository into our Library catalogue (Primo).

Due to constraints in how we can represent records in Primo, we only want to harvest records that fulfil one of these:

- are fully open access

- have a link to an OA copy elsewhere

- have a 'Request a Copy' link

We want to exclude records that have no full-text, or no immediately available full-text.




John Salter


White Rose Libraries Technical Officer
IT - Application Support (Research)
10.23B, IT Services Building
University of Leeds


Simeon Warner

Feb 10, 2022, 8:48:19 AMFeb 10
Hi John,

I'm afraid this is a "bug" in the OAI-PMH model -- the notion of selective harvesting using sets does not support understanding of items that move between sets. The issue of an item moving into a set is solved by correctly updating the datestamp for the change. However, the specification doesn't provide a mechanism to know that an item has move out of a set unless it is deleted entirely. From a harvesting point of view this could be solved by changing the identifier (which essentially means old record deleted, new one added). but for most use cases that is undesirable for plenty of other reasons. I don't know of a generally viable workaround.


John Salter

Feb 10, 2022, 9:01:54 AMFeb 10
Hi Simeon,
Thanks for the quick reply. Glad I hadn't overlooked something in the spec!

In this specific case, I think the best solution will depend on the behaviour of the harvester.
I'll do some fine-grained testing of the Primo harvest behaviour and plan from there.

The movement of a record between sets is triggered by other aspects of the record changing, so the datestamp will be updated and the 'into' will be OK.


From: <> on behalf of Simeon Warner <>
Sent: 10 February 2022 13:48
To: OAI-PMH <>
Subject: [OAI-PMH] Re: Representation of records moving between sets

You received this message because you are subscribed to the Google Groups "OAI-PMH" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Ferran Jorba

Feb 15, 2022, 6:04:13 AMFeb 15

I have done changes like this one and I think that the protocol resolves it well enough. In the response header there is the oaiset list field <setSpec> where this record appears. If the record is updated, and thus its datestamp, even only to change those values, it is up to the harvester to take into account this information.

For example:

So from the protocol point of view, I don't think that it is necessary to delete the record or change the identifier. Another issue is if the harvester is able to make good use of this information.

Best regards,

Ferran Jorba
Universtitat Autònoma de Barcelona

Missatge de John Salter <> del dia dj., 10 de febr. 2022 a les 15:01:

John Salter

Feb 16, 2022, 5:54:59 AMFeb 16

Hi Ferran,
Thanks for the reply.

I think I'm trying to address the 'harvester is able to make good use of this information' part of your response.


In Primo, it looks like we can process the <metadata> section of the record, but can’t apply logic to anything (such as sets) in the <header> element.


I'll provide some more info here once we have worked out what we can or can't do in Primo, in case others are attempting something similar.




Ferran Jorba

Feb 16, 2022, 8:07:29 AMFeb 16
Hello John,

I was slightly involved with Primo, but only to provide and configure the repository oai interface, not configuring Primo itself.  During the last year, our university has changed from Primo (Innovative) to Alma (ExLibris).  My colleagues say that Primo was more limited than Alma, but sincerely, I don't know the details, as it is done by another team.

Anyway, dealing with commercial providers is a headache that I try to avoid as much as possible.

Good luck,

Ferran Jorba
Universtitat Autònoma de Barcelona

Missatge de John Salter <> del dia dc., 16 de febr. 2022 a les 11:55:
Reply all
Reply to author
0 new messages