[
https://jira.duraspace.org/browse/DS-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27665#comment-27665
]
Richard Rodgers commented on DS-1481:
-------------------------------------
While I agree that this is a problem we need to work on - I'm less sure that
suppressing the date.issued assignment is the best solution.
The bedrock use-case for DSpace was not published articles, but 'grey lit'
(born digital content from an institution that was *not* in the official
scholarly record): for this sort of content, appearance in the IR essentially
*is* the equivalent of publication. As a convenience, that use-case was cooked
into the InstallItem logic - otherwise submitters would have to manually (and
needlessly) enter a date issued to when they were submitting the content.
If there *was* a publication date, the assumption was that it would be assigned
to date.issued, in which case it would be left alone by InstallItem.
The real problem is that the date issued is not being captured/cataloged for
articles, and in that case it get incorrectly assigned.
There are various ways to attack this, but it may need a bit more analysis and
discussion.....
My 2 cents,
Richard
> "dc.date.issued" is often incorrectly set (reported from Google)
> ----------------------------------------------------------------
>
> Key: DS-1481
> URL: https://jira.duraspace.org/browse/DS-1481
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.7.0, 1.7.1, 1.7.2, 1.8.0, 1.8.1, 1.8.2, 3.0, 3.1
> Reporter: Tim Donohue
> Fix For: 4.0
>
>
> Google (Anurag Acharya and Darcy Darpa) has contacted DuraSpace about a
> common indexing issue affecting all DSpace sites.
> When Google & Google Scholar index DSpace content (from a variety of
> institutions), the "dc.date.issued" value is incorrect the majority of the
> time. The reason is that, if unspecified, DSpace sets this issued date to the
> *date of accession* (i.e. date that it was submitted to DSpace), see:
> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/InstallItem.java#L130
> Google says this causes their crawlers (for both Google & Google Scholar) to
> assume that the date of accession is actually the formal publication date.
> Rather than defaulting the 'dc.date.issued' to the accession date, Google
> recommends we leave it blank. DSpace is already tracking the accession date
> separately (in 'dc.date.accessioned'), so it seems odd to set
> 'dc.date.issued' to the same value by default.
> Google will be sending along some examples of this. They said they have seen
> repositories, where 30-50% of their items all have the same "dc.date.issued",
> as those items were all imported on the same date.
> This seems like a very reasonable recommendation to me as well. I'm not sure
> we should be setting 'dc.date.issued' by default, as it really is meant to be
> the date of *formal publication*, and not the date that something is made
> available on the web.
> This also seems like a small fix (remove a few lines from InstallItem).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
