In order to specify one of these ... an xsi:type attribute must be used in the instance document.
<dc:creator xsi:type="dc:Agent" scheme="overheid:Gemeente">Antwerpen</dc:creator>
This is OK, both from a schema point of view and from the semantics of this dublin core element.
But look at the following examples. They are OK schemawise, but do they make sense?
<dc:creator xsi:type="dc:Spatial" scheme="overheid:Postcode">3000</dc:creator>
The next example is showing the opposite; it is NOT correct schemawise since xsd:date is not a validly derived datatype from 'SimpleLiteral', but semantically it makes sense:
The solution would be that we can constrain the allowed types on xsi:type, BUT we can't. See also the note included in the dcterms schema.
Also, note that one shortcoming of this approach is that any type can be
applied to any of the elements or refinements. There is no convenient way
to restrict types to specific elements using this approach.
This whole approach can only work if the content creator knows and the type system and which type to use on which element.
It's our opinion that this is too much asked for. It is the schema designer who needs to be in charge of datatyping, not the content creator.
Other remarks related to xsi:type:
<dc:creator type="Agent" scheme="overheid:Gemeente">Antwerpen</dc:creator>
where the schema constraints the value of attribute type on element creator to "Agent", followed by the trick learned from Michael Kay
... to add the xsi:type attribute using a SAX filter; you then pipe your original source into the schema validator via the filter. Quite a few of the limitations of XML Schema 1.0 can be overcome by validating not the original document, but a simple transformation of it.
However I still do not find this satisfying for a solution that is not centralized and needs to work in standard XML editing environments.