[Koha-bugs] [Bug 15108] OAI-PMH provider improvements

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15108

--- Comment #35 from Frédéric Demians <frederic at tamil.fr> ---
(In reply to Katrin Fischer from comment #32)

> Hm, I think in some cases it would be nice to include updates on available -
> I wouldn't rule that out. Maybe the decision to take the item change into
> account could be configurable?

You're correct. IMO there are three cases:

(1) I don't want to send item info to harvesters. The item info are not needed
or are retrieved later using Koha webservices. This could be achieved with
include_items=0.

(2) I want to send all item info to harvester, ie descriptive info (branch,
call number, etc.) and circulation info (due date). This could be achieved
with include_items=1. With Ere patch, those info are resent to harvester each
time an item record is modified, or if a new item is added to an existing
biblio record. It wasn't the case until now, which is a bug from my
perspective.

(3) I want to send to harvester item info, but just 'descriptive' info. I want
that because I don't need availability info for example, or because it will be
retrieved later via webservices. With the OAI-PMH protocol, the availability
can't be provided to third party tools (say VuFind) in real time: webservices
are needed. But items.homebranch could be very useful in a metacatalog
populated via harvesting. And in this case, real time is not a requirement. So
this mixed mode could make sense for some. Especially to avoid bringing a Koha
server to its knee.

(In reply to Ere Maijala from comment #34)

> That said, if you think there should be an option to control whether item
> timestamps are taken into account, I can add that. But you're right in that
> if you'd like to only ignore status changes caused by circulation actions,
> that's not possible without changes deeper in the system.

I suspect that such an option would just add confusion. For scenario (3)
described above, a new patch should be needed.

But I was just curious whether you was able to measure the number of OAI-PMH
requests to Koha on a large catalog with a lot of circulation.

> Additionally we need to take into account floating collections that would
> cause item's location to change on checkin. I'm really an outsider to Koha
> (mainly a VuFind developer), so I'm not sure how everything works in
> practice, so I apologize if what I say doesn't make sense or use the correct
> terminology.

Floating collections modify item records, and so timestamp field. So you UNION
request will work.

-- 
You are receiving this mail because:
You are watching all bug changes.