[
https://jira.duraspace.org/browse/DS-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27667#comment-27667
]
Tim Donohue commented on DS-1481:
---------------------------------
Hi Richard,
I definitely understand why that auto-assign "dc.date.issued" logic was
initially "cooked into" DSpace for grey literature and similar.
However, I think that part of the issue is that this logic may be embedded too
deeply in DSpace, and DSpace has changed so much over the years. It almost
needs to be more evident that DSpace is going to auto-assign a "date.issued" if
you don't enter one, or say the item is unpublished.
If you think about it... items that come in via bulk ingest, SWORD, LNI (or
even a REST API) are all getting their "dc.date.issued" automatically set to
the date of ingest, if it happens to be missing from the import package. So,
the problem is really that DSpace is making a big assumption that:
a missing "dc.date.issued" = the item is grey lit / unpublished
When it fact, it now could just mean that the import package accidentally
didn't include it (for whatever reason -- maybe it was miscoded or just
unknown), or whoever ingested the item didn't fill it out.
Obviously, we'll never be able to achieve 100% accuracy here. I'm just pointing
out that I'm not sure we can assume any longer that a missing "dc.date.issued"
means that the associated files are grey lit / unpublished.
There may be an in-between resolution here: Maybe the UI needs to make the
choice more evident as to whether the "issued" date is set to 'today' or not,
and maybe all other formats of import (SWORD and the like) should just leave
the "issued" date empty if it's not included. Just a brainstorm.
> "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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
