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