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

[John R. WIECZOREK]

Comments inline.

On Sun, Oct 25, 2009 at 11:50 AM, Gregor Hagedorn
<g.m.hagedorn at gmail.com> wrote:
> 2009/10/25 John R. WIECZOREK <tuco at berkeley.edu>:
>> Can you explain the difference between your new term dwc:subtype and
>> the term dwc:basisOfRecord most recently proposed in this thread?
>
>> I see no difference bewteen your dwc:subtype and the proposed
>> dwc:basisOfRecord except the name. The term basisOfRecord has been
>> used for this purpose in Darwin Core since 13 Jun 2003. I think
>> precedence should prevail.
>
> Please see my slight preference for the word "subtype" over
> "basisOfRecord" as a secondary question.
>
> The essence is that I propose to use DublinCore (precendence since
> 1995 and extremely widely adapted) where it applies.

Agreed.

> basisOfRecord is a mixture of DublinCore type terms, and subtypes of
> DublinCore terms. In the latter case DwC omits the applicable
> DublinCore resource type vocabulary.

I think you missed some messages in the thread. What you say above is
true of the Darwin Core as published (basisOfRecord has StillImage,
MovingImage, and Sound among the recommendations), but I proposed a
solution (24 Oct 11:29AM) in which there is no mixing. What is "the
latter case" to which you refer - subtypes of Dublin Core terms
defined by Darwin Core? If so, you're correct, Darwin Core recommends
a vocabulary of literals, not refinements of Dublin Core Type
vocabulary (see my commentary in this thread 24 Oct 11:57PM, beginning
with "The following may be confusing...").

> Thus any DC-aware consumer of the data has to do both a mapping of
> dwc:StillImage to http://purl.org/dc/dcmitype/StillImage  and imply
> that the resource quoted throuh PreservedSpecimen, FossilSpecimen,
> LivingSpecimen is a http://purl.org/dc/dcmitype/PhysicalObject, that a
> HumanObservation or  MachineObservation must be
> http://purl.org/dc/dcmitype/Event, and   NomenclaturalChecklist a
> http://purl.org/dc/dcmitype/Text.

Again, there would be no dwc:StillImage. Instead dcmitype:StillImage
would be a possible value for dcterms:type. There would be no formal
declaration of the string literal vocabulary of basisOfRecord, and no
refinements of DCMI Type vocabulary for them.

I really think the answer (well, my answer) to your concerns is in
that paragraph about "The following may be confusing...", which I'll
repeat here for convenience.  If I haven't understood your concern,
please let me know. If you think I did understand it but you don't
like my response (encapsulated below), please propose an alternative.

Thanks,

John

JOHN R WIECZOREK wrote (24 Oct 2009 11:57PM):

"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."

> Gregor
>
> Gregor wrote:
>>> Thus, while I think recordType is a DarwinCore categorization of
>>> intent, not resource, and is fine, I still feel that the basisOfRecord
>>> vocabulary is a subtyping of resource types.
>>>
>>> I therefore believe that it would make life simpler for many consumers
>>> of DwC if DwC would adopt DublinCore type for its own purposes.
>>> Instead of having basisOfRecord =
>>>  PreservedSpecimen
>>>  FossilSpecimen
>>>  LivingSpecimen
>>>  HumanObservation
>>>  MachineObservation
>>>  StillImage
>>>  MovingImage
>>>  Sound
>>>  NomenclaturalChecklist
>>>
>>> DarwinCore would first use the DublinCore vocabulary: dcterms:type=
>>>  StillImage
>>>  MovingImage
>>>  Sound
>>>  Event
>>>  PhysicalObject /ADDED, forgotten in previous mail
>>>  Text
>>>
>>> and then use dwc:subtype=
>>>  PreservedSpecimen
>>>  FossilSpecimen
>>>  LivingSpecimen
>>>  HumanObservation
>>>  MachineObservation
>>>  NomenclaturalChecklist
>>>
>>> for those subtypes of dcterms:type that DarwinCore cares about to
>>> specify further. This would allow consumers to directly map DwC
>>> records into their DublinCore metadata, rather than analysing the
>>> implied hierarchy and mapping in the flattened basisOfRecord.
>