The proposed solution is simpler than people seem to be thinking. From my previous post...
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.
Net solution more fully explained: 1) and 2). dcterms:type will be used in Darwin Core exactly as in the Dublin Core, with exactly the same controlled vocabulary as in Dublin Core ("Collection", "Dataset", "Event", "Image", "InteractiveResource", "MovingImage", "PhysicalObject", "Service", "Software", "Sound", "StillImage", or "Text").
3) and 4). basisOfRecord will be used in Darwin Core as it is now, without a formal type vocabulary. The recommended controlled vocabulary will continue to be managed outside of the standard as supplementary documentation, as was ratified already. The current recommendations are given at http://code.google.com/p/darwincore/wiki/RecordLevelTerms#basisOfRecord. The values on this list can be used or not, changed or not, or added to without affecting the Darwin Core standard. When I mentioned "some of the terms would go to dcterms:type" in my net solution, above, I was thinking that it would be redundant to keep "StillImage", "MovingImage", and "Sound" on the list of controlled vocabulary for basisOfRecord, as they are already in dcterms:type. Communities would be free to add to the vocabulary to the level of specificity they require. For example, MRTG could dispense with the mrtg:subtype term and use dwc:basisOfRecord instead - adding "Photograph", for example, to the controlled vocabulary list. This is exactly the sort of thing basisOfRecord was always meant for.
5) and 6). Add dwc:recordClass and use the formal DwCType vocabulary (Taxon, Occurrence, Location, Event) to control this term rather than control dcterms:type.
One-liner summaries of actual changes to make: 1) Let dcterms:type comply 100% with Dublin Core 2) Create dwc:recordClass to do what was attempted incorrectly with dcterms:type.
Use cases from Bob: UC-Bob1 * http://bit.ly/AudubonOspreyDescription an original Audubon manuscript describing the Osprey in the Audubon Osprey drawing
UC-Bob2 * http://bit.ly/AudubonOspreyPrint an original of the Audubon Osprey print, for sale at a gallery, or as in a stable Collection
UC-Bob3 * http://bit.ly/AudubonOspreyDigitalImage N.Y. Public Library Digital Image of Audubon Osprey print.
UC-Bob4 * http://www.flickr.com/photos/mikebaird/324182767/ a cc licensed picture on Flickr of an Osprey, georeferenced to named location.
UC-Bob1, UC-Bob2, and UC-Bob3 are not a Darwin Core resources - they can't be made into records of any of the DwCTypes (Taxon, Occurrence, Location, Event). This doesn't mean that DwC terms couldn't be used to describe these resource - you just can't make Darwin Core records out of them.
UC-Bob4 can be made into a Darwin Core Occurrence record having: dcterms:type = "StillImage" dwc:basisOfRecord = "Photograph" or "DigitalStillImage" or "DigitalPhotograph" or whatever vocabulary you decide. dwc:recordClass = "Occurrence"
Use cases from Steve: UC-Steve1 * 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?]
UC-Steve2 * 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
UC-Steve3 * and for the record of the specimen image: DwC:recordClass = Occurrence DwC:basisOfRecord = StillImage dcterms:type = StillImage mrtg:subtype = Photograph
For UC-Steve1, looking at the URL, I see nothing that suggests that the resource at http://www.cas.vanderbilt.edu/bioimages/species/frame/oslo.htm refers to an Occurrence record, but I suppose it is no different from having a specimen with no location information. Nevertheless, if the resource was being described with DwC terms, I would assign: dcterms:type = "StillImage" dwc:basisOfRecord = "Photograph" or "DigitalStillImage" or "DigitalPhotograph" or whatever vocabulary you decide. dwc:recordClass = "Occurrence"
For UC-Steve2 the Alaska museum of the North should have an Occurrence record for that specimen with: dcterms:type = "PhysicalObject" dwc:basisOfRecord = "PreservedSpecimen" dwc:recordClass = "Occurrence"
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. The image resource could be described by the terms: dcterms:type = "StillImage" dwc:basisOfRecord = "Photograph" or "DigitalStillImage" or "DigitalPhotograph" or whatever vocabulary you decide. dwc:recordClass = "Occurrence"
I hope that helps.
John
On Sat, Oct 24, 2009 at 9:48 AM, Richard Pyle deepreef@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@lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of Bob Morris Sent: Saturday, October 24, 2009 5:50 AM To: tuco@berkeley.edu Cc: tdwg-content@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@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:
- keep dcterms:type
- 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
-- Robert A. Morris Professor of Computer Science (nominally retired) UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 Associate, Harvard University Herberia email: ram@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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content