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

[John R. WIECZOREK]

The downside is that we would have no idea what "Class" of record
(Taxon, Occurrence, Location) a record is. That was the reason for
adding dcterms:type to begin with. basisOfRecord may not be the best
name for the term we need for the record class, and it has a history
of being associated with the StillImage, PreservedSpecimen, etc.

How about we retain basisOfRecord, but have it refine dcterms:type,
drop dcterms:type and add a "recordClass" term in its place that is
governed exactly as dcterms:type is currently being used in the
recently ratified version of the Core?



On Fri, Oct 23, 2009 at 10:26 AM, "Markus Döring (GBIF)"
<mdoering at gbif.org> wrote:
> 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
>
>