Dates:
Use of a date or dates to express a chronological ordering of versions is a very useful tool in version identification.
However, which date to use in what context? There are a lot of potential dates, all valid in different contexts or for different object types, but potentially confusing if they are not consistently applied.
Qualified Dublin Core offers the following choice of dates (http://dublincore.org/documents/dcmi-terms):
- available - date (often a range) that the object became or will become available
- created - creation date of resource
- dateAccepted - date of acceptance of an object
- dateCopyrighted - date of copyright
- dateSubmitted - date of submission of an object
- issued - date of formal issuance (e.g. publication) of the resource
- modified - date on which an object has changed
- valid - date (often a range) of validity of a resource
Other dates relevant to the management of objects in repositories include:
- Deposit - date deposited into the repository
- Annotated - date annotated comments made to object for whatever reason - this could include by the repository staff.
Pros:
- Using dates is one of the most obvious, simple and potentially effective ways of identifying a version. If someone is looking for the last available version, then a date is really the only information they might need.
- As long as it is clear which date is being used, a date can be put in a number of different locations. This could be in the metadata, on a coversheet, in the filename or in a watermark.
- It is an applicable solution across any kind of digital object.
- Using dates was supported by VIF research survey respondents.
Cons:
- Ambiguity is easily introduced if the meaning or the context it is introduced in is unclear.
- Research is a dynamic process and therefore does not always fit a straight forward time-based chronology. It is not always clear which pieces of research do fit into a linear timeline and which do not.
- Someone looking for the last available version might still end up with the wrong version if they misinterpret the date they are looking at. For example an academic moving institution might deposit all his or her material on the same date, leaving this date meaningless.
- Some simple metadata schemes, such as Unqualified Dublin Core, only allow for a 'Date' field without further description as to which date should be used.
Recommendations:
- It is essential to be clear about which date has been used and if applicable, why.
- If there is ever only one option for a date, then it is critical that you find a way to make it clear which date you are referring to. You should agree on what the most relevant to your repository is, apply it consistently and provide information to users about it.
- VIF recommends is that if you only use one date, it should be Date Modified (by the author, not the repository) and wherever possible, this should be accompanied by a description of who made the changes and why.
- A key thing to remember when considering which date to use to enhance version identification, is that it should relate to the object at hand, not to the repository or to an understanding of the workflow.
- VIF also strongly recommends avoiding the use of unexplained dates, as these are very open to misinterpretation.
Notes:
The use of rich metadata helps significantly and applying Dublin Core application profiles for harvesting will also provide better versioning information.
Coversheets allow excellent space for proper descriptors as well as additional information such as who added the date or made the change; an author or content creator's change might be more pertinent than a change by a repository manager, who is unlikely to be changing meaning of the version, rather, just flagging further information about the object.
If you take a repository decision to apply a filenaming convention, or watermarking convention, then VIF recommends you write a policy about what dates are used and when, and then publicise this convention so that it is easily understood.