I seem to have found another dependency, in that the OAIDCCrosswalk
class that's used by the OAI-PMH interface exposes the
contributor.author field as a creator element. This isn't necessary if
we're using dc.creator in DSpace.
It looks easy enough to change this class so that the contributor.author
field in DSpace is exposed in the OAI-PMH interface as a contributor
element, and then redeploy the changed class where it is needed. I'm
wondering if this is an okay approach, or if it would be better to
create a new class with the differing functionality, and then configure
the oai webapp to use the new class?
Dorothea Salo wrote:
I'd like to change an installation to require dc.creator rather than
dc.contributor.author in the input form, and to configure it to build
the author search index on dc.creator rather than dc.contributor.author.
Not too difficult. Change index-forms.xml accordingly, and one SQL
query in the metadatavalues table in the database should do the trick
for existing items.
Also, is it true that an upcoming version of DSpace will allow the
author browse to use an index based on both the creator and the
contributor elements?
This brings up an interesting detail about Manakin. When determining
authors for items that come up in title or subject browse listings,
the algorithm is: when there's a dc.contributor.author, use that; if
not, use dc.author; if neither of those, use whatever dc.contributor
there is. The FIXME comment I left in my utility stylesheet reads
thus:
FIXME: This template should pull out dc.contributor.author and
dc.creator, then make a list of all of them... Should probably have
better way to cope with other dc.contributor as well. The trick is
that some dc.contribs feel author-y (composers, maybe editors) and
others don't (e.g. translators, advisors). Three Minute Hate on Dublin
Core. -DS
I haven't in fact tried to fix this yet, but it shouldn't be
impossible; the tricky bit for me is figuring out how to make XSLT
union dc.contributor.author (and maybe one or two other
dc.contributor.X) with dc.creator.
For item metadata listings, the same union trick would come into play.
The nice thing is that it's not hard to add lines for additional
metadata. Here's mine for dealing with thesis advisors (note that I'm
not using Manakin's table markup and have added author linking):
xsl:if
test=$data/dim:[EMAIL PROTECTED]'contributor'[EMAIL PROTECTED]'advisor']
dt
i18n:textxmlui.dri2xhtml-METS-1.0.advisor/i18n:text
/dt
dd
xsl:for-each
select=$data/dim:[EMAIL PROTECTED]'contributor'[EMAIL PROTECTED]'advisor']
a
xsl:attribute name=href
xsl:value-of
select=concat($context-path,'/browse-author-items?author=')/
xsl:copy-of select=text()/
/xsl:attribute
xsl:copy-of select=text()/
/a
xsl:if
test=count(following-sibling::dim:[EMAIL PROTECTED]'contributor'[EMAIL
PROTECTED]'advisor'])
!= 0
xsl:text; /xsl:text
/xsl:if
/xsl:for-each
/dd
/xsl:if
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
