A standard rule of Dublin Core is that all its elements are repeatable and optional. (Also they can be in any order.)
But there are at least two instances in (Australian) repositories where this is not the case in practice:
1. Only one date
The Australasian Digital Thesis Program requires only one dc:date field in the thesis records it harvests from repositories. This means repositories need to be careful in how they format their date values where there are multiple dates associated with an ADT thesis.
What might be a good idea is if ADT either adopts a specialist ADT thesis schema for its needs or establishes common data and Sets policies within the different repository solutions. This could be done in consultation with the stakeholders in the major open source and other repository solutions. But it could well be done. It is likely to have the support of many repository managers who will not then be constrained in their normal use of metadata values and DC by a “special case” such as ADT theses.
2. Only one type
The other case where a DC field is not repeatable is at the moment of depositing a record into a repository. It is generally assigned a single resource or genre dc:type value. The selection of this value in most cases prompts a metadata form template appropriate for that type. The general need for encouraging self-submission (or at least non-specialist submission) is one good reason some repositories have been designed this way.
The open source DSpace repository is an exception. It does not require a single type selection to drive the appropriate template, but it does only accept a single type option from a drop-down list. There is a good preservation argument for this being a good idea in DSpace. Given DSpace’s Collection and Community structure, a record can only go in one place at one time, and any other manifestations of that record in other places will only be really shortcut links to the one place where the record is initially based. So if a record could be put in both a Thesis collection and a Journal Article collection (e.g. a component of a Thesis by publication), then come time for migration of data there will be major difficulties in maintaining the integrity of the data.
To avoid this problem it is possible to deposit the same record multiple times, once for each resource type. Can anyone imagine more volunteers than fingers on a foot for that solution?
Policies and technologies
These two exceptions to the use of multiple DC fields are really policy based exceptions, and not technical exceptions. It is still possible to break the policies and multiply the date and type fields in both cases — at least if the software configuration of your particular repository allows you to.
Which is fine since repositories need to work with multiple policies. In the proprietary VITAL repository, for example, one can add a second dc:type field to create a special Set for the harvesting of ADT theses. Another repository might use another field as the base for pulling out their ADT theses.