Closed GoogleCodeExporter closed 9 years ago
Comment from Gerry Moore - NRCS, Greensboro, NC <Gerry.Moore@gnb.usda.gov>
during public comment:
It should be noted that there are different classes of homonyms when talking
about nomenclature of all living things.
Some are perfectly legitimate and unavoidable when the names are governed by
different Codes of nomenclature. For example there is a beetle genus Tribolium
and a grass genus Tribolium. However, homonyms governed by the same Code of
nomenclature cannot be in use. Thus, Rhynchospora pallida M.A.Curtis and
Rhynchopsora pallida Steud. cannot both be used as the latter is an
illegitimate later homonym that is not be taken up.
Also citation of the author names would help in avoiding ambiguities but it
would not solve the problem as sometimes the same author published the same
name for different taxa. Linnaeus did it, for example: Mimosa cinera L. (Sp.
Pl.: 517. 1753) and Mimosa cinera L. (Sp. Pl.: 520. 1753). Thus, homonyms are
defined not as the same name published by different authors, but the same name
with different types. Homonyms are usually published by different authors but
not always.
Comment from Steve: I recognize that these are somewhat vexing problems. What
I'm not sure about is whether fixing them is in scope for Audubon Core. For
example, in the case where aggregation results in the inclusion of media
bearing an illegitimate homonym, I think one could use the term
dwc:acceptedNameUsage to note the currently accepted homonym in the image
database. However, it seems unlikely that this would be done often enough to
consider it to be a term that AC would suggest for general use by media
providers.
In the case of the issues where two different taxa are identified by the same
generic epithet or where two homonyms have identical name strings and authors,
it seems like an identifier for the name would be needed to completely
disambiguate the homonyms. This could be done using a term such as
dwc:scientificNameID, but again, use of this term may be uncommon enough that
it would not warrant placing it among the terms selected for inclusion in
Audubon Core.
How far to the limits of AC extend? Does a problem noted by a single major
provider warrant including the two terms dwc:acceptedNameUsage and
dwc:scientificNameID as part of AC, or does AC just say that in cases like this
the provider is welcome to add any terms from other vocabularies that the
provider sees fit?
Original comment by steve.ba...@vanderbilt.edu
on 9 Apr 2013 at 2:45
Comment from Andréa Matsunaga <ammatsun@acis.ufl.edu> during public review:
"e) In iDigBio (http://tinyurl.com/MISC-Media), some people have expressed the
desire to have information about the magnification being used (to have a rough
idea of the size of the object, potentially from data that is automatically
retrieved from the capturing device) as well as the real world size depicted by
a pixel (for the purposes of allowing one to make measurements on the image;
this would require one to have a scale on an image and perform some
arithmetic). Would it be possible to add such terms?"
Comment from Steve: I put out a request for discussion on this issue to the
tdwg-content list and Live Plant Imaging Group list and received only one reply
from Boyce Tankersley <btankers@chicagobotanic.org>:
"For those living specimens where measurements are critical we include a scale
next to the plant part in the image.
We currently have 25 photographers using their own cameras and I am not sure
how we would be able to determine and/or document magnification levels without
the use of a scale.
If we were working with a single make and model of a camera attached to a
microscope I think the issue of magnification of the raw image would be easier
to determine."
From the lack of discussion about this issue, it is unclear to me how critical
it is to the community to include terms for more detailed metadata about image
extent, pixel dimensions, etc. of the sort that are included in the
SpatialMetrics terms (section 9.1) of the MIX vocabulary
(http://www.loc.gov/standards/mix/ ). So I'm including these comments in this
issue because it is relevant to the question of what terms should be considered
part of Audubon Core.
Unlike Darwin Core, which mints most of the terms in its vocabulary, Audubon
Core adopts many terms from other vocabularies. What is the criterion that
determines the need to include terms from other vocabularies? In Darwin Core,
there is the informal criterion that "at least two people need to want the
term" before considering adding it to the vocabulary. However, since in many
cases AC doesn't actually have to mint terms which users want, how is the
decision made to include terms defined outside of the AC namespace? In order
to satisfy potential users who want to provide metadata for things like the
size of a pixel, one could simply say that all MIX 2.0 terms are incorporated
into AC (in a manner similar to the way all Darwin Core Location terms are
included). But if we go down this road, why not just say that metadata
providers can use any terms from any vocabularies in an "Audubon Core record".
So what I'm getting at here is that the scope of Audubon Core could conceivably
range from the expectation that Audubon Core records contain only the required
terms, to the expectation that Audubon Core records contain any possible
media-related terms that anybody can think of. The obvious answer is that
Audubon Core records contain terms that are on the Audubon Core term list. But
there are already more terms on the AC list than most providers are likely to
use, so what is the criterion by which a decision is made whether or not to add
additional non-AC-defined terms to the list, given that using the non-required
terms is optional anyway?
Original comment by steve.ba...@vanderbilt.edu
on 15 Apr 2013 at 3:27
Comment from Cyndy Parr <parrc@si.edu> during public comment:
Agents vocabulary
EOL has a richer agents extension available here:
http://eol.org/schema/agent_extension.xml
While I don't think it accounts for metadataCreators, it does account
for some other roles that may be relevant. Is there any chance of
borrowing from this?
Comment from Steve: When I looked at the properties listed in the
agent_extension.xml file, most of them seem to be foaf: properties. There
isn't anything that would stop any metadata provider from elaborating on the
details of their metadata using FOAF or any other well-known vocabulary. The
question here is whether those properties would be considered "core" enough for
AC to recommend that they be part of an "Audubon Core record".
Original comment by steve.ba...@vanderbilt.edu
on 25 Apr 2013 at 5:42
[deleted comment]
Moved Cyndy Parr item to Issue #76. All three issues now separated, so closing
this on as Status Duplicate (even though it's earlier than #74, #75, #76
Original comment by morris.bob
on 3 Jun 2013 at 9:47
Original comment by morris.bob
on 3 Jun 2013 at 9:48
Original comment by morris.bob
on 22 Oct 2013 at 1:56
Original issue reported on code.google.com by
steve.ba...@vanderbilt.edu
on 6 Apr 2013 at 11:44