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

["Markus Döring (GBIF)"]

I agree this should be changed as soon as possible.
Do I understand your proposal John correctly to have:

dcterms:type
uncontrolled by darwin core and expected to be StillImage,  
HumanObservation, etc. The regular DC vocabulary or the classic dwc  
basis of record?

and still keep dwc:basisOfRecord with dwc:Occurrence, dwc:Taxon, etc?

If so, basisOfRecord does not seem intuitive for those kind of  
"classes" to me and I would prefer to either drop it altogether or  
define a new term instead - fully aware that this is opening up a can  
of worms again.
Personally I think I would prefer to simply drop basisOfRecord. What  
are the downsides of this?

Markus

On Oct 23, 2009, at 18:48, John R. WIECZOREK wrote:

> 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.
>>
> _______________________________________________
> tdwg-content mailing list
> tdwg-content at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-content