Question about dc.date.accessioned and dc.date. available

[Xiping Liu]

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

[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

--
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 dspace-tech...@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
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

[Christian Scheible]

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

-- 
Christian Scheible
Softwareentwickler / Abt. Content-basierte Dienste
Kommunikations-, Informations-, Medienzentrum (KIM)
Universität Konstanz
78457 Konstanz
+49 (0)7531 / 88-2857
Raum B 703

[Xiping Liu]

Hi Christian and Tim, 

Thank you for your replies. 

I don't think we have used embargo on our ETDs, although we will test on it to see if it will make a difference for these two fields. We can test on using an approval system too. 

I have found out that some of the older ETDs have these duplicate fields but not the newer ones. So maybe with the newer version of DSpace the bug has been fixed? As long as we know it's not something that we did that created these duplicate information, the only thing we need to do now is to clean them up. 

Thanks again.

Xiping 

[Luiz dos Santos]

Hi,

   I have seen some dc.date.available and dc.date.accessioned when the items were harvested, and I do have a workflow where the dc.date.available is one of the fields available through the repository workflow.

Best regards

Luiz

[Nada Abo-Eita]

Hi Xiping,

In our DSpace instance we have approval/rejection workflow and the accession date is initialized only when a handle assigned to the item ( when item approved )

[Tim Donohue]

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

[Ben Heartland]

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 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.