Dear John
we (Gregor Hagedorn, Bob Morris, Steve Baskauf) realize that the public review period for DarwinCore (DwC) is over, but we believe we need to bring a potentially highly problematic issue to your attention. This issue has been found originally by Steve Baskauf. Essentially, it is an issue that is not very appearant when reading DarwinCore for review, but detected when trying to implement it in combination with other technologies.
Steve describes the problem on: http://www.keytonature.eu/wiki/MRTGv08_Type_term_inconsistent_with_DwC
DarwinCore seems to use dcterms:type in a way that is inconsistent with the DublinCore (DC) recommendations for publication artifacts, which is the way most users of DC are likely to use dcterms:type. Steve pointed out that MRTG's use, which does follow the DC recommendation, is inconsistent with DwC. We believe that this is not a problem of MRTG; the problem equally occurs, e. g., where natural history collections collaborate with the culture and library initative Europeana.eu, which equally uses DublinCore type in the original sense.
DublinCore dcterms:type has an explicit type vocabulary: http://dublincore.org/documents/dcmi-terms/#terms-type whose annotations says: "Recommended best practice is to use a controlled vocabulary such as the DCMI Type Vocabulary [DCMITYPE]." This vocabulary: http://dublincore.org/documents/dcmi-type-vocabulary/ defines values like StillImage, Sound, MovingImage, Text.
In contrast, the DwC type vocabulary acts on an abstract level of recording occurrences that are independent of physical records. These occurrences can then be vouchered by physical resources like specimens, photos, movies, etc. The actual resources treated in DublinCore are therefore only potential vouchers for a DarwinCore resource. The terms recommended for DublinCore "type" are therefore expected in the DarwinCore "basisOfRecord" property.
We do not mean to imply that there is anything wrong with the DarwinCore perspective. Unfortunately, we believe that DarwinCore cannot coexist with DublinCore data, as long as DarwinCode does not define its own dwc:type/dwc:abstractType property.
-------------
Test case: An image showing a taxon observation shall be documented both in DarwinCore and DublinCore.
DarwinCore prescribes or recommends dcterms:type=Occurrence, plus: basisOfRecord:StillImage.
DublinCore recommends dcterms:type=StillImage.
-------------
We have internally begun to discuss possible solutions. In DublinCore, dcterms:type does not express a particular type of metadata record, but is metadata about the underlying resource. We therefore consider replacing the DwC use of dcterms:type with something in the dwc namespace, and replacing dwc:basisOfRecord with dcterms:type as an option that minimizes the necessary design changes in DwC. We can see some other issues arise that depend on how one tries to bring DwC into closer coherence with the DublinCore recommendations, but perhaps these are best put forth on a wiki.
Here we would like only to point out that we believe that the values for basisOfRecord fit into the dcterm:type vocabulary. Observations (dwc:HumanObservation and dwc:MachineObservation) may be placed as subtypes of http://purl.org/dc/dcmitype/Event. and specimens (dwc:PreservedSpecimen, dwc:FossilSpecimen, dwc:LivingSpecimen) as subtypes of http://purl.org/dc/dcmitype/PhysicalObject. For different communities, the dwc specimen types may have to be further subtyped as "Seed", "TissueSample", "DNA_Sample".
However, we believe it is not possible to create a hierarchy like "StillImage - isSubtypeOf - Image - isSubtypeOf - Occurrence" because this is a use-case dependent view: A character image may be a subtype of a taxon representation, and it may or may not be a subtype of an occurrence representation.
-------------
Best wishes
Gregor, Bob, Steve