<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
John & Co.<br>
<br>
It is good to read that DwC would now be finalised as a TDWG standard.
When we are promoting biodiversity data sharing, it helps to convince
new followers when we can unambigously state that we are using real
agreed standards.<br>
<br>
My comments to some of the points<br>
<blockquote
cite="mid:8e794ee60805221315o7e3b7e7eqf05902a5cf684cb7@mail.gmail.com"
type="cite">
<div>1) Is species occurrence in nature and in collections the right
scope for the Core?<br>
</div>
</blockquote>
Occurrence of an organism in nature is the core of the core.<br>
<br>
Collection specimens is already a step more specialised, and those
elements could go to an specimen extension or curatorial extension.<br>
<br>
This is more or less already taken care and what is left is mainly
matter of language. I always have trouble explaining to field
observers that they need to use Collector for Observer or Reporter. It
is confusing to speak of Collector when no specimen was collected. Same
with CollectionCode which really is something like CatalogCode or
DatasetName.<br>
<blockquote
cite="mid:8e794ee60805221315o7e3b7e7eqf05902a5cf684cb7@mail.gmail.com"
type="cite">
<div>2) Should the general philosophy of the Core be inclusive or
minimalist? What are the characteristics of a concept that allow it to
be in the Core? What are the characteristics of a concept that allow it
to be added to an existing extension?<br>
</div>
</blockquote>
Minimalist core but inclusive extensions.<br>
<blockquote
cite="mid:8e794ee60805221315o7e3b7e7eqf05902a5cf684cb7@mail.gmail.com"
type="cite">
<div>3) What are the defining characteristics of a group of related
concepts that justify the creation of a new extension? Should
extensions be based on abstract conceptual groupings/objects (events,
identifications/determinations, places)? Or on special interests
(paleo, curation, interaction)? Or on the stability of the concepts
(core contains the proven stable concepts, extensions are more
volatile)?<br>
</div>
</blockquote>
I favour an approach where the extensions are created by communities of
users, such as invasive species, agriculture, forestry, observers,
botanic gardens, museum collections, etc. Each of these groups already
have their own databases where the necessary elements can be found. <br>
<blockquote
cite="mid:8e794ee60805221315o7e3b7e7eqf05902a5cf684cb7@mail.gmail.com"
type="cite">
<div>4) Should there be elements in the Core and extensions to hold
GUIDs linking them to instances of related classes of objects, such as
an occurrence to a TaxonConceptGUID, or an occurrence to a
CoreGatheringGUID? Should every extension have a non-mandatory GUID
allowing for the external resolution of the object?<br>
</div>
</blockquote>
The core now has GlobalUniqueIdentifier, which can be used to resolve
to the other identifiers for gathering, taxon etc. But that is tricky,
and I doubt how many people can really deal with it. I would probably
want to add direct GUIDs for those most important linking elements, but
package them all into a Linking Extension. In particular we should
include GUID for the taxonomic concept. That is because LSIDs are now
available from SP2000, and probably from some others as well. Lets
start using them!<br>
<br>
The above also concerns the References Elements that need to be removed
from the core, IMHO.<span style="color: rgb(255, 255, 255);"><strong>..<br>
</strong></span>
<blockquote
cite="mid:8e794ee60805221315o7e3b7e7eqf05902a5cf684cb7@mail.gmail.com"
type="cite">
<div>5) <br>
6) Is it the right approach to have restrictions on content at the
concept definition level? <br>
</div>
</blockquote>
Only in cases when the restriction stems from mathematical or logical
rule, then restrict. For agreed sets of values I would refer to
community practice. Communities need to keep such lists, which can
dynamically be changed as agreed, and without need to update standard
versions.<br>
<br>
Regards, Hannu<br>
<br>
</body>
</html>