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:text>xmlui.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/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
