[
https://jira.duraspace.org/browse/DS-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27671#comment-27671
]
Richard Rodgers commented on DS-1481:
-------------------------------------
Hi Tim:
I completely agree that the assumption is in general a perilous/wrong one - all
I meant was that by simply removing it (i.e just pulling the logic from
InstallItem) - you would be creating a significant burden for the IR. For us
maybe 3-5 percent of our content is published articles. So that would mean for
95-97% of new content, we would have to manually catalog the date.issued field
per submission, a big hit. And it's even worse than that, since a lot of our
stuff comes in *not* through the web submission, but ItemImport, etc. I guess
we would have to write scripts that dynamically inject the run-time date into
Simple Archive Format XML trees, etc, or rewrite ItemImport to do the same.
And unfortunately (for us at least), the ingest mode (web UI, vs SWORD vs LNI)
doesn't line up nicely with whether to auto-assign date.issued or not.
We tend to put a lot of institutional content (= where we want date.issued to
just reflect the accession date) through ItemImport, and use the UI for our OA
collection (which *is* published journal stuff - but where we dutifully record
the publication date as date.issued). And we use SWORD for both internal use,
and external partners, etc For us, maybe a collection-based rule (with a
default), would work, but I'm not sure about other IRs.
I'm all for eradicating hard-coded assumptions, but the result shouldn't be a
loss in usability/efficiency. I'll try to brainstorm on this as well....
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
