Hello Alexander,
> Currently, bfe_authors.py uses
>
> authors = []
> authors_1 = bfo.fields('100__')
> authors_2 = bfo.fields('700__')
>
> This enforces authors to be considered only if both indicators are
> blank. However, you may notice that from the authoritative definition at
>
> http://www.loc.gov/marc/bibliographic/bd100.html
this is an example of the default values of Invenio not being Marc21
compliant. I've complained about this a few times, and I should have
filled a task about those defaults, and sent a few patches, although I
haven't yet ;-(.
The problem of the default values not being correct has those
consequences: if you import records from another catalog, those values
mishave in Invenio. Librarians (and library-educated computer people)
expect those records to behave like in the other system. So it is
interoperability and economy.
The problem arises not only in those Python bibformat snippets, but also
in bibindex definition, and all export formats. For example, my
bfe_author.py has those fields:
if (authors_type in ['','personal']):
authors.extend(bfo.fields('100%%'))
if (authors_type in ['','corporate']):
authors.extend(bfo.fields('110%%'))
if (authors_type in ['','meeting']):
authors.extend(bfo.fields('111%%'))
if (authors_type in ['','personal']):
authors.extend(bfo.fields('700%%'))
if (authors_type in ['','corporate']):
authors.extend(bfo.fields('710%%'))
if (authors_type in ['','meeting']):
authors.extend(bfo.fields('711%%'))
if (authors_type in ['','personal','corporate','meeting']):
authors.extend(bfo.fields('720%%'))
(In my case I have the need of show sometimes personal or corporate
authors, depending of the collection; I understand that it is not always
the case).
In bibindex (/admin/bibindex/bibindexadmin.py/field), you have also to
add those fields:
author 100%, 110%, 111%, 700%, 710%, 711%, 720%
In the Marcxml to DC xls xls as well:
<xsl:for-each select="datafield[(@tag=100 or @tag=110 or @tag=111)]">
<dc:creator>
<xsl:call-template name="subfieldSelect">
<xsl:with-param name="codes">ab</xsl:with-param>
</xsl:call-template>
</dc:creator>
</xsl:for-each>
<xsl:for-each select="datafield[(@tag=700 or @tag=710 or @tag=711 or
@tag=720)]">
<dc:contributor>
<xsl:call-template name="subfieldSelect">
<xsl:with-param name="codes">ab</xsl:with-param>
</xsl:call-template>
</dc:contributor>
</xsl:for-each>
I borrowed the following xsl function from somewhere (LC, I think):
<!--- Added FJ 5-feb-2010 to resolve template -->
<xsl:template name="subfieldSelect">
<xsl:param name="codes">abcdefghijklmnopqrstuvwxyz</xsl:param>
<xsl:param name="delimeter">
<xsl:text> </xsl:text>
</xsl:param>
<xsl:variable name="str">
<xsl:for-each select="subfield">
<xsl:if test="contains($codes, @code)">
<xsl:value-of select="text()"/>
<xsl:value-of select="$delimeter"/>
</xsl:if>
</xsl:for-each>
</xsl:variable>
<xsl:value-of
select="substring($str,1,string-length($str)-string-length($delimeter))"/>
</xsl:template>
And so on. It is a major task, but much needed. Newcomers are likely
to feel frustated due to the system not behaving as espected.
Ferran
