Bug 6334

Summary: Using OAI with the OPACBaseURL syspref
Product: Koha Reporter: Christophe Croullebois <christophe.croullebois>
Component: Z39.50 / SRU / OpenSearch ServersAssignee: Galen Charlton <gmcharlt>
Status: CLOSED WONTFIX QA Contact: Bugs List <koha-bugs>
Severity: enhancement    
Priority: P3 CC: chris, f.demians, katrin.fischer, magnus, paul.poulain
Version: master   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: proposed patch for 3.2
new proposed patch for 3.2
proposed patch for 3.4
Few UNIMARC records

Description Christophe Croullebois 2011-05-12 12:20:35 UTC
In the UNIMARslim2OAID.xsl the link to biblio is hardcoded, with this patch it
takes the value of OPACBaseURL.
Useful for Library with specific path
Comment 1 Paul Poulain 2011-05-12 12:26:05 UTC
MARC21 probably has the same problem. Asking Christophe to take care of it too
Comment 2 Christophe Croullebois 2011-05-12 13:27:28 UTC Comment hidden (obsolete)
Comment 3 Christophe Croullebois 2011-05-12 13:34:54 UTC
After checking, following the comment of Paul, no similar url link in MARC21slim2OAIDC.xsl, so nothing done about that.
Comment 4 Christophe Croullebois 2011-05-12 13:47:05 UTC
Created attachment 4084 [details] [review]
new proposed patch for 3.2
Comment 5 Christophe Croullebois 2011-05-12 15:18:27 UTC
Created attachment 4085 [details] [review]
proposed patch for 3.4
Comment 6 Chris Cormack 2011-05-12 20:52:42 UTC
Christophe, (or any unimarc user) can you please attach a couple of UNIMARC records here, or point me to some, so I can test. The code looks fine at first glance, and applies to master cleanly. But Id like to give a proper test.

Thank you

(PS is Christophe the French version of Christopher?)
Comment 7 Frédéric Demians 2011-05-13 05:39:41 UTC
I'm not for the integration of this patch for several reasons:

- In XSL file, the new syspref is named 'syspref', which is misty.

- It will produce identifier looking like that:

  http://mylibrary.tld.fr4589
 
  OAI identifier I've seen look rather like that:

  oai:institution-name:unique-id
  oai:univ-tours.fr:univ-tours-8437
  oai:halshs.archives-ouvertes.fr:halshs-00550946 

So I suggest to create a new Web Services syspref, something like
OAI-PMH:IdentifierBase, and to use it in XSL rather than OPACBaseURL.
Comment 8 Magnus Enger 2011-05-13 08:08:25 UTC
(In reply to comment #7)
> So I suggest to create a new Web Services syspref, something like
> OAI-PMH:IdentifierBase, and to use it in XSL rather than OPACBaseURL.

I think this is what the OAI-PMH:archiveID is already used for? The description of this syspref is "Identify records at this site with the prefix ___"

I have a live installation where OAI-PMH:archiveID = oai:bibkat.no:NO-1120127 and the resulting identifiers look like this: 

http://sksk.bibkat.no/cgi-bin/koha/oai.pl?verb=ListIdentifiers&metadataPrefix=oai_dc

I'm not sure why you would want an identifier that includes http://, but it seems to me that using OPACBaseURL for it would work fine. 

PS. This part of UNIMARCslim2OAIDC.xsl looks overly hardcoded too: 

<xsl:when test="marc:subfield[@code='c']='MAIN'">Main Branch</xsl:when>
<xsl:when test="marc:subfield[@code='c']='BIB2'">Library 2</xsl:when>
Comment 9 Frédéric Demians 2011-05-13 08:36:49 UTC
> > So I suggest to create a new Web Services syspref, something like
> > OAI-PMH:IdentifierBase, and to use it in XSL rather than OPACBaseURL.
> 
> I think this is what the OAI-PMH:archiveID is already used for? The
> description of this syspref is "Identify records at this site with the
> prefix ___"

Intersting. Yes, you're correct, this syspref could be used. In fact,
there are two identifiers: one in the <header> section of the response
and another one in the Dublin Core record. The first one is generated by
oai.pl script. That's what you're refering to. It's a valid identifier
build based on OAI-PMH:archiveID syspref. The second one is generated by
the XSL. If we want consistency, we must modify XSL to construct the
same identifier.
Comment 10 Frédéric Demians 2011-05-13 08:39:23 UTC
> PS. This part of UNIMARCslim2OAIDC.xsl looks overly hardcoded too: 

> <xsl:when test="marc:subfield[@code='c']='MAIN'">Main Branch</xsl:when>
> <xsl:when test="marc:subfield[@code='c']='BIB2'">Library 2</xsl:when>

It is an issue only if the OAI harverster need to sublocalize your
ressources. It's rarely the case. But in this situation, you have to use
Koha OAI server in extended mode and hand craft a local XSL.
Comment 11 Magnus Enger 2011-05-13 09:03:54 UTC
(In reply to comment #9)
> If we want consistency, we must modify XSL to construct the
> same identifier.

That seems to make excellent sense! ;-)
Comment 12 Frédéric Demians 2011-05-13 09:46:55 UTC
(In reply to comment #11)
> (In reply to comment #9)
> > If we want consistency, we must modify XSL to construct the
> > same identifier.
> 
> That seems to make excellent sense! ;-)

So, it's up to the patch submitter to propose an updated version 
of his patch?
Comment 13 Christophe Croullebois 2011-05-13 13:59:57 UTC
Created attachment 4104 [details]
Few UNIMARC records
Comment 14 Christophe Croullebois 2011-05-13 14:02:39 UTC
(In reply to comment #6)
> Christophe, (or any unimarc user) can you please attach a couple of UNIMARC
> records here, or point me to some, so I can test. The code looks fine at first
> glance, and applies to master cleanly. But Id like to give a proper test.
> 
> Thank you
> 
> (PS is Christophe the French version of Christopher?)

Done Chris, and yes Christophe is Christopher in French... ;o)
Comment 15 Christophe Croullebois 2011-05-13 15:28:30 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > If we want consistency, we must modify XSL to construct the
> > > same identifier.
> > 
> > That seems to make excellent sense! ;-)
> 
> So, it's up to the patch submitter to propose an updated version 
> of his patch?

Sorry but I am not sure to understand, first, right and ok for the name, I'll do a new patch with s/syspref/opacbaseurl/, 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.
Comment 16 Frédéric Demians 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.
Comment 17 Paul Poulain 2011-10-24 11:38:15 UTC
Updating Version : This ENH will be for Koha 3.8
Comment 18 Paul Poulain 2011-10-25 15:05:49 UTC
Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday)
Comment 19 Katrin Fischer 2011-12-21 05:39:19 UTC
There is no patch for master (although 3.4 patch applies there) and a lot of discussion about this bug. 
Christophe, Frederick and Magnus - can this be closed? Is this or another patch needed?