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

[John R. WIECZOREK]

Beginning at the end of Steve's commentary - Darwin Core can handle
the complex cases you are describing, but yes, the
ResourceRelationships are beyond the capabilities of the Simple Darwin
Core (flat by design) except in the limited way of sharing a list (in
a single given term) of resources related in the specific ways defined
by associatedMedia, associatedReferences, associatedOccurrences,
associatedSequences, and associatedTaxa. ResourceRelationship is wide
open in its capacity to relate resources to each other forward and
backward. As Steve points out, dcterms:source can't do this. Not sure
what threw you off thinking that the descriptions suggested ecological
relationships, Steve, because you were right on track.

dwc:resourceID
Definition: An identifier for the resource that is the subject of the
relationship.

dwc: relatedResourceID
Definition: An identifier for a related resource (the object, rather
than the subject of the relationship).

dwc:relationshipOfResource
Definition: The relationship of the resource identified by
relatedResourceID to the subject (optionally identified by the
resourceID). Recommended best practice is to use a controlled
vocabulary.
Comment: Examples: "duplicate of", "mother of", "endoparasite of",
"host to", "sibling of", "valid synonym of", "located within".

There is no reason relationshipOfResource couldn't contain the values
"derived from" or "source of" or any other values deemed clear and
appropriate.

On Sat, Oct 24, 2009 at 2:21 PM, Steve Baskauf
<steve.baskauf at vanderbilt.edu> wrote:
> Comments follow post extracts.
>
> Richard Pyle 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.
>>
>
> This is a topic that our SERNEC Live Plant Image subgroup had discussed at
> length over the last several years - a summary at
> http://www.sernec.org/?q=node/220 for anyone who can stomach it.  I think
> that the problem stems fundamentally from a confusion between what a
> resource IS and the PURPOSE of the resource.  The most helpful way to
> classify a resource is according to what it IS and to let the purpose be
> established through relationships that that resource has with other
> (probably abstract) resources or through assignment of attributes to the
> resource.  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.e. by images) and because a
> specimen does not have to document an occurrence if it is not collected from
> an organism in nature.  This can be illustrated by two figures from a paper
> I'm writing:
>
> http://www.cas.vanderbilt.edu/bsci110a/conceptual-scheme-botanical.gif
> http://www.cas.vanderbilt.edu/bsci110a/conceptual-scheme-insect.gif
>
> These diagrams represent scenarios similar to several ongoing large-scale
> documentation projects - the situation you describe with the fish would be
> similar.  In these situations, the resources that document occurrences are
> those that were derived directly from an individual in the wild (gray
> arrows).  Note that they are seeds, still images, preserved specimens, but
> could potentially also be living specimens, observations, tissue samples, or
> sounds.  The other resources in the diagrams derived indirectly from the
> individual (white arrows) and which are NOT occurrences are: still images,
> preserved specimens, living specimens, DNA samples, and DNA sequences.  The
> point is that there is no fundamental relationship between the type of
> resource and whether it is an occurrence or not.  The same could be said
> about Bob and Gregor's character state illustrations.  In the insect scheme
> diagram, the leg and wing preparations (dwc:basisOfRecord=PreservedSpecimen)
> and their images (dwc:basisOfRecord=StillImage) are specifically created to
> illustrate character states, but they could just as easily be used to
> identify the individual in the wild, as a part of a visual key, or as a
> computer tool to teach visual recognition.  Thus it seems to me a bad idea
> for the value of the recordClass term assigned to a resource to be based on
> the intended use (and therefore requiring several records with nearly
> identical metadata for each type of class).  Better just to say that a
> resource is derived from an organism (i.e. call its recordClass
> "DerivativeResource" rather than "Occurrence"), and indicates it's
> fitness-for-use through other means (e.g. an RDF relationship "isAnOccurence
> of", or "illustratesCharacterState" or something like that).
> John R. WIECZOREK wrote:
>
>> The image would be a different resource that could be referred to by
>> the Occurrence record via dwc:associatedMedia or through an instance
>> of the dwc:ResourceRelationship class. ...
>>
>
> I have been pondering for some time the appropriate way to indicate
> relationships among resources in complex networks such those shown in the
> two diagrams.  It seems to me that using dcterms:source exactly indicates
> the relationship of a resource to the one that it was derived from (e.g. the
> dcterms:source for a specimen image is the identifier for the
> PreservedSpecimen of which it is a representation).  However, I can find in
> DwC no general term for the inverse relationship: derived resources (i.e.
> resources that are created from another).  There are the specific instances
> of dwc:associatedMedia and dwc:associatedSequences, but as you can see from
> the two diagrams, there are many kinds of resources that can be derived from
> others including living and preserved specimens, DNA samples, etc. in
> addition to media items (such as StillImage) and sequences.  It would be
> better to have a general term to point to a derived resource (such as
> "derivedResource").  The type of that resource could then easily be
> determined by a machine by looking at the basisOfRecord for the derived
> resource.  I looked at the dwc:ResourceRelationship class for something that
> would work for this and considered a combination of dwc:relatedResourceID
> and dwc:relationshipOfResource (which could have a value of something like
> "derived").  However, the descriptions of these two terms look like they are
> intended for describing ecological relationships rather than resource
> creation relationships.
> I would be interested to know the best way under DwC to indicate these
> relationships.  The scope of this is really beyond the "Simple Darwin Core"
> because you can't handle such complex collection schemes with a flat
> database, but presumably it is intended at some point for DwC to be able to
> handle complex situations beyond the "Simple" cases.
>
> 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
>
>
>