[Yazlist] support for solrmarc?

Adam Dickmeiss adam at indexdata.dk
Tue Mar 18 17:40:55 UTC 2014


On 03/18/2014 06:04 PM, Michael Lackhoff wrote:
> As you know from my recent posts I am trying to return MARC from a Solr
> index that contains data produced by solrmarc (s. an example record at
> the bottom of this mail).
> To be able to embed an ISO-2709 record in XML the solrmarc people made
> one minor but decicive change: they replaced the separator characters
> that are illegal in XML with something very similar to an entity:
> &#1D; -> #29;  (record separator)
> &#1E; => #30;  (field separator)
> &#1F; => #31;  (subfield separator)
Boy that's ugly. And how's #29 then handled if it's NOT a control sequence?

IMHO, using an element for that would have been more elegant.
>
> But I cannot reverse this replacement with XSLT since the replacement
> characters would be illegal in XSLT as well.
>
> So my only hope is that the <marc> conversion can/will handle this.
> Is there any chance to provide a new inputformat like so:
> <marc inputformat="solrmarc" outputformat="marcxml" outputcharset="utf-8"/>
In the conversion from solrmarc to marcxml there wouldn't be any illegal 
characters.

But the stylesheet to convert from solrmarc to marcxml would be a hairy 
XSL transform indeed.

Given such a stylesheet you'd use something like this to offer marcxml:

          <retrieval syntax="xml" name="marcxml">
                 <backend syntax="xml">
                    <xslt stylesheet="solrmarc2marcxml.xsl"/>
                </backend>
         </retrieval>

No iso2709 magic here, except in the stylesheet, because solrmarc is 
using the iso2709 structure.

You could use record_transform to also offer marc21/usmarc in a marc 
step (taking marcxml as input).

/ Adam
>
> It could be almost the same as inputformat="marc", with just the
> mentioned three replacements added.
>
> It wouldn't be a "private enhancement" just for me. Everyone using
> Vufind or Blacklight could use it to have a lossless MARC record. For
> more info see
> https://code.google.com/p/solrmarc/
>
> Any chance? Or are there better options?
> -Michael
>
> <str name="fullrecord">01171nam a2200229
> cb4500001001200000005001700012008004100029035002700070035002100097040001900118049001000137245021400147260001600361300001100377490008500388490011600473650005000589689004800639689001100687830010600698830013700804#30;BV009747070#30;19940809
>         #30;940805s1994             |||| 00||| undod#30;
> #31;a(DE-599)BVBBV009747070#30;  #31;a(OCoLC)231623563#30;
> #31;aDE-604#31;erakddb#30;  #31;aDE-12#30;10#31;aHealth aspects of
> chemical accidents#31;bguidance of chemical accident awareness,
> preparedness and response for health professionals and emergency
> responders#31;cOrganiation for Economic Co-Operation and Development#30;
>   #31;aParis#31;c1994#30;  #31;a147 S.#30;1 #31;aIndustry and Environment
> Programme Activity Centre: Technical report series #31;v19#30;1
> #31;aOrganisation for Economic Co-operation and Development: Environment
> monographs*OECD environment monographs
> #31;v81#30;07#31;0(DE-588)4280172-2#31;aChemikalienvergiftung#31;2gnd#30;00#31;0(DE-588)4280172-2#31;Ds#31;aChemikalienvergiftung#30;0
> #31;5DE-604#30; 0#31;aIndustry and Environment Programme Activity
> Centre#31;pTechnical report series #31;v19#31;w(DE-604)BV008284255#30;
> 0#31;aOrganisation for Economic Co-operation and
> Development#31;pEnvironment monographs*OECD environment monographs
> #31;v81#31;w(DE-604)BV006667855#30;#29;</str>
>
> _______________________________________________
> Yazlist mailing list
> Yazlist at lists.indexdata.dk
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
>




More information about the Yazlist mailing list