[tdwg-content] Conflict between DarwinCore and DublinCore usage of dcterms:type / basisOfRecord
morris.bob at gmail.com
Sat Oct 24 17:50:04 CEST 2009
It seems to me that there is an underlying issue that makes some of
the DwC typing mechanisms difficult to apply to multimedia---at least
in the breadth the MRTG means to approach it--is that DwC is heavily
slanted towards documenting organisms as opposed to documenting
descriptions. Gregor's (and my) favorite examples are pictures meant
to illustrate a character and its states. It's possible, but likely
pointless, to document a picture such as http://bit.ly/pottedTomato as
only, or even primarily, something about the particular organism
photographed. The photograph was (speculatively) taken to illustrate
the concept of compound leaf for use in the Morphster ontobrowser.
Even if its original purpose \were/ to document, say, an Occurrence,
MRTG attempts to provide assistance in determining, without fetching
the media, a resource's fitness-for-use for some use perhaps unknown
or of no interest to the originator of the image. To support this, a
third-party might be motivated to create a MRTG or even a DwC record
as an annotation of the original resource record. Such a new record
must sometimes not be bound by any semantics that tie it to that
particular potted tomato plant, or the time and place the picture was
This particular example might be addressed by adding, e.g.
CharacterIllustration, to the DwC-specific basis of record vocabulary.
That might be a good idea, but it does not fully address my worry,
which is how scalable is DwC to concerns wider than documenting
occurrences. Even if such scalability is to be principally the
addition of recordClass terms for specific uses, it would be good if
one can examine whether such extensions have unintended consequences.
Unbridled class extension has a dark side: it's easy to introduce
inconsistencies and circularities.
On Fri, Oct 23, 2009 at 4:20 PM, John R. WIECZOREK <tuco at berkeley.edu> wrote:
> That sounds like a good solution to all of the problems. I would
> propose that the basisOfRecord IS the the same thing as your proposed
> dwc:subtype, so we should keep basisOfRecord.
> Net solution:
> 1) keep dcterms:type
> 2) use DCType vocabulary to control dcterms:type (so, StillImage,
> PhysicalObject, Event, etc.)
> 3) keep basisOfRecord
> 4) use our DwC-specific subtypes (PreservedSpecimen, FossilSpecimen,
> HumanObservation, etc.) as the controlled vocabulary for basisOfRecord
> without a formal type vocabulary (very close to how it is now, just
> some of the terms would go to dcterms:type).
> 5) add a recordClass term
> 6) use the DwCType vocabulary to control the recordClass term instead
> of the dcterms:type term.
> This solutions fixes the Dublin Core - Darwin Core controlled
> vocabulary problem, retains all existing terms, isolates the
> controlled vocabulary that is specific to our domain, making it very
> easy to expand without changes to the standard.
> Any objections?
> On Fri, Oct 23, 2009 at 12:33 PM, Gregor Hagedorn
> <g.m.hagedorn at gmail.com> wrote:
>>> 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?
>> recordClass for Taxon/Occurrence/Event sounds good.
>> I am less sure about keeping the "perspective-dependent"
>> basisOfRecord-term in a place where dcterms:type. The dcterms:type
>> vocabulary is, in principle, extensible, and meant to be extended.
>> Except, of course, some specific xml-implementation of dublin core
>> prevent this... To avoid problems with this one might desire to have
>> only the strict resource type vocabulary in dcterms:type. Then this
>> could by PhysicalObject/Event and a dwc:subtype added to express
>> PreservedSpecimen/MachineObservation etc. Essentially, MRTG intends to
>> use such a mrtg:subtype as well to differentiate different StillImage
>> or Text subtypes:
>> This would then mean, DarwinCore might support:
Robert A. Morris
Professor of Computer Science (nominally retired)
100 Morrissey Blvd
Boston, MA 02125-3390
Associate, Harvard University Herberia
email: ram at cs.umb.edu
phone (+1)617 287 6466
More information about the tdwg-content