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

Sat Oct 24 19:24:48 CEST 2009

Your examples step on the dark side of class extension that I
mentioned, and are a special case of my main concern in that posting,
which is that one must think of unintended consequences of any
proposal to fix the agreed-upon problem.

Off-topic, but perhaps an answer to your question about multiple
records: one model is what we hope will emerge at the Annotations
Working Session in Montpellier. With sufficient cyberinfrastructure
for annotations, it shouldn't matter what is the original purpose (or
even the original metadata or content schema) of a digital record. A
set of annotations against an available record or set of records
should form a kind of discoverable view of the original record(s).
Those annotations might even be machine generated, as might be the
case for, e.g., error corrections such as addressing name
mis-spellings, or translations from one metadata schema to another.
Nevertheless, the payload of annotations will be against \some/
metadata schema, and DwC is likely to be a common one, so the problem
of this thread is not irrelevant to real implementations of annotation
mechanisms.

Bob

On Sat, Oct 24, 2009 at 12:48 PM, Richard Pyle
<deepreef at bishopmuseum.org> wrote:
>
> I've wrestled with similar issues; namely collections of images that span
> from obvious occurrence records to illustrative images of the sort that Bob
> shows, to diagrams of particular specimens, to abstract diagrams of no
> specimen in particular.
>
> My concern about Bob's CharacterIllustration BoR is that this is
> non-mutually exclusive to others.  For example, a StillImage in-situ could
> represent both a geographic occurrence and a representation of a particular
> morphological character.  How to represent such cases: two separate records?
>
> My gut feeling is that we need to separate records that represent an
> occurrence, from records that represent the evidence documenting the
> occurrence.  Very often we have undewater video of a fish in its habitat,
> then we collect the specimen, then we take a prepared specimen digital
> photograph.  I assume the appropriate way to represent this through DwC is
> via three separate occurrence records, each appropriately types, and each
> cross-referenced to each other.  But perhaps there should be only one
> occurrence record, with three cross-linked "Evidence" records of some sort.
>
> Too early in the morning for me to think this through thoroughly -- just
> throwing it out there.
>
> Aloha,
> Rich
>
>> -----Original Message-----
>> From: tdwg-content-bounces at lists.tdwg.org
>> [mailto:tdwg-content-bounces at lists.tdwg.org] On Behalf Of Bob Morris
>> Sent: Saturday, October 24, 2009 5:50 AM
>> To: tuco at berkeley.edu
>> Cc: tdwg-content at lists.tdwg.org; Steve Baskauf; Vishwas Chavan (GBIF)
>> Subject: Re: [tdwg-content] Conflict between DarwinCore and
>> DublinCore usageof dcterms:type / basisOfRecord
>>
>> 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 taken.
>>
>> 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.
>>
>> Bob Morris
>>
>>
>> On Fri, Oct 23, 2009 at 4:20 PM, John R. WIECZOREK
>> <tuco at berkeley.edu> wrote:
>> > Gregor,
>> >
>> > 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?
>> >
>> > John
>> >
>> > 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:
>> >>  http://www.keytonature.eu/wiki/MRTG_Schema_v0.8#Subtype
>> >>
>> >> This would then mean, DarwinCore might support:
>> >>  dwc:recordClass
>> >>  dcterms:type
>> >>  dwc:subtype
>> >>
>> >> Gregor
>> >>
>> >
>>
>>
>>
>> --
>> Robert A. Morris
>> Professor of Computer Science (nominally retired)
>> UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390
>> Associate, Harvard University Herberia
>> email: ram at cs.umb.edu
>> web: http://bdei.cs.umb.edu/
>> web: http://etaxonomy.org/FilteredPush
>> http://www.cs.umb.edu/~ram
>> phone (+1)617 287 6466
>> _______________________________________________
>> tdwg-content mailing list
>> tdwg-content at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>
>
>

-- 
Robert A. Morris
Professor of Computer Science (nominally retired)
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390
Associate, Harvard University Herberia
email: ram at cs.umb.edu
web: http://bdei.cs.umb.edu/
web: http://etaxonomy.org/FilteredPush
http://www.cs.umb.edu/~ram
phone (+1)617 287 6466