More comments inline.
On Sat, Oct 24, 2009 at 12:02 PM, Steve Baskauf steve.baskauf@vanderbilt.edu wrote:
Comments inline.
John R. WIECZOREK wrote:
One-liner summaries of actual changes to make:
- Let dcterms:type comply 100% with Dublin Core
- Create dwc:recordClass to do what was attempted incorrectly with
dcterms:type.
OK, I think this is fine if basisOfRecord is not supposed to be a subclass of dcterms:type. Then is basisOrRecord considered to be a subclass of the new dwc:recordClass that replaces the former DwC use of dcterms:type as would be inferred from the "definition" line of http://rs.tdwg.org/dwc/terms/index.htm#basisOfRecord ?
A few points of information. basisOfRecord is a property, not a class, and so it cannot be a subclass. dcterms:type is also a property, not a class. basisOfRecord has no value for the narrowerThan attribute, which it would need to have if it was a sub-property of anything. It isn't. Nor would I propose that it should be. The definition of basisOfRecord was
"The specific nature of the data record - a subtype of the dcterms:type. Recommended best practice is to use a controlled vocabulary."
The word subtype here has no ontological meaning, it is simply used for human understanding of the relationship between the two terms (properties). Under the changes I've proposed the new definition of basisOfRecord should be
"The specific nature of the data record - a subtype of the recordClass. Recommended best practice is to use a controlled vocabulary."
The following may be confusing and isn't necessary to the resolution of the issue mentioned, but I thought I'd bring it up for the sake of completeness. Continue at your own risk. The DublinCore type vocabulary (Image, StillImage, MovingImage, etc.) is composed of classes, not properties, and some of the classes are subtypes of others (for example, StillImage and MovingImage have the subClassOf attribute rdfs:subClassOf rdf:resource="http://purl.org/dc/dcmitype/Image"/). One could create formal vocabulary terms under the Darwin Core type vocabulary for dwctype:PreservedSpecimen, dwctype:FossilSpecimen, dwctype:LivingSpecimen as subclasses of dcmitype:PhysicalObject (rdfs:subClassOf rdf:resource="http://purl.org/dc/dcmitype/PhysicalObject"/), for dwctype:HumanObservation and dwctype:MachineObservation as subclasses of dcmitype:Event (rdfs:subClassOf rdf:resource="http://purl.org/dc/dcmitype/Event"/), and for the remaining terms (TaxonDistribution,TaxonName, NomenclaturalAct, and TaxonNameUsage) as entirely new classes. This was actually done in a previous iteration of the Darwin Core before public review. These new classes (the new vocabulary terms) could be used as values of dcterms:type (in XML, for example, by declaring dcterms:type xsi:type=”dwc:DwCType”) and a basisOfRecord term wouldn't be needed. This is what I mean by a formal vocabulary. In the Darwin Core as published this option was abandoned as being too much of a maintenance burden even within our community, as there is a tendency to split and lump and split ad infinitum. Precedent for not taking on more than can be reasonably handled by volunteer labor can be found in Thomas Baker's "Maintaining a vocabulary: Practices, policies, and models around Dublin Core" (http://dcpapers.dublincore.org/ojs/pubs/article/viewFile/765/761), in which the tendency toward simplicity is defended. In face of this challenge it was deemed prudent to use an informal recommended controlled vocabulary for basisOfRecord that could be managed without affecting the standard, and therefore without incurring the process overhead every time someone wants to add new capabilities using Darwin Core. Time will tell us if this was the right course, but for now, it is what we all ratified by not saying anything to the contrary.
Don't say I didn't warn you about reading this far. ;-)
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?]
...
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"
These images are geolocated - I just haven't finished writing the software to display the location information yet. My intention eventually is to make available all metadata that would be available for a specimen AND for an image resource type, hence my interest in both DwC and MRTG.
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.
Yes, that helps a lot. I agree that they should separate records. I have a comment/question related to the issue of relationships between resources of these types, but since it's also related to another comment as well, I'll attach it to that message. Steve
-- 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