[
https://jira.duraspace.org/browse/DS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22871#comment-22871
]
Scott Phillips commented on DS-1055:
------------------------------------
I don't think the bug is in the display code as the patch suggests. Instead
when harvesting an item from DSpace to DSpace the bundles should be preserved.
So you shouldn't need to add a check in the display side to only show those
items on the front end which are in the original bundle according to ORE
because they should already be in the original bundle. The bug has to be in the
harvesting code.
I believe you are under the misconception that the only important data is in
the ORIGINAL bundle. That is not a good assumption. You may create a bundle and
call it "super cool stuff that must be preserved". It can be displayed just
like content on the front end but be separate from the ORIGINAL bundle. Now
DSpace does create derivative file types and store them in separate bundles by
default. This includes the license, thumbnails, extracted text, etc. None of
these items should be thrown away in a DSpace to DSpace harvest. Let's take the
thumbnails for example, they could be hand crafted thumbnails placed in the
thumbnail bundle manually that were NOT generated by standard thumbnail
generator. Same with the extracted text, perhaps on an item the default text
extracted was poor so someone took the time to manually extract the text and
uploaded it DSpace. You wouldn't want to throwaway a hand created thumbnail or
textual translation just because they reside in a separate bundle would you?
> References to bitstreams not from the 'ORIGINAL' bundle are shown in
> harvested items
> ------------------------------------------------------------------------------------
>
> Key: DS-1055
> URL: https://jira.duraspace.org/browse/DS-1055
> Project: DSpace
> Issue Type: Bug
> Components: XMLUI
> Reporter: Àlex Magaz Graça
> Attachments: only-show-ORIGINAL-bitstreams.patch
>
>
> When harvesting a collection with references to bitstreams (ORE) from another
> DSpace instance, all the bitstreams from the source repository are shown
> instead of only the ones in the 'ORIGINAL' bundle. For example, if a
> 'document.pdf' is shown in the item of the source repository, in the
> harvested item 'document.pdf.txt' (THUMBNAIL bundle) and 'license.txt'
> (LICENSE bundle) are also shown. It should look at the <dcterms:description>
> value in the RDFs statements of the corresponding bitstream to filter out the
> other bundles:
> [...]
> <atom:link [...]
> href="https://buleria.unileon.es/xmlui/bitstream/handle/10612/793/1945333.pdf.txt?sequence=4";
> title="1945333.pdf.txt" [...]/>
> [...]
> <rdf:Description
> rdf:about="https://buleria.unileon.es/xmlui/bitstream/handle/10612/793/1945333.pdf.txt?sequence=4";>
> <rdf:type rdf:resource="http://www.dspace.org/objectModel/DSpaceBitstream"/>
> <dcterms:description>TEXT</dcterms:description>
> </rdf:Description>
> [...]
> snippet taken from here:
> https://buleria.unileon.es/oai/request?verb=GetRecord&metadataPrefix=ore&identifier=oai:buleria.unileon.es:10612/793
> I think the code to be fixed is in
> dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/themes/dri2xhtml-alt/aspect/artifactbrowser/ORE.xsl
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
