It is necessary to describe what Best Practices documents need to be written, 
especially if more than one.

Determine what privilege is required on the gcode site for AC committee members.

I find the term "Record-level terms" to be too generic and non informative. It 
is meant to contrast with "Access-level terms". However, each access level is a 
data record as well. Referring to "record" therefore does not inform the reader 
which level is meant here.

The terms in "Record-level terms" all refer to the production, management, or 
content of a media item. Proposal: use

"Work-level terms" (referring to a work in the sense of the Berne Convention).

I would also be happy with "Content-level terms", highlighting that this is 
about the content of the image or other media, even if this is not fully covers 
all metadata management aspects.

Patrick Sweeney reports a need of the New England Vascular Plants project  to 
represent a checksum in AC data.  

This sounds like a need for some provenance attribute in the Access Point 
Vocabulary.

Both the unqualified name and namespace for the object of hasServiceAccess 
Point should be specified in the normative document.

Pros:
1. Users, documenters, and programmers of applications against different 
representation of AC will be less confused.

Cons:
1. Terms have normative Labels and these can fit all the documentation needs.
2. The namespace certainly doesn't matter. It's just a small way to help 
abbreviate long URIs

Is every multimedia resource subject to copyright? If not, do we need a value 
to represent that?  This is different from Public Domain, which denotes that a 
copyright that has been ceded or expired.

A best practices document is needed for suggested mappings between AC and other 
vocabularies.

1. Provide an ac Term Name or Label. A link to the Normative Term List is
also helpful. This can be easily done at one of the <a ref="http://terms.gb
if.org/wiki/Audubon_Core_Term_List_(DRAFT_of_1.0_normative)#Vocabulary_Indi
ces" Vocabulary Indices</a>

Missing:
ac:demediation 

2. Describe the defect or lack of clarity you find in the term. If you have
an opinion for a change, please add it here, perhaps with pros and cons.

This is a concept that is missing but would be immensely useful. Discovered 
during the pre-review of the DwC RDF Guide to try to map associatedMedia. In 
the absence of a better term name, ac:demediation (modelled on 
foaf:depiction)would enable media other than images to take advantage of the 
concept of embodied in foaf:depiction, which can't be used for anything other 
than an image.

Generate trivial RDF directly from the input to 
http://species-id.net/wiki/Audubon_Core_Term_List

dcterms:extent permits strings that require parsing. Should something else be 
supported as well?

It's more traditional to start camel case property names with lower case, but 
there is no choice for xap:MetadataDate since Adobe XAP specified it.
We should follow that for ac:metadataLanguage

Pros: 
1. Easier to remember camel case of xap:MetadataDate if it matches the required 
 metadata language tag. 

Cons: 
1. metadata language tag would be the only ac native term not following 
traditional.  If all of them are changed, there might still be conflicts with 
other terms' camel case. 
2. tags are generally machine generated, so any confusion has to only be 
resolved once.

There are two normative documents, 
http://terms.gbif.org/wiki/Audubon_Core_(1.0_normative) and 
http://terms.gbif.org/wiki/Audubon_Core_Term_List_(DRAFT_of_1.0_normative)

They might profitably be merged.

Pros: The former explains some subtle points of the latter.

Cons: A merger makes the Term List document even longer than it is now. A 
merger adds material that is mainly about special, subtle, points that most 
readings of the Term List will not stumble upon.

Adopt Audubon Core 1.0

There are no anonymous issue tracker reports permitted

For natural scenes, should any guidance be given n the Geography Vocabulary 
about the location of the camera vs the location of the scene? For distant 
scenes these might be quite different.

1. Provide an ac Term Name or Label. new term

2. Describe the defect or lack of clarity you find in the term. Comment from 
Andréa Matsunaga: "A couple of auxiliary terms also identified in iDigBio, are 
terms to capture the funding source of the digitization effort. Would it be 
possible to add such terms?" iDigBio media terms: http://tinyurl.com/MISC-Media 

1. Whenever term documentation refers to another term, it does so by label, not 
name. Would name be easier to find? Easier to internalize when reading the 
documentation?

2. It might be helpful, and perhaps make the issue moot, if documentation 
carried hyperlinks when referring to other terms.  Both the name and label are 
easily hyper-linked as shown by the two index sets near the top of the Term 
List.  However, it might be a consequential task to set those links.

Public Comment complete for 1.0 adoption consideration.

Develop requirements for finer grain metadata for video and audio than is in AC 
1.0. This may not be feasible before adoption of AC 1.0

Some "Details" fields on Vocabularies are not hyperlinked.  Missing some 
treatment of "Doc" templates at species-id.

Specify detailed use cases for links from borrowed URIs into AC documentation 
instead of the http dereference

The normative page's headers could be rendered in RDF as N3 comments.

Given that we now accept all DwC geography terms, we should eliminate the IPTC 
geography terms.

Pros:
1. They are redundant.
2. If used, they may still in practice have to be mapped to DwC geography 
terms, especially by consuming agents

Cons:
1. In a few cases they are somewhat richer

Recommendation R10 of the TDWG GUID Applicability Statement carries:

"R10. The default metadata response format should be RDF serialized as XML.
If no format is specified in a resolution request, then GUID authorities should 
return information in RDF format by default. Other formats may be returned if 
supported by the provider. This ensures the default metadata for an object is 
compatible with semantic web technologies and can be used for semantic analysis 
and inference.

IPTC terms used in AC are from the IPTC Extension, but most have a definition 
in the IPTC Core namespace also. We should continue to use those in the 
extension.

As an example, see <a 
href="http://terms.gbif.org/wiki/Audubon_Core_Term_List_(DRAFT_of_1.0_normative)
#xmpRights:Owner">xmpRights:Owner</a>

Pros:

<a 
href="http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201
007_1.pdf">The IPTC document</a> carries this advice on page 11:

(legacy) appended to a property name<br>>
This suffix is used if the IPTC Extension provides a better solution to 
annotate the information about an image than the IPTC Core does. In this case, 
the IPTC recommends to phase out the use of the (legacy)-marked property and to 
move towards using the IPTC Extension. See the notes on this matter in the 
particular specification table.

1. Iptc4xmpExt:CVterm. 
http://terms.gbif.org/wiki/Audubon_Core_Term_List_%28DRAFT_of_1.0_normative%29#I
ptc4xmpExt:CVterm

2. Consider adding A Controlled Vocabulary for LTER Datasets 
(http://databits.lternet.edu/spring-2010/controlled-vocabulary-lter-datasets ) 
to Notes of the Term Name: Iptc4xmpExt:CVterm 

associatedObservationReference seems to duplicate the functionality of 
dwc:BasisOfRecord which should be adopted instead.

Pros:

Cons:

Bob explains: "Also, we follow DwC in having no prefix in the names of native 
AC terms."

I always found and still find that totally confusing. In the context of the 
cross-reference issue, I think this even more. 

The result of dwc's decision is that when AC refers to an Darwincore term name, 
this term name does not exist in Dwc. The user has to understand that in dwc, 
the term name changes.

I think we should not continue this in AC and we should add "ac:" in front of 
the audubon core names.

Public Comment opens for adoption consideration.

In order to link issues to terms, we need a representation on the google code 
wiki of the [http://species-id.net/wiki/Audubon_Core_Term_List Audubon Core 
Term List]

We need permalinks for terms. Is the rs.tdwg.org/ac/* enough?

The W3 Provenance Ontology PROV-O is nearing Recommendation stage. Should AC us 
prov:wasDerivedFrom instead of minting a new term?

Pros: new terms ultimately have to be mapped to standards. We should start with 
the standard.

Cons: prov:wasDerivedFrom is the only term from prov (for now).

The job of implementers and readers could be eased if the normative document is 
split into Layer 1 and Layer 2 (or whatever the layers are named) documents (at 
least separated sections).

Pros: easier to know what the layers are

Cons: hard to know which Layer 2 terms may have terms that add nuance to one or 
another Layer 1 term.

Address Public Comments and submit to TDWG EC

In the trivial RDF rendering at 
http://species-id.net/wiki/Audubon_Core_Term_List_RDF_Version, the layer is 
represented as an ac term.  Should it be rendered as a SKOS property instead?

http://species-id.net/wiki/Audubon_Core_Term_List_RDF_Version should perhaps 
use SKOS instead of rdfs:comment for the Comment and Details fields.

Adapt http://rs.tdwg.org/dwc/terms/namespace/index.htm to Audubon Core and 
deploy the adapted result

Produce Best Practices documents

In [http://species-id.net/wiki/Audubon_Core_Term_List_RDF_Version | the Term 
List RDF] there are two RDFS Classes defined that are unrelated to the 
[http://species-id.net/wiki/Audubon_Core_Term_List | normative document], which 
has no notion of Class.] Should the normative document take a position on 
whether implementations that do have classes or types use a specific name space?

As of this writing, Gregor and I have changed the usage "Core Layer" and 
"Extended Layer" to "Layer 1" and "Layer 2" because "Audubon Core Core" is 
clumsy. Nevertheless, these seem inadequately descriptive and perhaps do not 
carry the idea that a simple implementation might only be of Layer 1 terms.

1. Provide an ac Term Name or Label. This applies to all terms which might 
reasonably be applied to both multimedia resources and multimedia collections 
but which don't specify how they apply to each, e.g. xmp:CreateDate

2. Describe the defect or lack of clarity you find in the term. 

'AC is defined as "a set of vocabularies designed to represent metadata for 
biodiversity multimedia resources and collections". While many terms have some 
guidance on how the term applies (or not) to a "multimedia resource" vs. 
"multimedia collections", not all terms display that guidance (e.g., 
xmp:CreateDate). I imagine that the larger a collection becomes, the harder it 
is to have a single value for most of the terms (e.g., dcterms:rights, 
ac:captureDevice, ac:providerID). Would it be possible for each term to display 
information on its applicability to "multimedia resource" vs. "multimedia 
collections", e.g. when to use repeatability of terms for describing 
collections?'  Quote from email from Andréa Matsunaga <[email protected]> 

1. Provide an ac Term Name or Label. ac:variant 
(http://terms.gbif.org/wiki/Audubon_Core_Term_List_%281.0_normative%29#Variant )

2. Describe the defect or lack of clarity you find in the term. Comment from 
Andréa Matsunaga <[email protected]>: "Another important term for iDigBio 
is MD5 checksum for each variant. This allows users retrieving an object to 
automatically verify the integrity of the object. Would it be possible to add 
such a term for each access point?"

The dcterms:identifier is a URI of the resource itself.  An accessURI 
identifies a service, which is not the same thing.

Many people will want to use one identifier for both.... 

What to do?

made minor change of e. g., to e.g., as party test of whether I could edit, and 
partly fix.

In documentation in the term list sometimes the Label, which is usually 
capitalized, and sometimes the term name is used. The latter is rarely 
capitalized except when the term is borrowed from another vocabulary which 
capitalizes the term name. References to a term should always be by its name, 
not its English label.

If the term name needs to stand out, it should probably be italicized.

In http://species-id.net/wiki/Audubon_Core_Term_List_RDF_Version there is a 
class for the objects of hasServiceAccessPoint, but in general the normative 
Term List is free of any notion of classes.  Nevertheless, there should be a 
standardized namespace and type name for constructing URI references for 
"objects" of hasServiceAccessPoint.

Pros:
1. It could uniformize documentation of implementations of AC
2. It could make mapping between implementation more transparent.

Cons:
1. It's a needless constraint.  Documentation of implementations would normally 
be targeted at people who are sophisticated about namespace. 
2. It's conceivable that some implementers may have underlying reasons for 
controlling both the name and namespace of the "class" of such objects.

Figure out how to support  applications that can take a URI and make a 
resolution to the corresponding AC documentation instead of the standard http 
dereferencing. The latter normally goes native documentation when the term is 
in a borrowed namespace.

Probably this could be supported in rdf with an rdfs:comment term containing 
the URL of the wiki entry for the term.  But it remains for the application to 
interpret this, and it might require AC implementors to deal with it. Just 
putting it in RDF probably won't help, e.g. an XML-Schema implementation.

The trivial RDF at 
http://terms.gbif.org/wiki/Audubon_Core_Term_List_RDF_Version is silent on the 
representation of the DwC Geography terms included by reference in the Term 
List 
http://terms.gbif.org/w/index.php?title=Audubon_Core_Term_List_(DRAFT_of_1.0_nor
mative

1. possibly ncd:taxonCoverage, dwc:scientificName, dcterms:description

2. Comment from Rob Stevenson: "Let's say I have a picture of a leaf with holes 
in it.  Is there a way to specify the taxon of the leaf and the taxon of the 
insect that made the holes.  Caterpillar species A eats Plant leaf Species B? 
If I know that caterpillar only made that shape hole when it was parasitized 
can I also specify the taxon of the parasite?  Another leaf example would be 
lichens and liverworts that colonize leaves.  One might be over growing another?

In general I would like to specific multiple taxa and relationships among the 
taxa in the image or movie, etc"

Comment from Alexey Zinovjev: "How would I record most of my sawfly photos:  
which are usually not sawflies [adults or larvae] themselves but their galls, 
mines, 'holes in leaves' (sometimes, by their shape, I can precisely identify 
species produced it), etc., etc.  People will photograph nests, animal's 
traces, record bird songs, but how such media would be tracked?  It seems to be 
a very common situation."

Grant appropriate privilege on gcode site for AC committee.