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

[John R. WIECZOREK]

More comments inline.

On Sat, Oct 24, 2009 at 12:02 PM, Steve Baskauf
<steve.baskauf at vanderbilt.edu> wrote:
> Comments inline.
>
> John R. WIECZOREK wrote:
>>
>> 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.
>>
>
> 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