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 On Fri, May 27, 2016 at 6:22 PM, Xiping Liu <xipi...@gmail.com> wrote: > 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 > > > On Friday, May 27, 2016 at 1:42:35 AM UTC-5, 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 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 >> >> -- >> 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. >> >> >> >> -- >> Christian Scheible >> Softwareentwickler / Abt. Content-basierte Dienste >> Kommunikations-, Informations-, Medienzentrum (KIM) >> Universität Konstanz >> 78457 Konstanz+49 (0)7531 / 88-2857 >> 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 dspace-tech+unsubscr...@googlegroups.com. > To post to this group, send email to dspace-tech@googlegroups.com. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
