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

Sun Oct 25 18:09:23 CET 2009

My feeling is that in its present form MRTG doesn't mean to directly
support all the concerns expressable in
http://code.google.com/p/darwincore/wiki/RecordLevelTerms#basisOfRecord
(other than those we've already agreed belong in dc:type). Instead,
in its "Content Category Vocabulary" MRTG provides a mechanism
"CVTerm"  to identify and use other communities' controlled
vocabularies to describe the content.  Thus, if I had an image of a
PreservedSpecimen, and wanted to signal that in MRTG metadata, I
believe our recommendation would be to use something like the
informally stated
   CVterm = dwc:PreservedSpecimen

The exact representation must depend on the MRTG implementation
language, e.g. RDF or XML Schema, and whether there actually is a DwC
URI dwc:PreservedSpecimen, or whether PerservedSpecimen is just a
favored literal in DwC...something which I can't quite tell at the
moment. A secondary, but important, rationale is the anecdotal
evidence that many existing biodiversity image stores already try to
use DwC terms, and we want it to be easy to reuse those in MRTG in
many cases.

>>>From MRTG's point of view, I think the real discussion is the original
one: get dc:type consistent across MRTG, DwC and DC. The rest of the
discussion probably doesn't impact MRTG very directly, except that
MRTG has to track the fallout and chime  in two places: (a) where we
have used another DwC term that was consistent with DwC before but
becomes inconsistent after the DwC revision and (b)where expertise of
MRTG contributors smells DwC usage problems. I suspect (a) is minimal.
 Happily for me, my expertise probably doesn't cover (b), but Gregor
and Steve seem to be chiming just fine.  :-)

Bob

On Sun, Oct 25, 2009 at 12:49 PM, John R. WIECZOREK <tuco at berkeley.edu> wrote:
> Steve,
>
> Perhaps the definition of the dwc:Occurrence class will help with your
> quandary, as it was meant specifically to apply to all of the cases
> you have brought forth so far, at least if you don't get too caught up
> in the two explicit examples and read more into the "etc."
>
> dwc:Occurrence
>
> Definition: The category of information pertaining to evidence of an
> occurrence in nature, in a collection, or in a dataset (specimen,
> observation, etc.).
>
> Hence, it is perfectly permissible to has a record of a specimen in a
> collection for which there is no location information, or a record of
> a zoo animal for which the location information is the zoo, or a
> photograph of the animal in the zoo with no location information, or
> the photograph of the animal zoo with the location information for the
> zoo perfectly georeferenced. All of these are Occurrence records in
> DwC. How you use them depends on you. How you discover whether they
> are fit for use is by the content of terms such as dcterms:type (as
> newly proposed), dwc:basisOfRecord (as newly proposed),
> dwc:establishmentMeans, dwc:occurrenceStatus, dwc:disposition,
> dwc:samplingProtocol, dwc:georeferenceMethod, or indeed any other term
> that allows you to filter your special criteria.
>
> John
>
> On Sun, Oct 25, 2009 at 4:59 AM, Steve Baskauf
> <steve.baskauf at vanderbilt.edu> wrote:
>> Kevin Richards wrote:
>>
>> I'm not sure I agrre here...
>>
>>
>>
>> Steve Baskauf [steve.baskauf at vanderbilt.edu]
>> Unfortunately, this issue has been clouded somewhat by
>> adoption of the term Occurrence for the class that includes specimens
>> and observations.  I understand the reason why this was done (i.e.
>> because specimens and observations both can serve as records of
>> occurrence), but I think it would be better to have used something like
>> "DerivativeResource" (i.e. a resource that is derived from an organism)
>> for the dwc:recordClass rather than "Occurrence" because an occurrence
>> can documented by resources other than specimens and observations
>>
>>
>> I think there is really only 2 categories of occurrence here - those with
>> physical vouchered specimens, and those with digital only representations.
>> Only those with a physical specimen are "specimen occurrences", all others
>> are "observed occurrences" (even if thay have an image assocuated with
>> them).
>>
>> The distinction I was drawing was between non-physical resources that return
>> a representation of the organism and those that do not.  For example, a
>> database record representing a digital image of a bird could contain a URL
>> to the location from which the bird image can be retrieved.  A consuming
>> application could retrieve this file and display it on the screen for the
>> user to see.  In contrast, a database record representing a checked box for
>> a Christmas Bird Count observation the same bird can return no
>> representation of the bird.  Both records would have the same metadata about
>> location, date, taxonomy, observer, etc. but only the former would have
>> metadata of the sort that MRTG is dealing with (copyright and licensing
>> information for the image, a title, caption, etc.).  In a third case where a
>> bird was mist-netted and the wing length measured, one could put the record
>> in either the first category or the second depending on whether one
>> considered the wing length to be data or metadata.  But that is a question
>> for the observation people and out of my area.  My point was that aside from
>> occurrences with physical vouchers, there are two fundamentally different
>> types of resources: those that return a digital representation of the
>> organism and those that don't.  If a record is linked to a digital
>> representation (StillImage, MovingImage, or Sound), a user may examine that
>> representations for physical or behavioral characters that would allow the
>> taxonomic determination of the organism to be verified, while in the
>> checklist example, the user would simply have to trust the identification
>> ability of the observer.
>>
>> I can't see why this would really restrict you from represetning any
>> occurrence data you may have.
>> Also, one of the beneficial things about DwC is its simplicity and
>> specificity.  If we generalise again (to handle "all" types of occurrence,
>> "resources derived from organisms"), then I feel the ontology will become
>> less usable, and obvious, to end users.  Sometimes it is a good thing to
>> specify precise data fields and types in an ontology.
>>
>>
>>
>> My problem here is with use of the word "occurrence".  The nature of that
>> word implies that the record represents a valid occurrence record for a
>> species, i.e. that the record could appropriately be used to put a dot on on
>> a distribution map for the species.  If I take a StillImage of an Osmorhiza
>> longistylis plant in the woods and my digital camera records the time and
>> GPS coordinates, then those metadata indicate that Osmorhiza longistylis
>> occurred in that woods on the day that I took the image.  On the other hand,
>> if I take an image of a PreservedSpecimen of Osmorhiza longistylis in an
>> herbarium and my camera records the same information, it would not be
>> appropriate to use those time and location metadata to put a dot on the
>> Osmorhiza longistylis distribution map at the location of the herbarium.
>> Rather, the time and location metadata for the collection of the
>> PreservedSpecimen should be used to place the dot.  I still need to record
>> the time and place where the specimen image was taken, I just don't want for
>> it to represent an occurrence.  That is why it bothers me to classify a
>> StillImage of a PreservedSpecimen as a recordType=Occurrence.  My suggestion
>> of the term "DerivativeResource" was an attempt to divorce the USE of the
>> image (to document a valid occurrence or not) from what the thing IS (a
>> representation that was derived directly or indirectly from an organism).
>> Calling such representations something other than "Occurrence" gets us away
>> from the issue raised by Gregor and Bob where there are many possible uses
>> for a resource.  When I take live plant images, I consciously intend for
>> them to be used simultaneously to record an occurrence, illustrate
>> characters, and be used for media tools such as visual keys and visual
>> recognition software, not just to document an occurrence.
>>
>> I should also note that although this problem is widespread for images, it
>> can also apply to physical resources as well.  A PreservedSpecimen taken
>> from a wild-collected plant growing in a botanical garden or animal in a zoo
>> (i.e. from a LivingSpecimen) has the same problem.  Both would provide
>> useful information for identifying the organism but in neither case would
>> the PreservedSpecimen collection time and location represent a valid
>> occurrence that should used to put a dot on a map.  The collection time and
>> location for the LivingSpecimen would be the metadata to use to place the
>> dot (i.e. valid occurrence).
>>
>> Because DwC has traditionally been applied primarily to preserved specimens
>> which usually represent valid species occurrences, this may not have been a
>> very important issue, but for people like me who want to apply DwC to images
>> it is a big deal.
>>
>> Steve Baskauf
>>
>> --
>> Steven J. Baskauf, Ph.D., Senior Lecturer
>> Vanderbilt University Dept. of Biological Sciences
>>
>> postal mail address:
>> VU Station B 351634
>> Nashville, TN  37235-1634,  U.S.A.
>>
>> delivery address:
>> 2125 Stevenson Center
>> 1161 21st Ave., S.
>> Nashville, TN 37235
>>
>> office: 2128 Stevenson Center
>> phone: (615) 343-4582,  fax: (615) 343-6707
>> http://bioimages.vanderbilt.edu
>>
>> _______________________________________________
>> tdwg-content mailing list
>> tdwg-content at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>>
>>
> _______________________________________________
> 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