2

Current state

DSpace XMLUI (Mirage, Mirage 2 themes with "metadata" focus) by default shows items in search result listings as follows:

  1. When the search term was found in the title/author/publisher metadata, the item is shown as in "recently added" lists (including the first part of the abstract).
  2. When the search term was found in the abstract, the abstract snippet shown for the item "shifts" to show the context around where the search term was found.
  3. When the search term was found in extracted fulltext, the abstract snippet is not shown at all. Instead, a snippet of the extracted fulltext is shown to show the context around where the search term was found.

In all three cases, the search terms are bolded.

Issues with this approach

The approach above causes several issues in terms of user experience:

  • The logic above is not made clear to the user; search result listings can be a mix of items with the beginning of the abstract shown, items with a middle portion of the abstract shown, and items with a fulltext snippet shown.
  • The extracted fulltext may include "ugly" special characters and will generally include the filename, file size and other metadata of little relevance to the user.
  • The extracted fulltext may be from a restricted bitstream and the preview snippet may reveal information that is supposed to be confidential (see this DSpace bug).

Desired behaviour

Instead, I would like to always show an abstract snippet for items in search result listings. It's acceptable for the abstract snippet to "shift" to show context of the search term, but this should be made clear to the user. When the search term is found only in the fulltext file, the beginning of the abstract should be shown, alongside a message that a fulltext file belonging to the item contains the search term.

schweerelos
  • 2,189
  • 2
  • 17
  • 25

2 Answers2

2

The abstract/preview snippet part of the search result listing is generated in discovery.xml, for example starting here for the current version of the file in Mirage 2. Customising that "choose" statement as follows will yield the desired result (though it is not robust in terms of i18n):

<xsl:choose>
  <xsl:when test="dri:list[@n=(concat($handle, ':dc.description.abstract'))]/dri:item/dri:hi">
    <!-- 
        search term found in abstract - show context 
        around search term location(s) 
    -->
    <div class="abstract">
      <strong>Search term found in abstract:</strong>
      <xsl:for-each select="dri:list[@n=(concat($handle, ':dc.description.abstract'))]/dri:item">
        <xsl:text>… </xsl:text><xsl:apply-templates select="."/><xsl:text> …</xsl:text>
        <br/>
      </xsl:for-each>
    </div>
  </xsl:when>
  <xsl:when test="dri:list[@n=(concat($handle, ':dc.description.abstract'))]/dri:item">
    <!-- 
         search term not found in abstract but the item has an abstract 
         - show first part of abstract like in recently added lists 
    -->
    <div class="abstract">
      <xsl:value-of select="util:shortenString(dri:list[@n=(concat($handle, ':dc.description.abstract'))]/dri:item, 220, 10)"/>                       
    </div>
  </xsl:when>
</xsl:choose>
<xsl:if test="not(dri:list[@n=(concat($handle, ':dc.description.abstract'))]/dri:item/dri:hi) and dri:list[@n=(concat($handle, ':fulltext'))]">
  <!-- 
      search term not found in abstract but found in fulltext file - 
      show message _instead_ of preview; if there is an abstract 
      then it will already be shown via the choose statement above 
  -->
  <strong>(Search term found in fulltext file)</strong>
</xsl:if>
schweerelos
  • 2,189
  • 2
  • 17
  • 25
  • When I tried to implement the util:shortenString function, I got the following error: `org.apache.xpath.domapi.XPathStylesheetDOM3Exception: Prefix must resolve to a namespace: util` – veeTrain Mar 28 '16 at 18:17
  • I fixed it by adding this to the xsl:stylesheet at the beginning of the file: `xmlns:util="org.dspace.app.xmlui.utils.XSLUtils"` and potentially by also excluding util as a result prefix. – veeTrain Mar 28 '16 at 20:39
0

Thanks schweerelos! By your example we have made the following changes to our discovery.xsl:

First we needed to add an additional item to the stylesheet in order to execute the string shortening:

<xsl:stylesheet
    xmlns:util="org.dspace.app.xmlui.utils.XSLUtils"
    ...
    exclude-result-prefixes="xalan encoder i18n dri util ...">

And then we modified the :fulltext branch to be an otherwise that displays the first 220 characters of the abstract (so long as it is present).

<xsl:choose>
    <xsl:when test="dri:list[@n=(concat($handle, ':dc.description.abstract'))]/dri:item/dri:hi">
        <div class="abstract">
            <xsl:for-each select="dri:list[@n=(concat($handle, ':dc.description.abstract'))]/dri:item">
                <xsl:apply-templates select="."/>
                <xsl:text>...</xsl:text>
                <br/>
            </xsl:for-each>
        </div>
    </xsl:when>

    <xsl:otherwise> <!-- NEW APPROACH STARTS ON THIS LINE -->
        <div class="abstract">
            <xsl:value-of select="util:shortenString(dri:list[@n=(concat($handle, ':dc.description.abstract'))]/dri:item, 220, 10)"/>
        </div>
    </xsl:otherwise>
</xsl:choose>

We found this to be an acceptable trade-off and provides a consistent appearance. You either see the Hit Highlighting where the search term was found (KWIC) on the dc.description.abstract provided on the record or the start of the dc.description.abstract.

And where the abstract's text itself is presently embargoed (or restricted indefinitely) then any search term that would have otherwise shown restricted content in the old presentation just displays 'this item's abstract is restricted...' since the dc.description.abstract field is populated with that text.

The above approach (the <xsl:otherwise> portion) replaced the following content.

REJECTED (as-delivered) APPROACH:

<xsl:when test="dri:list[@n=(concat($handle, ':fulltext'))]">
    <div class="abstract">
        <xsl:for-each select="dri:list[@n=(concat($handle, ':fulltext'))]/dri:item">
        <xsl:apply-templates select="."/>
        <xsl:text>...</xsl:text>
        <br/>
        </xsl:for-each>
    </div>
</xsl:when>

The file was in an unexpected location and if I understood more about how the development process worked I could probably drop this in OUR themes folder but as it stands, it was edited in the dri2xhtml-alt theme. I did not expect the file that impacts this behavior to be found there, but it seems quite clear that it works to change it there.

\DSpaceRepo\dspace-xmlui\src\main\webapp\themes\dri2xhtml-alt\aspect\artifactbrowser\discovery.xsl

One last thing you should know -- if you are editing this file and expecting changes to be clearly apparent to you, you'll need to keep clearing your browser history/cache or executing new searches. The editing process was a little arduous for this reason (not appearing to reflect the latest changes) until I figured out a good workflow.

veeTrain
  • 2,915
  • 2
  • 26
  • 43