[tdwg-content] Conflict between DarwinCore and DublinCore usage of dcterms:type / basisOfRecord

[John R. WIECZOREK]

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 at 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.
>