Marc Export from dlr/EDIT

Project:RUcore dlr/EDIT
Category:bug report
Status:Moved to JIRA

Notes about supplementary files should not map here. Map to 500, but need to review how values would display. See examples



Title:Marc Export from Fedora» Marc Export from Fedora - Notes


Version:5.0» 5.2


Title:Marc Export from Fedora - Notes» Marc Export from dlr/EDIT
Assigned to:Anonymous» triggs

Marc Export enhancement requirements are posted online. Please refer to it when implementing this.


887 mapping does not conform to marc standard. I am uploading two documents. One shows how it is currently being exported, and the other document shows how it should be exported per marc standard.


The Library of Congress script uses this for mods:extension:

<xsl:template match="mods:extension">
<xsl:call-template name="datafield">
<xsl:with-param name="tag">887</xsl:with-param>
<xsl:with-param name="subfields">
<marc:subfield code="a">
<xsl:value-of select="."/>

It doesn't do anything for $2. I'm not sure I see what else it might be missing. I hesitate to change their spec though.


Select collection "data" (third one from the pick list), select "Export All New Objects". Test Marc Export for this collection shows three objects.

1: rutgers-lib:25398, /fedora30/data/objects/2010/0506/13/37/rutgers-lib_25398, :rucore00000000090:
Object has already had a MARC record created... <------------ This is confusing.
Object has not yet had a MARC record export... <------------ This is confusing.
Checking MARC Export...
A MARC record for this object has not yet been exported
The most recent MODS record for this object is dated 2010-05-17T21:40:54.467Z

I expect to see only the objects that don't have a Marc Export event in digiProv.


Assigned to:triggs» rmarker


Please see Jeffery's comment. Descriptive Events in Mods are not mapping correctly. We can ask Bob to delete 887 before loading.



.008. |110311s |||| 000 0|||| d

008 does not conform to marc standard. Move indicated '|' 3 spaces to the right.


These three are "new" and don't have an exported record with a digiprov. They have been run through the initial test, so the MARC record has been "created", but the export marc has not been triggered, so they do not have digiprov records. You can see the difference in a collection like the grad school, where a good portion of what we have on lefty64 have exported record, but many other do not. If you toggle "Export All" to "Export All New" the set of objects will change accordingly.


Status:active» fixed

I think this is fixed, though there may be some cached examples with the bad code. Test it by trying a new object.


Status:fixed» test


Assigned to:rmarker» ananthan


Version:5.2» 7-x


Status:test» active

I just looked at rutgers-lib:39267 that was exported recently and the spaces are still not correct. It seems there is only one space after ".008."


I seem to remember being told we needed only one space. In any event, we currently have:
&lt;xsl:for-each select="//marc:controlfield"&gt;
.&lt;xsl:value-of select="@tag"/&gt;.&lt;xsl:text&gt;_|&lt;/xsl:text&gt;&lt;xsl:value-of select="."/&gt;

we could change to:
&lt;xsl:for-each select="//marc:controlfield"&gt;
.&lt;xsl:value-of select="@tag"/&gt;.&lt;xsl:text&gt;____|&lt;/xsl:text&gt;&lt;xsl:value-of select="."/&gt;
Note I'm using underscores to show what would be spaces on this page. I would want to consult closely with somebody like Rhonda on a thing like this.


I would have to defer to Kalaivani on this one, as the question has less to do with the MARCXML schema, and everything to do with the MARC export script. The 008 field has 40 character positions. There are no indicators that are defined for this field. The first six bytes are for the data entered on file, in the pattern yymmdd. If the spacing pattern in the MARC export script reserves bytes for indicators or subfields, then it should be applied to this field, too.

We have been able to successfully export MARC records since last June, so has this been fixed?


Bob's script was fixing some of the issues outlined here but I'll check with him and update this entry.


Version:7-x» 8.x

Please update status when time permits.


Status:active» Moved to JIRA

Back to top