Gregor and others,
Thanks for this very clear explanation of the problem. There were good reasons for defining dcterms:type an basisOfRecord the way they are published, but the reasons did not account for this serious conflict with the use of dcterms:type. This must fixed, and right away. It is a pity it wasn't caught earlier, but a good thing it was caught early.
I think the most expedient solution is to switch the usage of dcterms:type and basisOfRecord, swapping there definitions and the type vocabulary control recommendations. That solution only gives me one real hesitation, which is that I believe there will be an explosion of new subtypes in our community, and the maintenance of them in the standard will be come onerous. This was the primary reason for having basisOfRecord not formally controlled by a type vocabulary - because it would be changing all of the time.
So, a second solution is to remove the formal type vocabulary from Darwin Core altogether in combination with the switch in term definitions suggested above. In doing so, the expansion of type usage would be a matter of vocabulary control outside of the normative standard and much easier to maintain.
Thanks again for exposing this issue. Let's find a reasonable solution to this as quickly as possible. I favor the first solution, for now, as it will have the least impact on the standard. If that is agreeable, I'll go through the prescribed process for changes to the standard to get it implemented. Namely:
"3.3. Semantic changes in Darwin Core terms
"Changes of definitions within Darwin Core recommendations and/or Darwin Core term declarations will be reflected in the affected Darwin Core recommendation and/or Darwin Core term declaration. Semantic changes of this type will undergo a request for comments, and will result in a decision [DECISIONS]. If, in the judgment of the TDWG Architecture Group, such changes of meaning are likely to have substantial impact on either machine processing of Darwin Core terms or the functional semantics of the terms, then these changes will be reflected in a change of URI for the Darwin Core term or terms in question. The URIs for any new Darwin Core namespaces resulting from such changes will conform to the Darwin Core namespace URI pattern defined above.
"Requests for semantic changes to a term should be made to the Technical Architecture Group [DWC-USAGE], and should consist of a complete list of attributes to be changed along with a statement of justification for the changes."
Let's consider this to be the beginning of the request for comments.
John
On Fri, Oct 23, 2009 at 2:38 AM, Gregor Hagedorn g.m.hagedorn@gmail.com wrote:
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
--
Dr. Gregor Hagedorn Heinrich-Seidel-Str. 2 12167 Berlin skype: g.hagedorn
This message is sent on a personal basis and does not constitute an activity of the German Federal Government or its research institutions. Together with any attachments, this message is intended only for the person to whom it is addressed and may not be redistributed or published without permission.