Title: Message Title
|
|
|
|
Hi Tim, et al:
I like the idea of 'foregrounding' dc.date.issued, to avoid inadvertent mis-assignment.
But I'm a little confused about your point #2 (incorrect dc.date.issued). How do you know it's incorrect if it agrees with accession date? Remember that the submission UI was designed for 'grey lit' (i.e. not previously published) from an institution. In this case, *issuing* was regarded as the date it appears in the repository, and it *should* agree with the accession date. It is only prima facie wrong if it was a published article. So how can we distinguish these cases?
I have no idea how we would would quantify across our repositories what percentage is published content, but my guess is that it is a small percentage. So if we 'fix' all these across the board (i.e remove dc.date.issued?), we have maybe hurt more than helped.
I can certainly see doing 'surgical' corrections (e.g. if there is a DOI, then correct it, since it must have been published), but I'm at a loss as to how to tackle it generally....
Richard
|
|
|
|
|
|
|
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 a...
|
|
|
|
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
