<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
So are we saying that dwc:nameAccordingTo can be a property of an
dwc:Identification? What's dwc:identificationReferences for?<br>
I'm sorry if this is a dumb question but I can plead ignorance on this
topic.<br>
Steve<br>
<br>
Peter DeVries wrote:
<blockquote
cite="mid:AANLkTinR6BE9UHcCUFCfzbbFTZiOnCrOdu1LKiC2nO0r@mail.gmail.com"
type="cite">Hi Markus,
<div><br>
</div>
<div>I feel your pain. :-)</div>
<div><br>
</div>
<div>Maybe an example might help clarify this.</div>
<div><br>
</div>
<div>I use the key* listed below to id my mosquitoes.</div>
<div><br>
</div>
<div>So I should mark up my RDF for the identification with something
like:</div>
<div><br>
</div>
<div><font class="Apple-style-span" face="tahoma, sans-serif"><span
class="Apple-style-span" style="font-size: x-small;"><dwcterms:nameAccordingTo>Identification
And Geographical Distribution Of The Mosquitoes: Of North America,
North Of Mexico By Richard F., Jr. Darsie et al.
2004</dwcterms:nameAccordingTo></span></font></div>
<div><br>
</div>
<div>Rather than use some other term like
"dwc:identificationReferences"</div>
<div><br>
</div>
<div>Correct?</div>
<div><br>
</div>
<div>- Pete</div>
<div><br>
</div>
<div>*</div>
<div>
<div>Identification And Geographical Distribution Of The Mosquitoes:
Of North America, North Of Mexico</div>
<div>By Richard F., Jr. Darsie, RONALD A. WARD, Chien C. Chang, Taina
Litwak</div>
<div>University Press of Florida, 2004</div>
<div>ISBN: 0813027845</div>
<div>Cite: 13463</div>
<div><br>
</div>
<div>=================================================================</div>
<br>
<div class="gmail_quote">On Mon, Oct 18, 2010 at 12:19 PM, "Markus
Döring (GBIF)" <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mdoering@gbif.org">mdoering@gbif.org</a>></span> wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
am sorry I dont have the time to follow this extensive thread, but I
can manage at least the first paragraphs ;)<br>
A quick comment on tying identification sources to a scientific name.
As for other taxon concepts this is usually done with the sec/sensu
reference which should be recorded as dwc:nameAccordingTo:<br>
<br>
<a moz-do-not-send="true"
href="http://rs.tdwg.org/dwc/terms/index.htm#nameAccordingTo"
target="_blank">http://rs.tdwg.org/dwc/terms/index.htm#nameAccordingTo</a><br>
<br>
I am slightly irritated that we seem to have some term duplicates for
this use case.<br>
Maybe dwc:identificationReferences is supposed to only list additional
references?<br>
<br>
Markus<br>
<br>
<br>
On Oct 18, 2010, at 18:49, Steve Baskauf wrote:<br>
<br>
> I've fallen behind on systematically perusing the list responses,
but I would like to focus in on a point that seems to be a consensus in
the responses that have shown up recently. The consensus seems to be
that documenting determinations (a.k.a. instances of dwc:Identification
class) that are applied to Individuals (or Occurrences if you don't
believe in Individuals) is the way to go. So in my usual graphical way
of thinking about this, I would draw a "relationship line" from the
determination to the Individual (or Occurrence) on one side and from
the determination to the species concept on the other. I will leave up
to the taxonomy people the different things would be connected to the
species concept and how all of their lines would be connected. The
determination would have any of the properties that are terms listed in
the dwc:Identification class (identifiedBy, dateIdentified,
identificationReferences, identification Remarks,
identificationQualifier, and typeStatus). Some properties like
dateIdentified and identificationReferences would be string literals
and others (especially identifiedBy) should probably be GUIDs but could
be literals if they had to be.<br>
><br>
> That all seems pretty clear. However, when I've started trying to
do this in real life, I immediately have questions. Take a look at<br>
> <a moz-do-not-send="true"
href="http://bioimages.vanderbilt.edu/rdf/examples/lsu000/0428.rdf"
target="_blank">http://bioimages.vanderbilt.edu/rdf/examples/lsu000/0428.rdf</a>
which should show up as a web page in your browser.<br>
><br>
> 1. The original label identifies the species as Juncus
diffusissimus. However, there is no indicator as to who originally
identified it or when. My assumption is that it was the collector
(Glen N. Montz) but I don't really know that. Do I assume that, or
list the original determiner as "unknown"?<br>
> 2. Do we draw a distinction between the initial identification and
subsequent annotations? I think the answer should be "no" and that's
why I refer to both generically as "determinations".<br>
> 3. There is really no indication given on the annotation labels as
to many of the things that we would like to know, such as the concept
they had in mind, any source they used (if any), or the reason why they
did the annotation. So how does one connect the name that they applied
to the determination when there is no indication of the concept? Is
this just something we can't do for old annotations and just something
that we try to do from this point forward?<br>
> 4. The last question is one that I really want to some opinions
about. It seems to me that there are a number of reasons why one would
apply a determination. One would be to correct an actual error in
identification. One would be to increase the precision of a previous
determination (e.g. an insect identified to family now is identified to
species). One would be to assert a difference in opinion as to the
correct way to group this individual with others (i.e. as in a
taxonomic revision). Finally, a single determiner might apply several
determinations to one individual and indicate in each determination the
concept intended (i.e. if you subscribe to Cronquist, you'd call it X;
if you like Radford's book, you'd call it Y; if you like Weakley's
treatment, you'd call it Z). Some of these four reasons may be
functionally equivalent, but how would you use Darwin Core to indicate
the reason why you applied the determination? Please don't say
"identificationRemarks"! From a machine-processing standpoint, this is
something we should know and there should be some kind of controlled
vocabulary to express it. For instance if an identification is
"deprecated" because it was in error (perhaps by the determiner
him/herself), one would like the incorrect determination to show up in
the historical metadata, but I wouldn't want it to be listed in a
website index. The same would hold true if an annotator was able to
pin the taxon down to a lower taxonomic level than the original
identifier. If someone goes to the trouble to connect an
Individual/Occurrence to several names under alternative concepts,
there should be a way the a machine would know this so that a software
user could select the concept they wanted to use and the name under
that concept would pop up.<br>
><br>
> I don't really see any term under the current DwC that could be
used to do this last thing. Am I missing something? Do we need
several terms to explain the reason why we made the determination
because the reasons fall into different categories?<br>
><br>
> The other comment that I'll throw out (since this is going out to
the bioblitz list as well as to tdwg-content) is that those of you who
are building apps to collect metadata in the field really need to
separate the process of entering (or acquiring) the collection metadata
from the determination process. In at least some apps, the user
immediately has to commit to a taxon as they enter the data at the time
of collection. It seems to me that it would be a very common situation
(especially in the case of "citizen science") that the
collector/observer/photographer would have no idea what the taxonomic
identity was at the time of collection. The process of determination
(and the recording of the various dwc:Identification class terms) is
really a separate process that should be able to happen at the time of
collection OR later.<br>
><br>
> Steve<br>
><br>
> Peter DeVries wrote:<br>
>> Hi Steve,<br>
>><br>
>> I would hypothesize that for the vast majority of identified
records the process is something like this:<br>
>><br>
>> 1) An individual uses some sort of key to determine what
species (taxon concept) to assign to a given individual<br>
>> * They may have created some sort of mental key in which
once they recognize one individual mosquito they can then pretty
quickly sort<br>
>> a number of individuals into collections.<br>
>><br>
>> 2) The actual name they assign to the specimen is usually
based on what their key says the name is. Often this does not specify
the authorship.<br>
>> Most of these human identifiers have not read the original
species descriptions and for the species they are identifying.<br>
>> So the specimen is actually tied to a concept that is
based more on the "key" than the original description.<br>
>> * An exception, would be where there is a key in the
original description and that was what what was used.<br>
>><br>
>> 3) So in a sense, the process of modeling this as if the if
the identifier actually asserted that the concept was the same as that
described by<br>
>> the original description or a subsequent revision is
"fudging"<br>
>><br>
>> Side effects of this process include:<br>
>><br>
>> 1) A new key for North American Mosquitoes comes out that
incorporates recent changes in nomenclature. The major change being the
elevation of<br>
>> a subgenus to a genus. For most of the species described
the "key concept" is unchanged.<br>
>><br>
>> Student identifier, Bob, in state X is using the latest key,
while student identifier, Joe, is state Z is using a slightly older
edition of the same key.<br>
>><br>
>> Bob identifies the species as Ochlerotatus triseriatus, while
Joe identifies what should be the same species as Aedes triseriatus.<br>
>><br>
>> These show up in GBIF on two different maps, they show up in
the EOL as two different pages.<br>
>><br>
>> Various TDWG'ers continue to argue that the original
description and subsequent revisions were really important in
determining what these individuals<br>
>> actually meant when they assigned a name to a specimen, and
that this is how we should model it in excruciating detail.<br>
>><br>
>> I would argue this should be modeled as best as possible to
what actually happens.<br>
>><br>
>> For example, how many of the species observed in the recent
BioBlitz were identified by referring to the original species
description or subsequent revisions?<br>
>><br>
>> In your diagram, I would suggest that you show that a taxon
concept may have many names associated with it. Since it is not clear
what the identifier intended by his or her choice of a name, it is
often difficult to determine what taxon concept they actually meant.<br>
>><br>
>> This is why I advocate a move to a more taxon concept based
identifier to link these data sets together because this allows the
intent of the identifier<br>
>> is more accurately modeled.<br>
>><br>
>> This would be done in the form of:<br>
>><br>
>> "I assert that this specimen (of what I call Aedes
triseriatus) was observed here. I also assert that it is an instance of
the this species concept => URI"<br>
>><br>
>> Or I assert that this is an individual of the type
"Individual of species concept X" = > URI<br>
>><br>
>> All of these are instances of the class "Individual"<br>
>><br>
>> So the resulting DarwinCore record would contain both the name
and and an optional, but I think needed, asserted species concept.<br>
>><br>
>> The species concept is a subclass of taxon concept, but is
fundamentally different than the higher clades.<br>
>><br>
>> There are some guidelines as to what an entity needs to be
considered a species.<br>
>><br>
>> While their are no real guidelines as to what clades should be
considered genera and what clades should be considered families etc.<br>
>><br>
>> Assigning properties at the level of genera or family is also
problematic because it assumes that there will be inferencing and it
will require rechecking<br>
>> that those properties are still valid if the species within
that genera change.<br>
>><br>
>> So if there is some property that is common to all the species
in the genus, make that a property of each of the individual species -
not a property<br>
>> of the genus.<br>
>><br>
>> Respectfully,<br>
>><br>
>> - Pete<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Oct 15, 2010 at 10:45 AM, Steve Baskauf <<a
moz-do-not-send="true" href="mailto:steve.baskauf@vanderbilt.edu">steve.baskauf@vanderbilt.edu</a>>
wrote:<br>
>> As a background to this post, I want to reference a post by
Bob called "SubclassOrNot". I discovered this page on an early foray
into the TDWG website labyrinth and it has been very influential on my
thinking since then. The idea Bob discusses is central to what I'm
writing below so if you haven't read it you might want to do so first.
You can probably skip the "OWL Inference" section and still get the
point which is described in the first two sections of his post. The
URL for the page is <a moz-do-not-send="true"
href="http://wiki.tdwg.org/twiki/bin/view/TAG/SubclassOrNot"
target="_blank">http://wiki.tdwg.org/twiki/bin/view/TAG/SubclassOrNot</a>
.<br>
>><br>
>> To preface what I'm going to say below, I want to put Darwin
Core Occurrences in the context of what Bob wrote. In my mind, one of
the hallmarks of the Darwin Core standard and one thing that makes it a
great improvement over previous versions is that the decision was made
to use what Bob called the "has a" approach rather than the "is a"
approach. In particular, the Darwin Core standard has a single class
called dwc:Occurrence rather than subclasses called "Specimen",
"Observation", and other possible things. The way that we
differentiate among different kinds of Occurrences is by using the DwC
types which are the controlled values for the term dwc:basisOfRecord.
Thus we say an Occurrence "has a" basisOfRecord=PreservedSpecimen
rather than saying it "is a" PreservedSpecimen. We say an Occurrence
"has a" basisOfRecord=HumanObservation rather than saying it "is
a"HumanObservation". This approach has greatly reduced the number of
different terms in the standard since we don't have to have separate
"ObservedBy" and "CollectedBy" terms, but rather can just have a single
"RecordedBy" term that applies to both specimens and observations. The
same thing applies to many other things, like eventDate rather than
DateCollected and DateObserved, locality rather than collectionLocality
and observationLocality, etc. With the ratification of Darwin Core,
this decision is now a fait acompli and not a subject of discussion or
something optional for users of the standard. It also seems to be
clear that as necessary new terms can be added to the DwC types which
would then be valid controlled values for basisOfRecord.<br>
>><br>
>> Since the adoption of the DwC standard, the approach to
Occurrences has been what I would describe as "I know an Occurrence
when I see one". I consider this as a pretty sloppy practice and as I
indicated in my post last night, I think there is enough consensus
about what an Occurrence is that we can come up with a better
definition than "an occurrence is the category of information
pertaining to evidence of an occurrence...". Another part of what I
would characterize as sloppiness is the lack of a clear definition of
what exactly basisOfRecord means. When I wrote my attempt at
summarizing consensus last night, I dodged the question about what I
called the "token". This "thing" has been called various names. In
the previous discussion on the list, it was sometimes called "the
evidence" of the occurrence. In the past I have called it "a
representation" - however, I now think the term "token" is better
because "representation" has a different technical meaning in the
context of content negotiation. When we type an Occurrence by saying
it has a basisOfRecord=PreservedSpecimen, we are saying that this
Occurrence has as supporting evidence, or as a "token" if you prefer,
all or part of the dead remains of the organism (i.e. what I'm calling
"the Individual") that was being documented by the Occurrence. When we
type an Occurrence by saying it has a basisOfRecord=LivingSpecimen, we
are saying that this Occurrence has as a "token" the entire organism
that was being documented (or some vegetative part of the live organism
that was propagated). When we type an Occurrence by saying it has a
basisOfRecord=HumanObservation, we are saying that the Occurrence has
no supporting evidence other than the reputation of the observer to
accurately record the metadata about the Occurrence. In other words,
we "tag" a instance of a core class (to use Bob's words), Occurrence,
by telling a metadata consumer what kind of token we are using as
evidence of the Occurrence.<br>
>> A fundamental part of creating a clear definition of what an
Occurrence is, is to define exactly what we are including in the
concept of Occurrence. One possibility is to (1) say that the two
boxes at the right side of the diagram at <a moz-do-not-send="true"
href="http://bioimages.vanderbilt.edu/pages/occurrence-diagram.gif"
target="_blank">http://bioimages.vanderbilt.edu/pages/occurrence-diagram.gif</a>
are fused and that both the Occurrence metadata and its associated
token are what we consider to be "the Occurrence". Another approach
(2) would be to say that the actual Occurrence as an entity is only the
metadata part and that the token is a separate thing. A third approach
is to say (3) that everything with the blue dotted lines is considered
a part of the Occurrence (i.e. the metadata, the token, the event, and
the locality). I don't think in an absolute sense, any one of these
approaches is "right". The problem is that these approaches are used
inconsistently, sometimes even by the same person, depending on the
basisOfRecord. Differences in ways of thinking about this issue is a
part of why people aren't understanding the way other people are
approaching the structuring of metadata. I have tried to consistently
take the approach (1) that the two boxes on the right are fused, i.e.
that the Occurrence metadata and the token should both be considered
part of the entity that we call "an Occurrence". I think this is why
Rich was confused in <a moz-do-not-send="true"
href="http://lists.tdwg.org/pipermail/tdwg-content/2010-October/001666.html"
target="_blank">http://lists.tdwg.org/pipermail/tdwg-content/2010-October/001666.html</a>
when I said that it was "wrong" to assert that a scientific name is a
property of an Occurrence - obviously it is silly to say that the token
(photons on a film, sound patterns in a digital file) has a scientific
name. Yet that is exactly what people do routinely when the token is a
branch cut off a tree and glued to a piece of paper. They say that
they are "identifying a specimen". What I am asking (actually
demanding) is that the TDWG community get its act together and come to
some consistency on this. If we are going to take the approach (2),
then we need to take specimens off their pedestal and treat them like
we do any other token that we are using as evidence that an Occurrence
happened. If we are going to do what was suggested for the BioBlitz in
<a moz-do-not-send="true"
href="http://lists.tdwg.org/pipermail/tdwg-content/2010-October/001603.html"
target="_blank">http://lists.tdwg.org/pipermail/tdwg-content/2010-October/001603.html</a>,
i.e. to call Occurrences "observations" and then link the tokens to
them by associatedMedia, ResourceRelationship, or some other means
(approach 2) then do it consistently for every kind of token, including
specimens, and don't single out media tokens for punishment.<br>
>> I have in a sense "thrown down the gauntlet" on this issue by
proposing that DigitalStillImage be added as a DwC type and as a
controlled value for basisOfRecord (<a moz-do-not-send="true"
href="http://code.google.com/p/darwincore/issues/detail?id=68"
target="_blank">http://code.google.com/p/darwincore/issues/detail?id=68</a>).
I know what some people are going to say in response to this proposal.
"Why do you need to have 'DigitalStillImage' as a value for
basisOfRecord when you can just say that the resource's
dcterms:type=StillImage?" The answer goes back to Bob's point. If we
are going to go the "has a" path (which we already have in DwC for
Occurrences) rather than subclassing everything, then we need to
provide an appropriate value for the "tag" for any type of resource
that a reasonable number of users will want to use as a token. I think
it is clear from this and other Bioblitzes, my work in Bioimages, the
whale tracking project, and many other examples, that there are plenty
of people who are already using DigitalStillImages as tokens and we all
need a controlled value to use for basisOfRecord.<br>
>> The other thing that we accomplish when we type an Occurrence
by its basisOfRecord is to tell a consumer what kind of metadata to
expect to get about the token in addition to the generic metadata that
is provided for all Occurrences. Thus for a LivingSpecimen we expect
to be told what zoo, botanical garden, bacterial collection, etc.
contains the specimen. For a PreservedSpecimen we expect to be told
the preparation type, the location of the repository, etc. For a
DigitalStillImage we expect to be told the file type, accessURL, etc.
Simply providing a value for dcterms:type=StillImage doesn't indicate
whether the image is a physical one (i.e. on film) or a digital one.
It is also unreasonable to expect a client to have to be checking two
different terms (basisOfRecord and dcterms:type) to find out what they
could learn from one (basisOfRecord). Of course it would be advisable
to provide a value for dcterms:type as well for clients outside the
biodiversity community who may not "understand" what basisOfRecord
means.<br>
>> I hate to keep bringing my posts back to the RDF issue, but
thinking about how one would write RDF forces clear thinking about how
metadata should be structured. If we intend to separate tokens as
entities from their associated Occurrence metadata, i.e. approach (2),
then we open up a whole other can of worms. To associate the
occurrence resources (i.e. the metadata) with the "different" resource
(i.e. the token), we will have probably have to be able to create URIs
for the tokens and separate RDF metadata blocks which will have to be
rdfs:type'd. What are we going to use for that rdfs:type - create
another Darwin Core class? I simply don't think that is a complicated
road that we want to travel. It would be far easier to just say that
every Occurrence has a one-to-one relationship with its token (which
could be "the empty set" for observations). This would not work for
people who want to hang multiple tokens on a single observation event,
but I think that itself is a bad idea because it makes it even harder
to have "flat" occurrence datasets. Just say that every time we
collect a different token (or make an observation that has no token),
it is a new Occurrence record. Realistically, a single collector can't
actually take a picture of a plant at the same time he or she collects
it for a specimen anyway. Those really should be considered two
different events because they happen at different times.<br>
>><br>
>> OK, enough said. Consider this my defense of my proposal
"issue 68" to add DigitalStillImage. I would urge the powers that be
to respond to the issues that I've raised here before having any kind
of "vote" (or whatever is ultimately going to happen when there is an
up or down decision about the proposal).<br>
>><br>
>> Steve<br>
>><br>
>> Steve Baskauf wrote:<br>
>> After the flurry of emails recently, I had an opportunity to
carefully<br>
>> read all the way through the threads again, followed by
enforced "think<br>
>> time" during my long commute. I was actually pretty cheerful
after that<br>
>> because I think that in essence, most of the conversation
about what<br>
>> constitutes an Occurrence really boils down to the same thing.
So I<br>
>> have sat down and tried to summarize what seems to me to be a
consensus<br>
>> about Occurrences. To follow my points, please refer to the
diagram at:<br>
>> <a moz-do-not-send="true"
href="http://bioimages.vanderbilt.edu/pages/occurrence-diagram.gif"
target="_blank">http://bioimages.vanderbilt.edu/pages/occurrence-diagram.gif</a><br>
>><br>
>> Consensus on relationships<br>
>> 1. The fundamental definition of an Occurrence involves
evidence that a<br>
>> representative of a taxon occurred at a place and time.<br>
>> Note 1.A: For clarity, I have modified John's statement in his
last<br>
>> email by replacing "taxon" with "representative of a taxon".
I'm<br>
>> considering a taxon to be an abstract concept that is applied
to<br>
>> individuals or groups of organisms.<br>
>> Note 1.B. This definition is far more useful than the official<br>
>> definition of the class Occurrence "The category of information<br>
>> pertaining to evidence of an occurrence..." which is
essentially circular.<br>
>> Note 1.C: This statement is extremely broad because the
evidence could<br>
>> be of many sorts, the representative could range from a single<br>
>> individual to all organisms on the earth, the taxon could be
anyone's<br>
>> definition at any taxonomic level, the place could range from
a GPS<br>
>> point with uncertainty of less than 10 meters to the entire
planet<br>
>> earth, and the time could range from a shutter click of less
than one<br>
>> second to 3.4 billion years.<br>
>> 2. The diagram is an attempt to summarize in pictorial form
statements<br>
>> and relationships that have been described in the thread. The
taxon<br>
>> representative is recorded as existing at a particular time
and place<br>
>> (the arrow) and the result is an Occurrence record. That
Occurrence<br>
>> record exists as metadata which may be associated with a token
that can<br>
>> be used to voucher the fact that the taxon representative
existed. That<br>
>> token may be the organism itself (or a living part of it as in
a twig<br>
>> for grafting), all or part of the organism in preserved form,
an<br>
>> electronic representation such as an image or sound recording,
and other<br>
>> kinds of things like tissue or DNA samples. There may also be
no token<br>
>> at all, in which case we call the Occurrence record an
observation.<br>
>> Based on direct observation of the taxon representative,
examination of<br>
>> one or more tokens, or both, some determiner asserts that a
taxon<br>
>> concept applies to the taxon representative and as a result a
scientific<br>
>> name can be used to "identify" the taxon representative.
(There may be<br>
>> a lot of other complicated stuff above the Identification box,
but that<br>
>> will have to be filled in by the taxonomists.)<br>
>> Note 2.A: I have mapped onto this diagram the letters that
John used in<br>
>> his last email to refer to entities that are involved in an
Occurrence<br>
>> (T, E, L, O, and G). I will beg the forgiveness of fossil
people<br>
>> because I don't really know how the geological context fits
in. I'm<br>
>> assuming that it is a way of asserting time and location on a
much<br>
>> broader scale than we do for extant organisms.<br>
>> Note 2.B: I have put a dotted line around the part of the
diagram that I<br>
>> think includes all the things that people might consider part
of the<br>
>> Occurrence itself. I have left out "T" and the other parts
related to<br>
>> identification because it seems to me that you can have an
occurrence<br>
>> that you document which does not yet (and perhaps never will)
have an<br>
>> identification. The Occurrence still asserts that a taxon<br>
>> representative existed at a time and place; we just don't yet
know what<br>
>> the taxon is.<br>
>> 3. The red lines indicate the relationships that connect the
various<br>
>> entities (I'm going to go ahead and call them resources).
Consistent<br>
>> with popular opinion, the Occurrence record is the center of
the<br>
>> universe and most things are connected to it.<br>
>> Note 3.A: I am sticking to my guns and refuse to connect the<br>
>> Identification directly to the Occurrence. It is the taxon<br>
>> representative that is being identified, not the occurrence.
One can<br>
>> assert another sort of relationship between the identification
and the<br>
>> occurrence if one wants to say that one consulted the
occurrence<br>
>> metadata and token in order to decide about the
identification, but it<br>
>> is not correct to say that the Identification identifies
either the<br>
>> Occurrence metadata or the token (as Rich pointed out).<br>
>><br>
>> OK, so that's step one - defining what is related to what. If
anyone<br>
>> disagrees with these relationships, please clarify or create
your own<br>
>> diagram.<br>
>><br>
>> Complicating circumstances/caveats<br>
>> 1. It is noted and recognized that some users will not care to
include<br>
>> all of these relationships in their models. In the interest of<br>
>> simplification or "flattening" the relationships, they may
wish to<br>
>> collapse some parts of this diagram (e.g. incorporate time and
location<br>
>> metadata within the Occurrence metadata rather than
considering them<br>
>> separate resources, applying scientific names directly to the
taxon<br>
>> representatives without defining a taxon concept or recording
the<br>
>> determination metadata, connecting identifications directly to
the<br>
>> occurrence, etc.). This doesn't mean that the relationships
don't<br>
>> exist, it just means that some users don't care about them.<br>
>> 2. It is recognized that different users will be interested in
or able<br>
>> to specify the various resources to differing degrees of
precision.<br>
>> Examples: A photographer might record times to the nearest
second, a<br>
>> collector may only be interested in noting the date on which a
specimen<br>
>> was collected. A location may be specified to the precision
of a GPS<br>
>> reading or be defined as some geographic or political
subdivision. The<br>
>> taxon representative may be an individual organism, a flock or
clump, or<br>
>> some larger aggregation of taxon representatives.<br>
>><br>
>> That's step two. If I've missed any complications, please
point them out.<br>
>><br>
>> My opinions about the implications of this diagram<br>
>> 1. The circle I've labeled as "taxon representative" is the
resource<br>
>> type that I'm proposing to be represented by the class
Individual. You<br>
>> will note that in both the definition of dwc:individualID ("An<br>
>> identifier for an individual or named group of individual
organisms...")<br>
>> and the proposed class definition ("The category of information<br>
>> pertaining to an individual or named group of individual
organisms<br>
>> represented in an Occurrence"), groups of individual organisms
are<br>
>> included. Thus John's example of a fossil having myriad
individuals, or<br>
>> Richard's examples of thousands of plankton, a large school of
fish,<br>
>> herd of wildebeest, flock of<br>
>> birds, could all be categorized as "Individual" under this
definition if<br>
>> there is a reasonable expectation that all of the individuals
in the<br>
>> group are members of the same taxon. Perhaps there is a
better name for<br>
>> this resource, but since dwc:individualID was already extant,
I chose<br>
>> Individual as the class name for consistency with the pattern<br>
>> established with other classes and their associated xxxxID
terms.<br>
>> 2. Although in note 1.C. I have given the ranges of the various<br>
>> resources to their logical extreme (as was done previously in
the<br>
>> thread), I think that as a practical matter we can adopt
guidelines to<br>
>> set reasonable values for the "normal" ranges of the
resources. One<br>
>> such guideline might be that we suggest a range that can
accommodate<br>
>> about 95% of the user needs within the community (this came
from Rich's<br>
>> comment about satisfying 95% of the user need with an
establishmentMeans<br>
>> controlled vocuabulary). For example, it was suggested that
the range<br>
>> for the location of an Occurrence could span the entire planet
Earth.<br>
>> True enough, but virtually nobody would find such a span
useful. 95% of<br>
>> users would probably find a range between a GPS reading with
10 meter<br>
>> precision and the extent of a county or province useful for
recording<br>
>> the location of an Occurrence. I can suggest similar "useful"
ranges:<br>
>> one second to one day for an event time (excluding fossils),
one<br>
>> individual organism to the number of organisms that would fit
within a<br>
>> 50 meter radius for an "individual", and taxon identified to
family for<br>
>> plants and maybe mammals, genus for birds, and order for
insects. So<br>
>> framing the definition of an Occurrence in these terms it
would be<br>
>> something like: "An occurrence involves evidence (consisting
of a<br>
>> physical token, electronic record, or personal observation)
that a<br>
>> representative (ranging from a single individual to the number
that<br>
>> would fit on a football field) of a taxon (hopefully
identified to some<br>
>> lower taxonomic level) occurred at a place (determined to a
precision<br>
>> between that of a GPS reading and the size of a
county/province) and<br>
>> time (spanning one second to one day)." A few people might
object to<br>
>> this level of restrictiveness, but I would guess that it would
make 95%<br>
>> of us happy.<br>
>> 3. With the exception of the "missing" class Individual, every
resource<br>
>> type on this diagram except for the "token" and Scientific
name has a<br>
>> Darwin Core class. Every resource type on the diagram except
for "token"<br>
>> has a dwc:xxxxID term that can be used to refer to a GUID for
the<br>
>> resource. The implication of this is that any resource on
this diagram<br>
>> except for the token and taxon representative (i.e.
Individual) is ready<br>
>> to be represented in RDF by Darwin Core terms in the sense
that the<br>
>> relationships (red lines) can be represented by the xxxxID
terms and<br>
>> that the resources can be rdfs:type'd using Darwin Core
classes.<br>
>> (Lacking a class for the scientific name doesn't seem like a
big deal to<br>
>> me since the scientific name can be a string literal - but
then I'm not<br>
>> a taxonomist.)<br>
>> 4. OK, I've avoided it as long as I can, so I'm going to
confess now to<br>
>> the RDF-phobes. The red lines and shapes are something pretty
close to<br>
>> an RDF graph. What that means is that if the community can
agree that<br>
>> this diagram correctly represents the relationships among the
kinds of<br>
>> biodiversity resources that we care about, then the matter of
providing<br>
>> guidelines on how to represent Darwin Core in RDF suddenly
gets a lot<br>
>> simpler. Just convert the "picture" of the RDF graph into XML
format<br>
>> and we have a template. Alright, that's an
oversimplification, but I<br>
>> think it is essentially true because the most difficult part of<br>
>> achieving a consensus on RDF representations is to decide how
we connect<br>
>> the resource types, not on the literals that we hang onto
resources as<br>
>> properties.<br>
>> 5. While I'm beating the RDF drum again, the importance of my
opinion<br>
>> number 2 can be extended into the GUID adoption process. In
my comments<br>
>> to Kevin about the Beginner's Guide to Persistent Identifiers,
I think I<br>
>> commented on the question of how one decides whether a GUID
needs to be<br>
>> assigned to something or not. I believe that the answer to
that<br>
>> question boils down to this: we need a GUID for any resource
that will<br>
>> be referenced by more than one other resource. Do we need to
be able to<br>
>> assign a GUID to Taxon concepts? Yes, because it is likely
that many<br>
>> identifications will want to reference a particular taxon
concept. Do<br>
>> we need to be able to assign a GUID to an Event? Maybe or
maybe not.<br>
>> If every occurrence has its own separate time recorded, then
no GUID is<br>
>> needed because the time is just a part of every separate
occurrence<br>
>> record. If the event is defined to be a time range that
represents a<br>
>> collecting trip, then there may be many Occurrences that are
associated<br>
>> with that trip and all of them could reference the GUID for
that event<br>
>> rather than repeating the event information for every
Occurrence. The<br>
>> point here is that every shape (class of resources) on this
diagram at<br>
>> least has the POTENTIAL to be a node connecting multiple
resources and<br>
>> therefore should have the capability of being assigned a GUID,
having<br>
>> its own RDF record, and being appropriately typed (presumably
by a DwC<br>
>> class). So this is a final technical argument for why we need
to have<br>
>> the DwC class Individual. Whether or not people ultimately
choose to<br>
>> assign GUIDs to particular resource types or not is their own
choice,<br>
>> but they need to at least be ABLE to if they need that
resource to serve<br>
>> as a node given the structure of their metadata.<br>
>><br>
>> We need to clarify how the "token" thing fits in, but I'm
stopping there<br>
>> for now. I would very much appreciate responses indicating
that:<br>
>><br>
>> A. you agree with the diagram and connections (and consider
this<br>
>> definition and diagram a consensus)<br>
>> B. you disagree with the diagram (and articulate why)<br>
>> C. you provide an alternative diagram or explanation of the<br>
>> relationships among the classes related to Occurrences.<br>
>><br>
>> Thanks for you patience with another tome.<br>
>> Steve<br>
>><br>
>> --<br>
>> Steven J. Baskauf, Ph.D., Senior Lecturer<br>
>> Vanderbilt University Dept. of Biological Sciences<br>
>><br>
>> postal mail address:<br>
>> VU Station B 351634<br>
>> Nashville, TN 37235-1634, U.S.A.<br>
>><br>
>> delivery address:<br>
>> 2125 Stevenson Center<br>
>> 1161 21st Ave., S.<br>
>> Nashville, TN 37235<br>
>><br>
>> office: 2128 Stevenson Center<br>
>> phone: (615) 343-4582, fax: (615) 343-6707<br>
>> <a moz-do-not-send="true"
href="http://bioimages.vanderbilt.edu" target="_blank">http://bioimages.vanderbilt.edu</a><br>
>><br>
>> _______________________________________________<br>
>> tdwg-content mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
>> <a moz-do-not-send="true"
href="http://lists.tdwg.org/mailman/listinfo/tdwg-content"
target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
>> .<br>
>><br>
>><br>
>><br>
>> --<br>
>> Steven J. Baskauf, Ph.D., Senior Lecturer<br>
>> Vanderbilt University Dept. of Biological Sciences<br>
>><br>
>> postal mail address:<br>
>> VU Station B 351634<br>
>> Nashville, TN 37235-1634, U.S.A.<br>
>><br>
>> delivery address:<br>
>> 2125 Stevenson Center<br>
>> 1161 21st Ave., S.<br>
>> Nashville, TN 37235<br>
>><br>
>> office: 2128 Stevenson Center<br>
>> phone: (615) 343-4582, fax: (615) 343-6707<br>
>> <a moz-do-not-send="true"
href="http://bioimages.vanderbilt.edu" target="_blank">http://bioimages.vanderbilt.edu</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>>
----------------------------------------------------------------<br>
>> Pete DeVries<br>
>> Department of Entomology<br>
>> University of Wisconsin - Madison<br>
>> 445 Russell Laboratories<br>
>> 1630 Linden Drive<br>
>> Madison, WI 53706<br>
>> TaxonConcept Knowledge Base / GeoSpecies Knowledge Base<br>
>> About the GeoSpecies Knowledge Base<br>
>> ------------------------------------------------------------<br>
><br>
> --<br>
> Steven J. Baskauf, Ph.D., Senior Lecturer<br>
> Vanderbilt University Dept. of Biological Sciences<br>
><br>
> postal mail address:<br>
> VU Station B 351634<br>
> Nashville, TN 37235-1634, U.S.A.<br>
><br>
> delivery address:<br>
> 2125 Stevenson Center<br>
> 1161 21st Ave., S.<br>
> Nashville, TN 37235<br>
><br>
> office: 2128 Stevenson Center<br>
> phone: (615) 343-4582, fax: (615) 343-6707<br>
><br>
> <a moz-do-not-send="true" href="http://bioimages.vanderbilt.edu"
target="_blank">http://bioimages.vanderbilt.edu</a><br>
> _______________________________________________<br>
> tdwg-content mailing list<br>
> <a moz-do-not-send="true"
href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.tdwg.org/mailman/listinfo/tdwg-content"
target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
----------------------------------------------------------------<br>
Pete DeVries<br>
Department of Entomology<br>
University of Wisconsin - Madison<br>
445 Russell Laboratories<br>
1630 Linden Drive<br>
Madison, WI 53706<br>
<a moz-do-not-send="true" href="http://www.taxonconcept.org/"
target="_blank">TaxonConcept Knowledge Base</a> / <a
moz-do-not-send="true" href="http://lod.geospecies.org/"
target="_blank">GeoSpecies Knowledge Base</a><br>
<a moz-do-not-send="true" href="http://about.geospecies.org/"
target="_blank">About the GeoSpecies Knowledge Base</a><br>
------------------------------------------------------------<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
</pre>
</body>
</html>