In a similar vein as Bob mentioned (below), I would like to see how this proposal would be applied to the specific case where images taken directly of living organisms are used to document occurrences (my original issue posted on the MRTG wiki, http://www.keytonature.eu/wiki/MRTGv08_Type_term_inconsistent_with_DwC). I routinely collect this kind of image and have made the case that live organism images can and should be used in the same way as physical specimens to document occurrences (http://www.cals.ncsu.edu/plantbiology/ncsc/vulpia/pdf/Baskauf_&_Kirchoff...). Thus as occurrence records, the metadata for such images should be in conformity with DwC as well as the media-specific MRTG schema.

In the example of a live plant image from http://www.cas.vanderbilt.edu/bioimages/species/frame/oslo.htm I would assign image record /DwC:recordClass/ = Occurrence /DwC:basisOfRecord/ = StillImage /dcterms:type/ = StillImage /mrtg:subtype/ = Photograph [Note that DwC:basisOfRecord is not synonymous with mrtg:subtype as it currently stands. Would it have to be under John's proposal?]

In the example of an image of an herbarium sheet shown at http://www.morphbank.net/Show/?pop=Yes&id=142009 I would assign the record for the herbarium sheet itself: /DwC:recordClass/ = Occurrence /DwC:basisOfRecord/ = PreservedSpecimen /dcterms:type/ = PhysicalObject

and for the record of the specimen image: /DwC:recordClass/ = Occurrence /DwC:basisOfRecord/ = StillImage /dcterms:type/ = StillImage /mrtg:subtype/ = Photograph

Is this the idea? Again, I note that it is not particularly useful in this situation to consider /basisOfRecord/ a subtype of /dcterms:type/ as they have the same value for the images.

Steve Baskauf

Bob Morris wrote:

For any proposed solutions, I'd like to see a few use cases, e.g., examples of biodiversity multimedia resources, and how the proposals play out for them. For MRTG's concerns, my favorites are:

• http://bit.ly/AudubonOspreyDescription an original Audubon

manuscript describing the Osprey in the Audubon Osprey drawing

• http://bit.ly/AudubonOspreyPrint an original of the Audubon Osprey

print, for sale at a gallery, or as in a stable Collection

• http://bit.ly/AudubonOspreyDigitalImage N.Y. Public Library Digital

Image of Audubon Osprey print.

• http://www.flickr.com/photos/mikebaird/324182767/ a cc licensed

picture on Flickr of an Osprey, georeferenced to named location.

--Bob

On Fri, Oct 23, 2009 at 4:20 PM, John R. WIECZOREK tuco@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@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