[Koha-bugs] [Bug 10662] Build OAI-PMH Harvesting Client

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

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662

--- Comment #2 from David Cook <dcook at prosentient.com.au> ---
(In reply to Galen Charlton from comment #1)
> (In reply to David Cook from comment #0)
> > Currently, Koha only acts as a OAI-PMH server, I propose to add a harvesting
> > client as well (likely using the HTTP::OAI::Harvester module), so that Koha
> > can ingest records from other data sources (such as digital repositories
> > like Dspace).
> 
> Interesting idea.
>

I'm glad that you approve :). I think you wrote a bit on the subject a few
years ago when the OAI-PMH support was first added to Koha, no? 

> 
> > I've only started reading about it but despite initial reservations about
> > resumption tokens, I think the hardest part will not be with the retrieval
> > of records so much as the parsing of those records into MARC.
> 
> This may be less of a problem in the long run with my plans to allow Koha to
> support multiple metadata formats (although even once that's available, you
> may still want the harvester to be able to convert the source metadata into
> something else).
>

I was thinking about that as I started my research, but I'm not sure how far
along you are with your plans for metadata diversity. While I'm extremely
excited for your work in that area, I suppose I wonder a bit about how feasible
(both in terms of time to get there and ultimate function) it is given the
current reliance of Koha on MARC data. 

In any case, like you say, the ability to transform incoming data might still
be desired. Either in terms of changing metadata formats or even adding local
data to incoming records. 

>  
> One thing I'd suggest is that the harvester keep a copy of the original
> metadata record in a database table; that would be more flexible than
> immediately converting it to MARC and discarding the source data.
>

Agreed. I was thinking of having a table to keep track of source record
identifiers, since I'm still not familiar with resumption tokens, so I could
certainly add columns for biblionumber and source metadata record. As you say,
that would add flexibility for the future plus give people a source of truth,
since data conversion isn't always precise or infallible.

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