[OAI-implementers] harvester guidelines
Jasper Op de Coul
opdecoul at ubib.eur.nl
Thu May 26 06:43:31 EDT 2011
Hi list,
I've been doing some work with OAIPMH harvesters lately, and would like
to share some of my experiences on the subject.
When harvesting specific sets with the `set` param, there is an issue
that a harvester is not notified when a record is removed from that set.
I think most implementers are aware of this, and it is the biggest hole
in the specification.
For example: A specific set is harvested, but at a later time one of the
records is no longer part of that set. The record then disappears from
the feed, but the harvester is never notified because there is no delete
event.
There are several ways to deal with this:
1. Do incremental harvests with the ?set param, then do a full harvest
periodically or when someone calls or mails that records are missing.
This is a common approach but it is no solution to the problem. I think
we can and should do better then that.
2. Always do a full harvest with the ?set param. This will put a lot of
load on the servers, take lots of time, and is not a very social thing
to do. So, not a good option.
3. Use incremental harvests, but never use the ?set param. The client
will receive all records and can inspect the SetSpec header manually to
see if this record is part of the wanted set. Records that are not part
of the wanted set but are in the client database can be removed.
The last option means a lot more housekeeping for the client, but it is
the only way for a client to be sure that the data is correct.
Although sets are a very useful feature, the set parameter is basically
broken. This should be noted somewhere in the documentation, probably in
the harvester guidelines.
Personally I would be in favour of deprecating the set parameter so we
can put a big fat warning explaining this problem.
Another issue that came up recently has to do with incremental
harvesting. The harvester guidelines mention that for the value of the
from parameter, the `responseDate` should be used, and that it is
advisable to overlap by a small additional amount.
I think it would be better if a harvester does not use the
responseDate, but instead uses the latest datestamp of all harvested
records.
Consider the following situation:
Someone modifies a document in a database at 4 o'clock.
An external OAI service gets updated once an hour, so it will have the
changes at 5 o'clock. The OAI software will use the modification dates
from the database, so at 5 o'clock the modified record is added with a
datestamp of 4 o'clock.
If a harvester comes by at 4:30, that modifed document is not in the OAI
feed yet. An hour later at 5:30, the harvester harvests again with a
`from` parameter value of 4:30. The harvester will never get the
modified document because it was modified earlier then 4:30.
Off course this whole situation is far from ideal, but it could be that
there is a gap between the modification date of a resource, and when it
gets added to the oai server. This gap can be anything from a few
seconds to a few weeks.
If a harvester always uses the latest datestamp of any of the harvested
records, you are sure that no records are missed, and you never harvest
too much.
I hope this helps implementers build better harvesters. If there is
concensus about adding this to the harvester guidelines, I would be
willing to write some text for it.
Kind regards,
Jasper
--
Jasper Op de Coul -- Erasmus University Rotterdam
t +31 10 4082922 -- http://eur.nl/ub
Burgemeester Oudlaan 50 3062 PA Rotterdam -- The Netherlands
--------------------------------Disclaimer--------------------------------
De informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is
vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit
bericht. Lees verder: http://www.eur.nl/email-disclaimer
The information in this e-mail message is confidential and may be legally
privileged. Read more: http://www.eur.nl/english/email-disclaimer
--------------------------------------------------------------------------
More information about the OAI-implementers
mailing list