Hi Chris, not a full answer, but hopefully this helps:
example item: http://demo.dspace.org/xmlui/handle/10673/43?show=full *dc.date.accessioned and dc.date.available *are set by DSpace automatically, at the point when the item exits the workflow and becomes a "live"/archived item in the repository. Wouldn't recommend to fill them out manually or to edit them. Features like RSS feeds, Recently submitted items on the frontpage and possibly also OAI rely on the contents of these dates. *dc.date.issued *is the most commonly used field for a "publication" date. For content that doesn't exist elsewhere, dc.date.issued can coincide with dc.date.available. But very often, the date of publication in another medium, website, or journal is used there. The submission form user interface date format allows: YYYY YYYY-MM YYYY-MM-DD But I'm pretty sure (not tested though!) that if you would fill it out with a timestamp, like 2018-01-07T08:55:55Z, it would work as well. You generally don't want to fill it out with "circa YYYY", or "195X" The main areas that you are risking to break are the Browse by Issue Date pages, cfr http://demo.dspace.org/xmlui/browse?type=dateissued Or you may have items not showing up in your Discovery date facets. (see screenshot) If you want to describe historical coverage of the images, I would recommend to store this information as text, in the dc.coverage.temporal field or dcterms.coverage. cfr https://wiki.lyrasis.org/display/DSDOC6x/Metadata+and+Bitstream+Format+Registries with kindest regards, Bram [image: logo] Bram Luyten 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586 Gaston Geenslaan 14, 3001 Leuven, Belgium DSpace Express Hosting <https://www.atmire.com/dspace-express?utm_source=emailfooter&utm_medium=email&utm_campaign=braml> - Open Repository Hosting <https://www.atmire.com/open-repository?utm_source=emailfooter&utm_medium=email&utm_campaign=braml> - Custom DSpace Services <https://www.atmire.com/custom-dspace?utm_source=emailfooter&utm_medium=email&utm_campaign=braml> On Sat, 27 Jun 2020 at 17:26, Chris Clawson <[email protected]> wrote: > My project is a mostly a historic repository of images from my home area. > In some cases, we know the exact date a picture was taken. In the worst > case, a date would only be a guess made from a historian ("circa 1895"). > Of course, many other date related fields are defined. There are > international standards and guidelines issued from Google and others. > > We wish to identify and curate everything added. How shall we deal with > imperfect information, and keep compatible with established guidelines? In > DSpace, where, when and how are the 'date' metadata fields important in > this case? > > -- > All messages to this mailing list should adhere to the DuraSpace Code of > Conduct: https://duraspace.org/about/policies/code-of-conduct/ > --- > You received this message because you are subscribed to the Google Groups > "DSpace Community" 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-community/2599252f-fa1b-40fe-b8e5-56ceb4d3df15o%40googlegroups.com > <https://groups.google.com/d/msgid/dspace-community/2599252f-fa1b-40fe-b8e5-56ceb4d3df15o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Community" 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-community/CACwo3X25-jfCdEY%2BmAUBrRW_H%2BLVh%2BMSNQo1DbE04-e1mu%2BPOw%40mail.gmail.com.
