[Koha-bugs] [Bug 6334] Using OAI with the OPACBaseURL syspref

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

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

--- Comment #16 from Frédéric Demians <frederic at tamil.fr> 2011-05-13 15:55:55 UTC ---
> but about the url, in my opinion in
> UNIMARslim2OAID.xsl we have a hardcoded link  not to go to
> OAI-PMH:IdentifierBase but to go to the biblio in the library site. I
> have transformed http://opac.mylibrary.org/bib/xxx because one of our
> customer have a specific adress, to avoid for each specific case a
> rewrite in the xsl file...  eg if OPACBaseURL == mabase.com, with the
> patch we have http://mabase.com/bib/biblionumber. In your example
> Frederic, we'll not have http://mylibrary.tld.fr4589 but
> http://mylibrary.tld.fr/bib/4589... Perhaps I'm wrong, sorry in this
> case, but I am not aware about this syspref and OAI in general, could
> you explain me in this case.

As it has been said above, thanks to Magnus, the identifier is already
in the result returned by Koha OAI server in the header section:

<ListRecords>
<record>
<header>
<identifier>MY-OAI-PREFIX-OAI:1</identifier>

What you find here before the biblionumber comes from OAI-PMH:archiveID
syspref. So for consistency purpose, the second identifier located in
the dublin core could be the same. Another option could be to just
remove it and rely only on the header identifier. This identifier could
be a link back to Koha OPAC detail page. But there is no rule for that.

Don't forget that if you have specific needs, you can operate the OAI
server in extended mode and then use a local specific XSL file, and 
even several XSL, one per metadata format.

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.