I'm surprised to see this issue not getting more attention, as dates of submission, accession and embargo lifting are key to Open Access compliance reporting. I spent quite a bit of time in the run-up to UK REF 2021 submission trying to get clarity on what these two fields mean, so thought I'd share my findings here:
Going back to *DSpace 1.0*, both dc.date.accessioned and dc.date.available are both set as the item is installed in the live archive: https://github.com/DSpace/DSpace/blob/dspace-1_0/dspace/src/org/dspace/content/InstallItem.java#L91 // create accession date DCDate now = DCDate.getCurrent(); item.addDC("date", "accessioned", null, now.toString()); item.addDC("date", "available", null, now.toString()); With the introduction of embargos in *DSpace 1.6*, dc.date.accessioned retains its original meaning of "date the item was installed in the live archive", while dc.date.available becomes the first date that the item is not under embargo: https://github.com/DSpace/DSpace/blob/dspace-1.6.0/dspace-api/src/main/java/org/dspace/content/InstallItem.java#L94 DCDate liftDate = EmbargoManager.getEmbargoDate(c, item); // create accession date DCDate now = DCDate.getCurrent(); item.addDC("date", "accessioned", null, now.toString()); // add date available if not under embargo, otherwise it will // be set when the embargo is lifted. if (liftDate == null) item.addDC("date", "available", null, now.toString()); Note that this uses the EmbargoManager.getEmbargoDate() method to get the embargo lift date (if any), which relies on the use of the old, pre-3.x embargo system that sets embargos via the metadata fields defined by the *embargo.field.terms* and *embargo.field.lift* config settings. As of DSpace 1.6, the main issue with these two fields is vague or misleading documentation: - dc.date.accessioned "Date DSpace takes possession of item." -- "takes possession" is vague and easily misinterpreted - dc.date.available "Date or date range item became available to the public." -- dc.date.available is now the date on which the *bitstreams* (i.e. files) are publicly accessible, not the item itself. Fast forward to *DSpace 7.0* and dc.date.accessioned still has its original function: https://github.com/DSpace/DSpace/blob/dspace-7.0/dspace-api/src/main/java/org/dspace/content/InstallItemServiceImpl.java#L140 // create accession date DCDate now = DCDate.getCurrent(); itemService.addMetadata(c, item, MetadataSchemaEnum.DC.getName(), "date", "accessioned", null, now.toString()); The code comments indicate that dc.date.available is still intended to indicate the first date that the files were not under embargo: https://github.com/DSpace/DSpace/blob/dspace-7.0/dspace-api/src/main/java/org/dspace/content/InstallItemServiceImpl.java#L145 // add date available if not under embargo, otherwise it will // be set when the embargo is lifted. // this will flush out fatal embargo metadata // problems before we set inArchive. if (embargoService.getEmbargoTermsAsDate(c, item) == null) { itemService.addMetadata(c, item, MetadataSchemaEnum.DC.getName(), "date", "available", null, now.toString()); } However, this is not the case. The EmbargoManager.getEmbargoDate() method has been superseded by embargoService.getEmbargoTermsAsDate() but this new method still assumes that the old embargo system is being used, despite it being optional since version 3.0. If the the old system is not used for item, embargoService.getEmbargoTermsAsDate(c, item) always returns null, meaning that dc.date.available is set whether an embargo is in place or not. The current DSpace 7.x documentation <https://wiki.lyrasis.org/display/DSDOC7x/Metadata+and+Bitstream+Format+Registries> still has the same descriptions for the two fields as DSpace 1.6. For dc.date.accessioned, clearly documenting it as "Date the item was first installed in the live archive" would solve the issue, since this has been its function consistently since version 1.0. dc.date.available probably needs some discussion as to how (and if) it should be used in future. Since the bug makes its meaning unclear, historical values aren't reliable (for any given item, it may record either the accession date or the embargo lift date, depending on the embargo system used for that item at the time it was installed in the live archive). In any case, it seems like some documentation of the current situation could avoid a lot of confusion. On Tuesday, 31 May 2016 at 16:38:08 UTC+1 Tim Donohue wrote: > Hi Christian, > > Thanks for correcting me. You are correct, and it seems I'm incorrect > here. The code most clearly shows that dc.date.accessioned and > dc.date.available will be identical (or nearly identical) unless you are > using the Old (pre-3.x) Embargo system. > > Now that I look a bit closer, I think this is a bug, and we may wish to > correct this behavior. So, I've logged an issue: > > https://jira.duraspace.org/browse/DS-3228 > > If others have thoughts on how these fields *should* be used, I'd > recommend adding comments to this ticket. Hopefully we can then work to > find a volunteer to help patch this issue for a future DSpace release. > > Thanks, > > Tim > > On 5/27/2016 1:42 AM, Christian Scheible wrote: > > Hi Xiping, Hi Tim, > > actually dc.date.available and dc.date.accessioned only differ if: > > 1. The old embargo system is used > 2. An embargo is set on an item. > > Otherwise, the both dates are the same (except for maybe a millisecond). > > See: > *org.dspace.content.InstallItem.installItem(Context, InProgressSubmission, > String) *which calls: > > *org.dspace.content.InstallItem.populateMetadata(Context, Item) *where > the two dates are set. > > If you have two dc.date.accessioned for the same item only differing in a > millisecond than this seems to be a bug in your DSpace instance. > (like installItem is called twice) but not sure where this comes from. > > I just wanted to clarify the meaning of the dates because we had the same > impression for the meaning of dc.date.accessioned and dc.date.available as > Tim until we found that piece of code in InstallItem.java. > > Best regards > Christian > > Am 26.05.2016 um 21:47 schrieb Tim Donohue: > > Hi Xiping, > > The dates serve slightly different purposes: > > * dc.date.accessioned = the date/time that DSpace received this document > (i.e. date/time the item was created in DSpace) > * dc.date.available = the date/time that the item was made *available* > through the DSpace web interface. > > If you are not using approval workflows, then dc.date.available will > always be the same as dc.date.accessioned. > > However, if an item undergoes an approval process, then > dc.date.accessioned will be the date that the approval *began* (i.e. when > the item was created) and dc.date.available will be the date that the > approval *completed* (i.e. when the item was fully approved and made > available to users). > > Tim > On 5/26/2016 1:44 PM, Xiping Liu wrote: > > Hello all, > > We are in the process of cleaning up our ETD metadata and we came across > something very interesting: > > Some of our ETD records have two dc.date.accessioned and dc.date.available > fields and they are very close to each other. For example: > > dc.date.accessioned 2012-01-10T15:05:49Z > dc.date.accessioned 2012-01-10T15:05:50Z > > dc.date.available 2012-01-10T15:05:49Z > dc.date.available 2012-01-10T15:05:50Z > My understanding is that every time DSpace accepts a new submission it > gives a time stamp on it. So how come it has two almost duplicate fields. > > Thank you. > > Xiping > -- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > > > -- > Tim Donohue > Technical Lead for DSpace & DSpaceDirect > DuraSpace.org | DSpace.org | DSpaceDirect.org > > -- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > > > > -- > Christian Scheible > Softwareentwickler / Abt. Content-basierte Dienste > Kommunikations-, Informations-, Medienzentrum (KIM) > Universität Konstanz > 78457 Konstanz+49 (0)7531 / 88-2857 <+49%207531%20882857> > Raum B 703 > > -- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > > > -- > Tim Donohue > Technical Lead for DSpace & DSpaceDirect > DuraSpace.org | DSpace.org | DSpaceDirect.org > > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/5d62958b-e0dd-4cd6-a1cf-41a033f956b8n%40googlegroups.com.
