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
MARC21 probably has the same problem. Asking Christophe to take care of it too
Created attachment 4083 [details] [review] proposed patch for 3.2
After checking, following the comment of Paul, no similar url link in MARC21slim2OAIDC.xsl, so nothing done about that.
Created attachment 4084 [details] [review] new proposed patch for 3.2
Created attachment 4085 [details] [review] proposed patch for 3.4
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?)
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.
(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>
> > 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.
> 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.
(In reply to comment #9) > If we want consistency, we must modify XSL to construct the > same identifier. That seems to make excellent sense! ;-)
(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?
Created attachment 4104 [details] Few UNIMARC records
(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)
(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.
> 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.
Updating Version : This ENH will be for Koha 3.8
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)
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?