tdwg / ac

Audiovisual Core
http://www.tdwg.org/standards/638
Creative Commons Attribution 4.0 International
12 stars 6 forks source link

Clarifying the limits to the scope of Audubon Core #55

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
1. Provide an ac Term Name or Label. No particular term, general documentation. 

2. Describe the defect or lack of clarity you find in the term. 
Comment from Gabriele Dröge: 

Why are detailed technical facts about a multimedia item are not part of the 
standard, e.g. color space, chromaticities, width, height, resolution, lens 
aperture, exposure time, compression scheme, saturation, modified date, 
manipulated etc. ?

Additional comment from Steve: Please clarify the limits of Audubon Core - what 
kinds of metadata properties are outside of the scope of the standard. 

Original issue reported on code.google.com by steve.ba...@vanderbilt.edu on 6 Apr 2013 at 11:44

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by morris.bob on 3 Jun 2013 at 9:48

GoogleCodeExporter commented 9 years ago

Original comment by morris.bob on 22 Oct 2013 at 1:56