diff --git a/code/build-preview.py b/code/build-preview.py
index fc8ea4ed..701cef52 100644
--- a/code/build-preview.py
+++ b/code/build-preview.py
@@ -5,10 +5,12 @@
languages = [
{'text': 'Čeština', 'href': '/cs/'},
+ {'text': 'Deutsch', 'href': '/de/'},
{'text': 'Español', 'href': '/es/'},
{'text': 'Français', 'href': '/fr/'},
{'text': '日本語', 'href': '/ja/'},
{'text': '한국어', 'href': '/ko/'},
+ {'text': 'Português', 'href': '/pt/'},
{'text': 'Русский', 'href': '/ru/'},
{'text': '繁體中文', 'href': '/zh-Hant/'}
]
diff --git a/code/build-webpages.py b/code/build-webpages.py
index d853663b..794d1509 100644
--- a/code/build-webpages.py
+++ b/code/build-webpages.py
@@ -21,7 +21,7 @@
# -----------------
# Configuration section
# -----------------
-languages = ['en', 'es', 'pt', 'de', 'fr', 'ko', 'nl', 'ru', 'zh-Hant']
+languages = ['en', 'cs', 'de', 'es', 'fr', 'ja', 'ko', 'nl', 'pt', 'ru', 'zh-Hant']
# -----------------
# Command line arguments
@@ -327,7 +327,7 @@ def generate_vocabulary_tables(self, locale):
if self.vocab_type == 1:
text += '\t\t
\n'
text += '\t\t\t | \n'
- text += '\t\t\t%s: %s -- %s: %s | \n' % (self.t('required'), self.t_val(row, 'tdwgutility_required', l), self.t('repeatable'), self.t_val(row, 'tdwgutility_repeatable', l))
+ text += '\t\t\t%s: %s – %s: %s | \n' % (self.t('required'), self.t_val(row, 'tdwgutility_required', l), self.t('repeatable'), self.t_val(row, 'tdwgutility_repeatable', l))
text += '\t\t
\n'
if row['term_deprecated'] != '':
diff --git a/code/cd-template/termlist-header.ar.md b/code/cd-template/termlist-header.ar.md
index 6cceaaf3..1c66d8b3 100644
--- a/code/cd-template/termlist-header.ar.md
+++ b/code/cd-template/termlist-header.ar.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -53,6 +53,7 @@ Section 3 is informative (non-normative).
In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
### 1.2 RFC 2119 key words
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
## 2 Use of Terms
@@ -63,6 +64,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
## 3 Term index
diff --git a/code/cd-template/termlist-header.cs.md b/code/cd-template/termlist-header.cs.md
index 6cceaaf3..1f3b7b48 100644
--- a/code/cd-template/termlist-header.cs.md
+++ b/code/cd-template/termlist-header.cs.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -9,19 +9,19 @@ Namespace IRI
Preferred namespace abbreviation
: accd:
-Date version issued
+Datum vydání verze
: {ratification_date}
-Date created
+Datum vytvoření
: {created_date}
-Part of TDWG Standard
+Část standardu TDWG
: <{standard_iri}>
-This version
+Tato verze
: <{current_iri}{ratification_date}>
-Latest version
+Aktuální verze
: <{current_iri}>
{previous_version_slot}
@@ -29,40 +29,41 @@ Latest version
Abstract
: {abstract}
-Contributors
+Přispěvatelé
: {contributors}
-Creator
+Tvůrce
: {creator}
-Bibliographic citation
+Bibliografická citace
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1 Úvod (informativní)
This document includes terms intended to be used as controlled values for Audiovisual Core terms `Iptc4xmpExt:CVterm` and `ac:CVtermLiteral`.
-### 1.1 Status of the content of this document
+### 1.1 Status obsahu tohoto dokumentu
-Section 1 is informative (non-normative).
+Oddíl 1 je informativní (nenormativní).
-Section 2 is normative.
+Oddíl 2 je normativní.
-Section 3 is informative (non-normative).
+Oddíl 3 je informativní (nenormativní).
-In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
+V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Štítek` a hodnoty všech ostatních vlastností nejsou normativní.
-### 1.2 RFC 2119 key words
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
+### 1.2 Klíčová slova RFC 2119
-## 2 Use of Terms
+Klíčová slova "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" a "OPTIONAL" v tomto dokumentu je třeba interpretovat tak, jak je popsáno v [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) a [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174), pokud a pouze pokud jsou uvedena velkými písmeny, jak je uvedeno zde.
-### 2.1 Relationship of value types to property terms
+## 2 Použití termínů
+
+### 2.1 Vztah hodnotových typů k pojmům vlastnictví
In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/ac/doc/termlist/), unabbreviated term IRIs SHOULD be used as values of the property `Iptc4xmpExt:CVterm`. Controlled value strings SHOULD be used as values of the property `ac:CVtermLiteral`.
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+IRI pro termín v tomto slovníku označuje stejný pojem jako pojem označený řízeným řetězcem hodnot pro stejný termín. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
-## 3 Term index
+## 3 Index termínů
diff --git a/code/cd-template/termlist-header.de.md b/code/cd-template/termlist-header.de.md
index 6cceaaf3..1c66d8b3 100644
--- a/code/cd-template/termlist-header.de.md
+++ b/code/cd-template/termlist-header.de.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -53,6 +53,7 @@ Section 3 is informative (non-normative).
In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
### 1.2 RFC 2119 key words
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
## 2 Use of Terms
@@ -63,6 +64,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
## 3 Term index
diff --git a/code/cd-template/termlist-header.es.md b/code/cd-template/termlist-header.es.md
index 6cceaaf3..386ddde1 100644
--- a/code/cd-template/termlist-header.es.md
+++ b/code/cd-template/termlist-header.es.md
@@ -1,68 +1,69 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
-Namespace IRI
+Espacio de nombres IRI
:
-Preferred namespace abbreviation
+Abreviatura preferida del namespce
: accd:
-Date version issued
+Fecha de publicación de la versión
: {ratification_date}
-Date created
+Fecha de creación
: {created_date}
-Part of TDWG Standard
+Parte del Estándar TDWG
: <{standard_iri}>
-This version
+Esta versión
: <{current_iri}{ratification_date}>
-Latest version
+Última versión
: <{current_iri}>
{previous_version_slot}
-Abstract
+Resumen
: {abstract}
-Contributors
+Colaboradores
: {contributors}
-Creator
+Creador
: {creator}
-Bibliographic citation
+Cita bibliográfica
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1. Introducción (Informativa)
-This document includes terms intended to be used as controlled values for Audiovisual Core terms `Iptc4xmpExt:CVterm` and `ac:CVtermLiteral`.
+Este documento incluye términos destinados a ser utilizados como valores controlados para los términos principales de Audiovisual Core `Iptc4xmpExt:CVterm` y `ac:CVtermLiteral`.
-### 1.1 Status of the content of this document
+### 1.1 Estado del contenido de este documento
-Section 1 is informative (non-normative).
+La Sección 1 es informativa (no normativa).
-Section 2 is normative.
+La sección 2 es normativa.
-Section 3 is informative (non-normative).
+La Sección 3 es informativa (no normativa).
-In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
+En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. La `Etiqueta` y los valores de todas las demás propiedades no son normativos.
-### 1.2 RFC 2119 key words
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
+### 1.2 Palabras clave RFC 2119
-## 2 Use of Terms
+Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" y "OPTIONAL" en este documento deben interpretarse como se describe en [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) y [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174), únicamente cuando aparezcan en mayúsculas, tal como se muestra aquí.
-### 2.1 Relationship of value types to property terms
+## 2 Uso de los Términos
-In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/ac/doc/termlist/), unabbreviated term IRIs SHOULD be used as values of the property `Iptc4xmpExt:CVterm`. Controlled value strings SHOULD be used as values of the property `ac:CVtermLiteral`.
+### 2.1 Relación de los tipos de valor con los términos de propiedad
-### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
+De acuerdo con el [documento de la Lista de Términos Básicos Audiovisuales](http://rs.tdwg.org/ac/doc/termlist/), los términos IRI no abreviados DEBEN usarse como valores de la propiedad `Iptc4xmpExt:CVterm`. Las cadenas de valores controlados DEBEN usarse como valores de la propiedad `ac:CVtermLiteral`.
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+### 2.2 Relación entre los valores de ac:CVtermLiteral y Iptc4xmpExt:CVterm
-## 3 Term index
+Una IRI para un término en este vocabulario denota la misma clase que la clase denotada por la cadena de valor controlado para el mismo término. Por lo tanto, un cliente PUEDE inferir un valor IRI para `Iptc4xmpExt:CVterm` dada una cadena de valor controlado para `ac:CVtermLiteral` incluso si ese IRI no se indica explícitamente. La implicación práctica es que los agregadores de datos PUEDEN materializar valores para la propiedad preferida `Iptc4xmpExt:CVterm` en los casos en que los proveedores solo proporcionan valores para `ac:CVtermLiteral`.
+
+## 3 Índice de Términos
diff --git a/code/cd-template/termlist-header.fr.md b/code/cd-template/termlist-header.fr.md
index 6cceaaf3..d526b156 100644
--- a/code/cd-template/termlist-header.fr.md
+++ b/code/cd-template/termlist-header.fr.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -9,53 +9,55 @@ Namespace IRI
Preferred namespace abbreviation
: accd:
-Date version issued
+Date de publication de la dernière mise à jour
: {ratification_date}
-Date created
+Date de création
: {created_date}
-Part of TDWG Standard
+Fait partie du standard TDWG
: <{standard_iri}>
-This version
+Cette version
: <{current_iri}{ratification_date}>
-Latest version
+Dernière version
: <{current_iri}>
-{previous_version_slot}
+Version précédente
+: {previous_version_slot}
Abstract
: {abstract}
-Contributors
+Contributeurs
: {contributors}
-Creator
-: {creator}
+Créateur :
+{creator}
-Bibliographic citation
-: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
+Citation :
+{creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
## 1 Introduction (informative)
This document includes terms intended to be used as controlled values for Audiovisual Core terms `Iptc4xmpExt:CVterm` and `ac:CVtermLiteral`.
-### 1.1 Status of the content of this document
+### 1.1 Statut du contenu de ce document
Section 1 is informative (non-normative).
-Section 2 is normative.
+La section 2 est normative.
Section 3 is informative (non-normative).
-In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
+Dans la section 4, les valeurs de l'`IRI du terme`, de la `Définition` et de la `Valeur contrôlée` sont normatives. La valeur de `Utilisation` (si elle existe pour un terme donné) est normative. Les valeurs de `Nom du Terme` ne sont pas normatives, bien que l'on puisse s'attendre à ce que le préfixe de l'abréviation de l'espace de noms soit celui couramment utilisé pour l'espace de noms du terme. `Label` and the values of all other properties are non-normative.
-### 1.2 RFC 2119 key words
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
+### 1.2 Mots clés RFC 2119
-## 2 Use of Terms
+Les mots clés "MUST/DOIT", "MUST NOT/NE DOIT PAS", "REQUIRED/OBLIGATOIRE", "SHALL/DEVRA", "SHALL NOT/NE DEVRA PAS", "SHOULD/DEVRAIT", "SHOULD NOT/NE DEVRAIT PAS", "RECOMMENDED/RECOMMANDÉ", "MAY/POURRAIT", et "OPTIONAL/OPTIONNEL" dans ce document doivent être interprétés comme défini dans les références [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) et [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174)] uniquement lorsqu’ils apparaissent en majuscules, comme ci-dessus.
+
+## 2 Utilisation des termes
### 2.1 Relationship of value types to property terms
@@ -63,6 +65,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
-## 3 Term index
+## 3 Index des termes
diff --git a/code/cd-template/termlist-header.ja.md b/code/cd-template/termlist-header.ja.md
index 6cceaaf3..1072cfcf 100644
--- a/code/cd-template/termlist-header.ja.md
+++ b/code/cd-template/termlist-header.ja.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -9,53 +9,55 @@ Namespace IRI
Preferred namespace abbreviation
: accd:
-Date version issued
+バージョン発行日
: {ratification_date}
-Date created
+作成日
: {created_date}
-Part of TDWG Standard
+TDWG標準での該当箇所
: <{standard_iri}>
-This version
+このバージョン
: <{current_iri}{ratification_date}>
-Latest version
+最新バージョン
: <{current_iri}>
+前のバージョン
{previous_version_slot}
Abstract
: {abstract}
-Contributors
+貢献者
: {contributors}
-Creator
+作成者
: {creator}
-Bibliographic citation
+書誌的引用
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
## 1 Introduction (informative)
This document includes terms intended to be used as controlled values for Audiovisual Core terms `Iptc4xmpExt:CVterm` and `ac:CVtermLiteral`.
-### 1.1 Status of the content of this document
+### 1.1 この文書の内容のステータス
Section 1 is informative (non-normative).
-Section 2 is normative.
+第2節は規範的な内容です。
Section 3 is informative (non-normative).
-In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
+セクション 4 では、`用語のIRI(Term IRI)`、`定義(Definition)`、`制御値(Controlled value)`の値が規範的なものです。 `使用法(Usage)`の値がもし存在する場合、それは規範的なものです。 `用語の名前(Term Name)`の値は非規範的ですが、名前空間の略語の接頭辞はその用語の名前空間で一般的に使われるものであると予想できます。 `Label` and the values of all other properties are non-normative.
-### 1.2 RFC 2119 key words
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
+### 1.2 RFC 2119 キーワード
-## 2 Use of Terms
+この文書における "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL" というキーワードは、ここに示されているようにすべて大文字で記載されている場合に限り、[BCP 14](https://www.rfc-editor.org/info/bcp14)、[\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) 、[\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) に記述されているように解釈されます。
+
+## 2 用語の使い方
### 2.1 Relationship of value types to property terms
@@ -63,6 +65,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
-## 3 Term index
+## 3 用語索引
diff --git a/code/cd-template/termlist-header.km.md b/code/cd-template/termlist-header.km.md
index 6cceaaf3..1c66d8b3 100644
--- a/code/cd-template/termlist-header.km.md
+++ b/code/cd-template/termlist-header.km.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -53,6 +53,7 @@ Section 3 is informative (non-normative).
In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
### 1.2 RFC 2119 key words
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
## 2 Use of Terms
@@ -63,6 +64,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
## 3 Term index
diff --git a/code/cd-template/termlist-header.ko.md b/code/cd-template/termlist-header.ko.md
index 6cceaaf3..1c66d8b3 100644
--- a/code/cd-template/termlist-header.ko.md
+++ b/code/cd-template/termlist-header.ko.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -53,6 +53,7 @@ Section 3 is informative (non-normative).
In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
### 1.2 RFC 2119 key words
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
## 2 Use of Terms
@@ -63,6 +64,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
## 3 Term index
diff --git a/code/cd-template/termlist-header.nl.md b/code/cd-template/termlist-header.nl.md
index 6cceaaf3..1c66d8b3 100644
--- a/code/cd-template/termlist-header.nl.md
+++ b/code/cd-template/termlist-header.nl.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -53,6 +53,7 @@ Section 3 is informative (non-normative).
In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
### 1.2 RFC 2119 key words
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
## 2 Use of Terms
@@ -63,6 +64,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
## 3 Term index
diff --git a/code/cd-template/termlist-header.pt.md b/code/cd-template/termlist-header.pt.md
index 6cceaaf3..1c66d8b3 100644
--- a/code/cd-template/termlist-header.pt.md
+++ b/code/cd-template/termlist-header.pt.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -53,6 +53,7 @@ Section 3 is informative (non-normative).
In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
### 1.2 RFC 2119 key words
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
## 2 Use of Terms
@@ -63,6 +64,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
## 3 Term index
diff --git a/code/cd-template/termlist-header.ru.md b/code/cd-template/termlist-header.ru.md
index 6cceaaf3..af14a52d 100644
--- a/code/cd-template/termlist-header.ru.md
+++ b/code/cd-template/termlist-header.ru.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -9,53 +9,50 @@ Namespace IRI
Preferred namespace abbreviation
: accd:
-Date version issued
+Дата публикации версии
: {ratification_date}
-Date created
+Дата создания
: {created_date}
-Part of TDWG Standard
+Часть стандарта TDWG
: <{standard_iri}>
-This version
+Текущая версия
: <{current_iri}{ratification_date}>
-Latest version
-: <{current_iri}>
+Последняя версия: {current_iri}
-{previous_version_slot}
+Предыдущая версия {previous_version_slot}
Abstract
: {abstract}
-Contributors
-: {contributors}
+Авторы: {contributors}
-Creator
-: {creator}
+Создатель:{creator}
-Bibliographic citation
-: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
+Библиографическая ссылка:{creator}. Год{year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
## 1 Introduction (informative)
This document includes terms intended to be used as controlled values for Audiovisual Core terms `Iptc4xmpExt:CVterm` and `ac:CVtermLiteral`.
-### 1.1 Status of the content of this document
+### 1.1 Статус содержания документа
Section 1 is informative (non-normative).
-Section 2 is normative.
+Раздел 2 является нормативным.
Section 3 is informative (non-normative).
-In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
+В разделе 4 значения `Термина IRI` и `Определения` являются нормативными. Значение `Использование` (если оно существует для данного термина) является нормативным. Значения `Term Name` не являются нормативными, хотя можно ожидать, что префикс сокращения пространства имен является одним из общепринятых префиксов, используемых для термина пространство имен. `Label` and the values of all other properties are non-normative.
-### 1.2 RFC 2119 key words
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
+### 1.2 Ключевые слова RFC 2119
-## 2 Use of Terms
+Ключевые слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY» и «OPTIONAL» в настоящем документе должны толковаться так, как это описано в [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) и [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) только тогда, когда они написаны заглавными буквами.
+
+## 2 Применение терминов
### 2.1 Relationship of value types to property terms
@@ -63,6 +60,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
-## 3 Term index
+## 3 Индексы терминов
diff --git a/code/cd-template/termlist-header.zh-Hans.md b/code/cd-template/termlist-header.zh-Hans.md
index 6cceaaf3..1c66d8b3 100644
--- a/code/cd-template/termlist-header.zh-Hans.md
+++ b/code/cd-template/termlist-header.zh-Hans.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -53,6 +53,7 @@ Section 3 is informative (non-normative).
In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
### 1.2 RFC 2119 key words
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
## 2 Use of Terms
@@ -63,6 +64,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
## 3 Term index
diff --git a/code/cd-template/termlist-header.zh-Hant.md b/code/cd-template/termlist-header.zh-Hant.md
index 6cceaaf3..5c7fa45b 100644
--- a/code/cd-template/termlist-header.zh-Hant.md
+++ b/code/cd-template/termlist-header.zh-Hant.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core Content Description: List of Terms
Namespace IRI
:
@@ -9,19 +9,18 @@ Namespace IRI
Preferred namespace abbreviation
: accd:
-Date version issued
+版本發行日期
: {ratification_date}
-Date created
-: {created_date}
+建立日期
-Part of TDWG Standard
+生物多樣性訊息標準的一部分
: <{standard_iri}>
-This version
+此版本
: <{current_iri}{ratification_date}>
-Latest version
+最新版本
: <{current_iri}>
{previous_version_slot}
@@ -29,33 +28,34 @@ Latest version
Abstract
: {abstract}
-Contributors
+貢獻者
: {contributors}
-Creator
+建立者
: {creator}
-Bibliographic citation
+書目引用
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
## 1 Introduction (informative)
This document includes terms intended to be used as controlled values for Audiovisual Core terms `Iptc4xmpExt:CVterm` and `ac:CVtermLiteral`.
-### 1.1 Status of the content of this document
+### 1.1 本文件內容的現況
Section 1 is informative (non-normative).
-Section 2 is normative.
+第 2 節為規範性。
Section 3 is informative (non-normative).
-In Section 4, the values of the `Term IRI`, `Definition`, and `Controlled value` are normative. The value of `Usage` (if it exists for a given term) is normative. The values of `Term Name` are non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. `Label` and the values of all other properties are non-normative.
+在第 4 節中,`Term IRI`、`Definition`和`Controlled value`的值為規範性。 `Usage`的值 (如果它存在於特定術語中) 為規範性。 `Term Name`的值為非規範性,不過可以預期命名空間縮寫是術語命名空間的常用前綴。 `Label` and the values of all other properties are non-normative.
-### 1.2 RFC 2119 key words
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) and [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
+### 1.2 RFC 2119 關鍵字
-## 2 Use of Terms
+關鍵字「必須」、「不得」、「要求」、「應」、「不應」、「應當」、「不應當」、「建議」、「可」、「可選」的定義,請參照[BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) 及 [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174) 所定義之含義,惟詞彙須以全大寫形式呈現時方適用。
+
+## 2 使用條款
### 2.1 Relationship of value types to property terms
@@ -63,6 +63,6 @@ In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/
### 2.2 Relationship between values of ac:CVtermLiteral and Iptc4xmpExt:CVterm
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
+An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `Iptc4xmpExt:CVterm` given a controlled value string for `ac:CVtermLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `Iptc4xmpExt:CVterm` property in cases where providers only provide values for `ac:CVtermLiteral`.
-## 3 Term index
+## 3 術語索引
diff --git a/code/format-template/termlist-header.ar.md b/code/format-template/termlist-header.ar.md
index cf4c48fc..33dfd7e8 100644
--- a/code/format-template/termlist-header.ar.md
+++ b/code/format-template/termlist-header.ar.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Contributors
: {contributors}
diff --git a/code/format-template/termlist-header.cs.md b/code/format-template/termlist-header.cs.md
index 56bf9b6f..d3ae5bf4 100644
--- a/code/format-template/termlist-header.cs.md
+++ b/code/format-template/termlist-header.cs.md
@@ -1,12 +1,11 @@
-# {document_title}
+# Řízený slovník pro formát Dublin Core: seznam termínů
-Title
-: {document_title}
+Název: Řízený slovník pro formát Dublin Core: seznam termínů
-Namespace IRI
+IRI jmenného prostoru
:
-Preferred namespace abbreviation
+Preferovaná zkratka jmenného prostoru
: acformat:
Datum vydání verze
@@ -26,8 +25,8 @@ Aktuální verze
{previous_version_slot}
-Abstract
-: {abstract}
+Abstrakt
+: Audiovisual Core přebírá termíny Dublin Core dc:format a dcterms:format, aby poskytoval informace o fyzickém nebo elektronickém formátu mediálního prvku. Tento řízený slovník poskytuje hodnoty pro tyto dva termíny.
Přispěvatelé
: {contributors}
@@ -38,19 +37,19 @@ Tvůrce
Bibliografická citace
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1 Úvod (informativní)
-This document includes terms intended to be used as a controlled value for Dublin Core terms `dc:format` and `dcterms:format`, which are borrowed by Audiovisual Core.
+Tento dokument obsahuje termíny, které mají být použity jako řízené hodnoty pro termíny Dublin Core `dc:format` a `dcterms:format`, které jsou převzaty z Audiovisual Core.
### 1.1 Status obsahu tohoto dokumentu
-Section 1 is informative (non-normative).
+Oddíl 1 je informativní (nenormativní).
-Section 2 is normative except as noted.
+Oddíl 2 je normativní, pokud není uvedeno jinak.
-Section 3 is informative.
+Oddíl 3 je informativní.
-V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. The values of `Has broader concept` and `Has exact match` are normative. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Label` and the values of all other properties are non-normative.
+V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnoty `Má širší pojem` a `Má přesnou shodu` jsou normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Štítek` a hodnoty všech ostatních vlastností nejsou normativní.
### 1.2 Klíčová slova RFC 2119
@@ -58,24 +57,24 @@ Klíčová slova "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
## 2 Použití termínů
-### 2.1 Relationship of value types to property terms
+### 2.1 Vztah hodnotových typů k pojmům vlastnictví
-In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/ac/doc/termlist/), unabbreviated term IRIs MUST be used as values of the property `dcterms:format`. Controlled value strings SHOULD be used as values of the property `dc:format`.
+V souladu s [dokumentem Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) MUSÍ být jako hodnoty vlastnosti `dcterms:format` použity nezkrácené termíny IRI. Jako hodnoty vlastnosti `dc:format` by se MĚLY používat řízené hodnotové řetězce.
-### 2.2 Relationship between concepts and concept schemes
+### 2.2 Vztah mezi pojmy a pojmovými schématy
-The entry for the property `dc:format` in the [Audiovisual Core term list document](http://rs.tdwg.org/ac/doc/termlist/#dc_format) specifies that three kinds of string values are RECOMMENDED: Internet Media Types (MIME types), special string values for physical media, or commonly used file extensions. This controlled vocabulary defines two SKOS concept schemes, a concept scheme for media types and physical media (the first two kinds of values specified for `dc:type`) and a concept scheme for file extensions (the last recommended kind of value). Because the Internet Assigned Numbers Authority (IANA) maintains a [registry of media types](https://www.iana.org/assignments/media-types/media-types.xhtml) and Audiovisual Core maintains a controlled list of physical media types, using values from the media types and physical media concept scheme is RECOMMENDED over the file extensions concept scheme.
+Záznam pro vlastnost `dc:format` v [dokumentu se seznamem základních audiovizuálních termínů](http://rs.tdwg.org/ac/doc/termlist/#dc_format) uvádí, že se DOPORUČUJÍ tři druhy řetězcových hodnot: typy internetových médií (typy MIME), speciální řetězcové hodnoty pro fyzická média nebo běžně používané přípony souborů. Tento řízený slovník definuje dvě schémata pojmů SKOS, schéma pojmů pro typy médií a fyzická média (první dva druhy hodnot specifikované pro `dc:type`) a schéma pojmů pro přípony souborů (poslední doporučený druh hodnoty). Protože organizace Internet Assigned Numbers Authority (IANA) vede [registr typů médií](https://www.iana.org/assignments/media-types/media-types.xhtml) a Audiovisual Core vede řízený seznam typů fyzických médií, DOPORUČUJE se používat hodnoty z koncepčního schématu typů médií a fyzických médií namísto koncepčního schématu přípon souborů.
-The concept scheme for media types and physical media defines a `skos:broader` relation between each specific media type or physical medium and one of the six [Top-level Media Types defined by RFC 2046](https://tools.ietf.org/html/rfc2046#page-4V) that are related to multimedia: application, audio, image, model, text, and video. This relation MAY be used by clients to infer the general category of the media item format.
+Koncepční schéma pro typy médií a fyzická média definuje vztah `skos:broader` mezi každým konkrétním typem média nebo fyzickým médiem a jedním ze šesti [typů médií nejvyšší úrovně definovaných v RFC 2046](https://tools.ietf.org/html/rfc2046#page-4V), které souvisejí s multimédii: aplikace, zvuk, obraz, model, text a video. Tento vztah MŮŽE být použit klienty k odvození obecné kategorie formátu mediálního prvku.
-The concept scheme for file extensions defines concepts for many common file extensions used for digital media files. These concepts are usually related to one of the media types and physical media by a `skos:exactMatch` relation. Metadata creators MAY use a controlled value from the file extensions concept scheme, but because of the asserted `skos:exactMatch` relation aggregators MAY substitute the equivalent value from the media types and physical media concept scheme.
+Koncepční schéma pro přípony souborů definuje pojmy pro mnoho běžných přípon souborů používaných pro soubory digitálních médií. Tyto pojmy jsou obvykle spojeny s jedním z typů médií a fyzickými médii pomocí relace `skos:exactMatch`. Tvůrci metadat MOHOU použít řízenou hodnotu ze schématu pojmů přípon souborů, ale kvůli deklarované relaci `skos:exactMatch` MOHOU agregátoři nahradit ekvivalentní hodnotu ze schématu pojmů typů médií a fyzických médií.
-### 2.3 Example workflows (non-normative)
+### 2.3 Příklady pracovních postupů (nenormativní)
-Workflow 1: A data provider uses spreadsheets containing a column for literal values for `dc:format`. The spreadsheets are populated with file extensions that are controlled string values from the concept scheme for file extensions. The spreadsheets are provided to an aggregator whose software "looks up" the controlled string values in the concept scheme for file extensions and determines the equivalent concepts from the concept scheme for media types and physical media. The IRIs from the concept scheme for media types and physical media are used as standardized values for `dcterms:format` in the aggregator's database.
+Pracovní postup 1: Poskytovatel dat používá tabulky obsahující sloupec pro doslovné hodnoty pro `dc:format`. Tabulky jsou vyplněny příponami souborů, které jsou řízenými hodnotami řetězců z koncepčního schématu pro přípony souborů. Tabulky jsou poskytovány agregátoru, jehož software „vyhledává“ kontrolované řetězcové hodnoty v koncepčním schématu pro přípony souborů a určuje ekvivalentní pojmy z koncepčního schématu pro typy médií a fyzická média. IRI z koncepčního schématu pro typy médií a fyzická média se používají jako standardizované hodnoty pro `dcterms:format` v databázi agregátoru.
-Workflow 2: A data aggregator acquires data about multimedia items that includes file names or URLs, but no format information. The aggregator extracts the file extensions from the files or URLs and uses the concept schemes to assign a `dcterms:format` IRI value from the concept scheme for media types and physical media to each item. In cases where an item has a file extension that does not correspond to one of the controlled value strings in the concept scheme for file extensions, the aggregator uses a community-maintained table of alternate file extension values to determine the appropriate format concept for the media item.
+Pracovní postup 2: Agregátor dat získává data o multimediálních položkách, která zahrnují názvy souborů nebo adresy URL, ale neobsahují informace o formátu. Agregátor extrahuje přípony souborů ze souborů nebo adres URL a pomocí schémat pojmů přiřadí každé položce hodnotu IRI `dcterms:format` ze schématu pojmů pro typy médií a fyzická média. V případech, kdy má položka příponu souboru, která neodpovídá žádné z kontrolovaných hodnot v koncepčním schématu pro přípony souborů, agregátor použije tabulku alternativních hodnot přípon souborů spravovanou komunitou k určení vhodného formátu pro danou mediální položku.
-Workflow 3: A data aggregator harvests media items from an open data repository. The remote server provides the media type via a `Content-Type` header and the file extension is determined from the file name. The aggregator cross-checks the media type value against the file extension value and uses the `skos:exactMatch` relations in the SKOS concept schemes to determine whether the values are consistent. Inconsistent pairs of values are flagged for manual checking. Previously unknown file extensions are flagged for additional research and possible inclusion in the community-maintained table of alternate file extension values.
+Pracovní postup 3: Agregátor dat shromažďuje mediální položky z otevřeného úložiště dat. Vzdálený server poskytuje typ média prostřednictvím hlavičky `Content-Type` a přípona souboru se určuje podle názvu souboru. Agregátor porovnává hodnotu typu média s hodnotou přípony souboru a pomocí vztahů `skos:exactMatch` v koncepčních schématech SKOS určuje, zda jsou hodnoty konzistentní. Nekonzistentní páry hodnot jsou označeny pro ruční kontrolu. Dosud neznámé přípony souborů jsou označeny pro další výzkum a možné zařazení do komunitou spravované tabulky alternativních hodnot přípon souborů.
## 3 Index termínů
diff --git a/code/format-template/termlist-header.de.md b/code/format-template/termlist-header.de.md
index cf4c48fc..33dfd7e8 100644
--- a/code/format-template/termlist-header.de.md
+++ b/code/format-template/termlist-header.de.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Contributors
: {contributors}
diff --git a/code/format-template/termlist-header.es.md b/code/format-template/termlist-header.es.md
index 9f3aa09b..e12a17f7 100644
--- a/code/format-template/termlist-header.es.md
+++ b/code/format-template/termlist-header.es.md
@@ -1,12 +1,12 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
-Title
-: {document_title}
+Título
+: Vocabulario Controlado para formato Dublin Core: Lista de términos
-Namespace IRI
+Espacio de nombres IRI
:
-Preferred namespace abbreviation
+Abreviatura preferida del espacio de nombres
: acformat:
Fecha de publicación de la versión
@@ -27,7 +27,7 @@ Esta versión
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Colaboradores
: {contributors}
@@ -38,19 +38,19 @@ Creador
Cita bibliográfica
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1. Introducción (Informativa)
-This document includes terms intended to be used as a controlled value for Dublin Core terms `dc:format` and `dcterms:format`, which are borrowed by Audiovisual Core.
+Este documento incluye términos destinados a ser utilizados como un valor controlado para los términos de Dublin Core «dc:format» y «dcterms:format», que son tomados prestados por Audiovisual Core.
### 1.1 Estado del contenido de este documento
-Section 1 is informative (non-normative).
+La Sección 1 es informativa (no normativa).
-Section 2 is normative except as noted.
+La Sección 2 es normativa salvo que se indique lo contrario.
-Section 3 is informative.
+La Sección 3 es informativa.
-En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. The values of `Has broader concept` and `Has exact match` are normative. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. `Label` and the values of all other properties are non-normative.
+En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. Los valores de `Tiene un concepto más amplio` y `Tiene coincidencia exacta` son normativos. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. La `Etiqueta` y los valores de todas las demás propiedades no son normativos.
### 1.2 Palabras clave RFC 2119
@@ -58,24 +58,24 @@ Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD
## 2 Uso de los Términos
-### 2.1 Relationship of value types to property terms
+### 2.1 Relación de los tipos de valor con los términos de propiedad
-In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/ac/doc/termlist/), unabbreviated term IRIs MUST be used as values of the property `dcterms:format`. Controlled value strings SHOULD be used as values of the property `dc:format`.
+De acuerdo con el [documento de la Lista de términos del Audiovisual Core](http://rs.tdwg.org/ac/doc/termlist/), los términos IRI no abreviados DEBEN usarse como valores de la propiedad `dcterms:format`. Las cadenas de valores controlados DEBEN usarse como valores de la propiedad `dc:format`.
-### 2.2 Relationship between concepts and concept schemes
+### 2.2 Relación entre conceptos y esquemas de conceptos
-The entry for the property `dc:format` in the [Audiovisual Core term list document](http://rs.tdwg.org/ac/doc/termlist/#dc_format) specifies that three kinds of string values are RECOMMENDED: Internet Media Types (MIME types), special string values for physical media, or commonly used file extensions. This controlled vocabulary defines two SKOS concept schemes, a concept scheme for media types and physical media (the first two kinds of values specified for `dc:type`) and a concept scheme for file extensions (the last recommended kind of value). Because the Internet Assigned Numbers Authority (IANA) maintains a [registry of media types](https://www.iana.org/assignments/media-types/media-types.xhtml) and Audiovisual Core maintains a controlled list of physical media types, using values from the media types and physical media concept scheme is RECOMMENDED over the file extensions concept scheme.
+La entrada para la propiedad `dc:format` en el [documento de lista de términos del núcleo audiovisual](http://rs.tdwg.org/ac/doc/termlist/#dc_format) especifica que se RECOMIENDAN tres tipos de valores de cadena: tipos de medios de Internet (tipos MIME), valores de cadena especiales para medios físicos o extensiones de archivo de uso común. Este vocabulario controlado define dos esquemas de conceptos SKOS: un esquema de conceptos para tipos de medios y medios físicos (los primeros dos tipos de valores especificados para `dc:type`) y un esquema de conceptos para extensiones de archivos (el último tipo de valor recomendado). Debido a que la Autoridad de Números Asignados de Internet (IANA) mantiene un [registro de tipos de medios](https://www.iana.org/assignments/media-types/media-types.xhtml) y Audiovisual Core mantiene una lista controlada de tipos de medios físicos, se RECOMIENDA utilizar valores del esquema de concepto de tipos de medios y medios físicos en lugar del esquema de concepto de extensiones de archivo.
-The concept scheme for media types and physical media defines a `skos:broader` relation between each specific media type or physical medium and one of the six [Top-level Media Types defined by RFC 2046](https://tools.ietf.org/html/rfc2046#page-4V) that are related to multimedia: application, audio, image, model, text, and video. This relation MAY be used by clients to infer the general category of the media item format.
+El esquema conceptual para los tipos de medios y medios físicos define una relación `skos:broader` entre cada tipo de medio específico o medio físico y uno de los seis [tipos de medios de nivel superior definidos por RFC 2046](https://tools.ietf.org/html/rfc2046#page-4V) que están relacionados con multimedia: aplicación, audio, imagen, modelo, texto y video. Esta relación PUEDE ser utilizada por usuarios para inferir la categoría general del formato del elemento multimedia.
-The concept scheme for file extensions defines concepts for many common file extensions used for digital media files. These concepts are usually related to one of the media types and physical media by a `skos:exactMatch` relation. Metadata creators MAY use a controlled value from the file extensions concept scheme, but because of the asserted `skos:exactMatch` relation aggregators MAY substitute the equivalent value from the media types and physical media concept scheme.
+El esquema conceptual para extensiones de archivos define conceptos para muchas extensiones de archivos comunes utilizadas en archivos multimedia digitales. Estos conceptos generalmente están relacionados con uno de los tipos de medios y medios físicos mediante una relación "skos:exactMatch". Los creadores de metadatos PUEDEN usar un valor controlado del esquema de concepto de extensiones de archivo, pero debido a la relación `skos:exactMatch` declarada, los agregadores PUEDEN sustituir el valor equivalente del esquema de concepto de tipos de medios y medios físicos.
-### 2.3 Example workflows (non-normative)
+### 2.3 Ejemplos de flujos de trabajo (no normativos)
-Workflow 1: A data provider uses spreadsheets containing a column for literal values for `dc:format`. The spreadsheets are populated with file extensions that are controlled string values from the concept scheme for file extensions. The spreadsheets are provided to an aggregator whose software "looks up" the controlled string values in the concept scheme for file extensions and determines the equivalent concepts from the concept scheme for media types and physical media. The IRIs from the concept scheme for media types and physical media are used as standardized values for `dcterms:format` in the aggregator's database.
+Flujo de trabajo 1: Un proveedor de datos utiliza hojas de cálculo que contienen una columna para valores literales para `dc:format`. Las hojas de cálculo se llenan con extensiones de archivo que son valores de cadena controlados desde el esquema de conceptos para extensiones de archivo. Las hojas de cálculo se proporcionan a un agregador cuyo software "busca" los valores de cadena controlados en el esquema de conceptos para extensiones de archivo y determina los conceptos equivalentes del esquema de conceptos para tipos de medios y medios físicos. Los IRI del esquema conceptual para tipos de medios y medios físicos se utilizan como valores estandarizados para `dcterms:format` en la base de datos del agregador.
-Workflow 2: A data aggregator acquires data about multimedia items that includes file names or URLs, but no format information. The aggregator extracts the file extensions from the files or URLs and uses the concept schemes to assign a `dcterms:format` IRI value from the concept scheme for media types and physical media to each item. In cases where an item has a file extension that does not correspond to one of the controlled value strings in the concept scheme for file extensions, the aggregator uses a community-maintained table of alternate file extension values to determine the appropriate format concept for the media item.
+Flujo de trabajo 2: Un agregador de datos adquiere datos sobre elementos multimedia que incluyen nombres de archivos o URL, pero ninguna información de formato. El agregador extrae las extensiones de archivo de los archivos o URL y utiliza los esquemas de concepto para asignar un valor IRI `dcterms:format` del esquema de concepto para tipos de medios y medios físicos a cada elemento. En los casos en que un elemento tiene una extensión de archivo que no corresponde a una de las cadenas de valores controlados en el esquema de conceptos para extensiones de archivo, el agregador utiliza una tabla de valores de extensión de archivo alternativos, mantenida por la comunidad, para determinar el concepto de formato apropiado para el elemento multimedia.
-Workflow 3: A data aggregator harvests media items from an open data repository. The remote server provides the media type via a `Content-Type` header and the file extension is determined from the file name. The aggregator cross-checks the media type value against the file extension value and uses the `skos:exactMatch` relations in the SKOS concept schemes to determine whether the values are consistent. Inconsistent pairs of values are flagged for manual checking. Previously unknown file extensions are flagged for additional research and possible inclusion in the community-maintained table of alternate file extension values.
+Flujo de trabajo 3: Un agregador de datos recopila elementos multimedia de un repositorio de datos abierto. El servidor remoto proporciona el tipo de medio a través de un encabezado `Content-Type` y la extensión del archivo se determina a partir del nombre del archivo. El agregador verifica el valor del tipo de medio con el valor de la extensión del archivo y utiliza las relaciones `skos:exactMatch` en los esquemas de conceptos de SKOS para determinar si los valores son consistentes. Los pares de valores inconsistentes se marcan para verificación manual. Las extensiones de archivos previamente desconocidas se marcan para investigación adicional y posible inclusión en la tabla de valores de extensiones de archivos alternativos mantenida por la comunidad.
## 3 Índice de Términos
diff --git a/code/format-template/termlist-header.fr.md b/code/format-template/termlist-header.fr.md
index 8fe13160..b3d6d836 100644
--- a/code/format-template/termlist-header.fr.md
+++ b/code/format-template/termlist-header.fr.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ Version précédente
: {previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Contributeurs
: {contributors}
diff --git a/code/format-template/termlist-header.ja.md b/code/format-template/termlist-header.ja.md
index 2361adee..51f7893f 100644
--- a/code/format-template/termlist-header.ja.md
+++ b/code/format-template/termlist-header.ja.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ TDWG標準での該当箇所
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
貢献者
: {contributors}
diff --git a/code/format-template/termlist-header.km.md b/code/format-template/termlist-header.km.md
index cf4c48fc..33dfd7e8 100644
--- a/code/format-template/termlist-header.km.md
+++ b/code/format-template/termlist-header.km.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Contributors
: {contributors}
diff --git a/code/format-template/termlist-header.ko.md b/code/format-template/termlist-header.ko.md
index cf4c48fc..33dfd7e8 100644
--- a/code/format-template/termlist-header.ko.md
+++ b/code/format-template/termlist-header.ko.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Contributors
: {contributors}
diff --git a/code/format-template/termlist-header.nl.md b/code/format-template/termlist-header.nl.md
index cf4c48fc..33dfd7e8 100644
--- a/code/format-template/termlist-header.nl.md
+++ b/code/format-template/termlist-header.nl.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Contributors
: {contributors}
diff --git a/code/format-template/termlist-header.pt.md b/code/format-template/termlist-header.pt.md
index cf4c48fc..33dfd7e8 100644
--- a/code/format-template/termlist-header.pt.md
+++ b/code/format-template/termlist-header.pt.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Contributors
: {contributors}
diff --git a/code/format-template/termlist-header.ru.md b/code/format-template/termlist-header.ru.md
index a5370ca2..63bb3c96 100644
--- a/code/format-template/termlist-header.ru.md
+++ b/code/format-template/termlist-header.ru.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
Предыдущая версия {previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Авторы: {contributors}
diff --git a/code/format-template/termlist-header.zh-Hans.md b/code/format-template/termlist-header.zh-Hans.md
index cf4c48fc..33dfd7e8 100644
--- a/code/format-template/termlist-header.zh-Hans.md
+++ b/code/format-template/termlist-header.zh-Hans.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
Contributors
: {contributors}
diff --git a/code/format-template/termlist-header.zh-Hant.md b/code/format-template/termlist-header.zh-Hant.md
index 67d977ea..e99bb077 100644
--- a/code/format-template/termlist-header.zh-Hant.md
+++ b/code/format-template/termlist-header.zh-Hant.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Dublin Core format: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Dublin Core format: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core borrows the Dublin Core terms dc:format and dcterms:format to provide information about the physical or electronic format of a media item. This controlled vocabulary provides values for those two terms.
貢獻者
: {contributors}
diff --git a/code/orient-template/termlist-header.ar.md b/code/orient-template/termlist-header.ar.md
index b412e2f2..6c74bb12 100644
--- a/code/orient-template/termlist-header.ar.md
+++ b/code/orient-template/termlist-header.ar.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Contributors
: {contributors}
diff --git a/code/orient-template/termlist-header.cs.md b/code/orient-template/termlist-header.cs.md
index f22063c7..04bdaa59 100644
--- a/code/orient-template/termlist-header.cs.md
+++ b/code/orient-template/termlist-header.cs.md
@@ -1,12 +1,12 @@
-# {document_title}
+# Řízený slovník pro Audiovisual Core subjectOrientation: Seznam termínů
-Title
-: {document_title}
+Název
+: Řízený slovník pro Audiovisual Core subjectOrientation: Seznam termínů
-Namespace IRI
+IRI Jmenného prostoru
:
-Preferred namespace abbreviation
+Preferovaná zkratka jmenného prostoru
: acorient:
Datum vydání verze
@@ -26,8 +26,8 @@ Aktuální verze
{previous_version_slot}
-Abstract
-: {abstract}
+Abstrakt
+: Termín subjectOrientation z Audiovisual Core popisuje orientaci pohledu vzhledem k organismu nebo části organismu zobrazenému v mediálním prvku nebo oblasti zájmu. Řízený slovník termínů subjectOrientation obsahuje termíny, které by měly být použity jako hodnoty pro ac:subjectOrientation a jeho doslovný ekvivalent ac:subjectOrientationLiteral.
Přispěvatelé
: {contributors}
@@ -38,40 +38,40 @@ Tvůrce
Bibliografická citace
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1 Úvod (informativní)
-This document includes terms intended to be used as controlled values for the Audiovisual Core terms `ac:subjectOrientation` and `ac:subjectOrientationLiteral`. A [JSON-LD representation](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient.json) (including translations to multiple languages) of this SKOS Concept Scheme is available. For more information about how to use this vocabulary, see the [subjectPart and subjectOrientation Controlled Vocabularies User Guide](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
+Tento dokument obsahuje termíny, které mají být použity jako řízené hodnoty pro Audiovisual Core termíny `ac:subjectOrientation` a `ac:subjectOrientationLiteral`. K dispozici je [JSON-LD reprezentace](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient.json) (včetně překladů do více jazyků) tohoto schématu pojmů SKOS. Další informace o používání této slovní zásoby naleznete v [uživatelské příručce k řízeným slovníkům subjectPart a subjectOrientation](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
### 1.1 Status obsahu tohoto dokumentu
-Section 1 is informative (non-normative).
+Oddíl 1 je informativní (nenormativní).
-Section 2 is normative except as noted.
+Oddíl 2 je normativní, pokud není uvedeno jinak.
-Section 3 is informative.
+Oddíl 3 je informativní.
-V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnota `Má širší pojem` je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Label` and the values of all other properties (such as `Examples` or `Notes`) are non-normative.
+V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnota `Má širší pojem` je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Štítek` a hodnoty všech ostatních vlastností (například `Příklady` nebo `Poznámky`) nejsou normativní.
### 1.2 Klíčová slova RFC 2119
Klíčová slova "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" a "OPTIONAL" v tomto dokumentu je třeba interpretovat tak, jak je popsáno v [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) a [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174), pokud a pouze pokud jsou uvedena velkými písmeny, jak je uvedeno zde.
-### 1.3 User feedback reports
+### 1.3 Hodnocení od uživatelů
-For perspective on the development of this [vocabulary enhancement](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements), refer to the [final Feature Report](https://github.com/tdwg/ac/blob/master/views/final-requirements.md) used to determine the requirements for the vocabulary. The Implementation Experience Report was published in _Biodiversity Information Science and Standards_ 7:e94188 and is available at
+Pro přehled o vývoji tohoto [rozšíření slovníku](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements) se podívejte na [závěrečnou zprávu o funkcích](https://github.com/tdwg/ac/blob/master/views/ final-requirements.md), která byla použita k určení požadavků na slovník. Zpráva o zkušenostech s implementací byla publikována v časopise _Biodiversity Information Science and Standards_ 7:e94188 a je k dispozici na
## 2 Použití termínů
-### 2.1 Relationship of value types to property terms
+### 2.1 Vztah hodnotových typů k pojmům vlastnictví
-In accordance with the [Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) document, unabbreviated term IRIs MUST be used as values of the property `ac:subjectOrientation`. Controlled value strings SHOULD be used as values of the property `ac:subjectOrientationLiteral`.
+V souladu s dokumentem [Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) MUSÍ být jako hodnoty vlastnosti `ac:subjectOrientation` použity nezkrácené termíny IRI. Jako hodnoty vlastnosti `ac:subjectOrientationLiteral` by se MĚLY používat řízené hodnotové řetězce.
-### 2.2 Relationships with other concept schemes and collections (informative)
+### 2.2 Vztahy k jiným koncepčním schématům a sbírkám (informativní)
-Particular `ac:subjectOrientation` values are appropriate for some `ac:subjectPart` values. The relationships between concepts in these two schemes are described by a [JSON-LD serialized SKOS Collection for each subject part](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient_collection.json) that designates which subject orientations are appropriate for that part. Similarly, [JSON-LD serialized SKOS Collections have been established for some organism groups](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart_collection.json) to indicate which subject parts exist for members of those groups. These collections are provided to aid application developers in filtering the concepts that should be presented to users and they may also be used for validation.
+Konkrétní hodnoty `ac:subjectOrientation` jsou vhodné pro některé hodnoty `ac:subjectPart`. Vztahy mezi pojmy v těchto dvou schématech jsou popsány pomocí [JSON-LD serializované SKOS kolekce pro každou část předmětu](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient_collection.json), která určuje, které orientace předmětu jsou pro danou část vhodné. Podobně byly [pro některé skupiny organismů vytvořeny serializované SKOS kolekce JSON-LD](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart_collection.json), které označují, které části předmětu existují pro členy těchto skupin. Tyto sbírky jsou poskytovány s cílem pomoci vývojářům aplikací při filtrování pojmů, které by měly být uživatelům prezentovány, a mohou být také použity pro ověřování.
-Human-readable collection lists of controlled value strings are available for [subjectPart](https://ac.tdwg.org/part_collections) and [subjectOrientation](https://ac.tdwg.org/orient_collections).
+Seznamy řízených hodnotových řetězců, které jsou čitelné pro člověka, jsou k dispozici pro [subjectPart](https://ac.tdwg.org/part_collections) a [subjectOrientation](https://ac.tdwg.org/orient_collections).
-Neither of these Collections are normative and they are maintained outside of the Audiovisual Core standards framework in order to make their development agile.
+Žádná z těchto sbírek není normativní a jsou spravovány mimo rámec standardů Audiovisual Core, aby byl jejich vývoj agilní.
## 3 Index termínů
diff --git a/code/orient-template/termlist-header.de.md b/code/orient-template/termlist-header.de.md
index b412e2f2..6c74bb12 100644
--- a/code/orient-template/termlist-header.de.md
+++ b/code/orient-template/termlist-header.de.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Contributors
: {contributors}
diff --git a/code/orient-template/termlist-header.es.md b/code/orient-template/termlist-header.es.md
index 9e0c58fc..c62d06a2 100644
--- a/code/orient-template/termlist-header.es.md
+++ b/code/orient-template/termlist-header.es.md
@@ -1,13 +1,12 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
-Namespace IRI
+IRI del espacio de nombres
:
-Preferred namespace abbreviation
-: acorient:
+Abreviatura preferida del espacio de nombres: acorient:
Fecha de publicación de la versión
: {ratification_date}
@@ -27,7 +26,7 @@ Esta versión
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Colaboradores
: {contributors}
@@ -38,40 +37,40 @@ Creador
Cita bibliográfica
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1. Introducción (Informativa)
-This document includes terms intended to be used as controlled values for the Audiovisual Core terms `ac:subjectOrientation` and `ac:subjectOrientationLiteral`. A [JSON-LD representation](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient.json) (including translations to multiple languages) of this SKOS Concept Scheme is available. For more information about how to use this vocabulary, see the [subjectPart and subjectOrientation Controlled Vocabularies User Guide](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
+Este documento incluye términos destinados a ser utilizados como valores controlados para los términos del Audiovisual Core `ac:subjectOrientation` y `ac:subjectOrientationLiteral`. Está disponible una [representación JSON-LD](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient.json) de este esquema de concepto SKOS (incluyendo traducciones a varios idiomas). Para más información sobre cómo utilizar este vocabulario, consulte la [guía del usuario de vocabularios controlados subjectPart y subjectOrientation](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
### 1.1 Estado del contenido de este documento
-Section 1 is informative (non-normative).
+La Sección 1 es informativa (no normativa).
-Section 2 is normative except as noted.
+La Sección 2 es normativa salvo que se indique lo contrario.
-Section 3 is informative.
+La Sección 3 es informativa.
-En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. El valor de `tiene un concepto más amplio` es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. `Label` and the values of all other properties (such as `Examples` or `Notes`) are non-normative.
+En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. El valor de `tiene un concepto más amplio` es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. `Etiqueta` y los valores de todas las demás propiedades (como `Ejemplos` o `Notas`) no son normativos.
### 1.2 Palabras clave RFC 2119
Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" y "OPTIONAL" en este documento deben interpretarse como se describe en [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) y [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174), únicamente cuando aparezcan en mayúsculas, tal como se muestra aquí.
-### 1.3 User feedback reports
+### 1.3 Reportes de comentarios de los usuarios
-For perspective on the development of this [vocabulary enhancement](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements), refer to the [final Feature Report](https://github.com/tdwg/ac/blob/master/views/final-requirements.md) used to determine the requirements for the vocabulary. The Implementation Experience Report was published in _Biodiversity Information Science and Standards_ 7:e94188 and is available at
+Para obtener una perspectiva sobre el desarrollo de esta [mejora de vocabulario](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements), consulte el [Informe de requerimientos finales](https://github.com/tdwg/ac/blob/master/views/final-requirements.md) utilizado para determinar los requisitos del vocabulario. El Informe sobre la Experiencia de Implementación se publicó en _Biodiversity Information Science and Standards_ 7:e94188 y está disponible en
## 2 Uso de los Términos
-### 2.1 Relationship of value types to property terms
+### 2.1 Relación de los tipos de valor con los términos de propiedad
-In accordance with the [Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) document, unabbreviated term IRIs MUST be used as values of the property `ac:subjectOrientation`. Controlled value strings SHOULD be used as values of the property `ac:subjectOrientationLiteral`.
+De acuerdo con el documento [Lista de términos del Audiovisual Core](http://rs.tdwg.org/ac/doc/termlist/), los IRI de los términos no abreviados DEBEN usarse como valores de la propiedad `ac:subjectOrientation`. Las cadenas de valores controlados DEBEN usarse como valores de la propiedad `ac:subjectOrientationLiteral`.
-### 2.2 Relationships with other concept schemes and collections (informative)
+### 2.2 Relaciones con otros esquemas conceptuales y colecciones (informativo)
-Particular `ac:subjectOrientation` values are appropriate for some `ac:subjectPart` values. The relationships between concepts in these two schemes are described by a [JSON-LD serialized SKOS Collection for each subject part](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient_collection.json) that designates which subject orientations are appropriate for that part. Similarly, [JSON-LD serialized SKOS Collections have been established for some organism groups](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart_collection.json) to indicate which subject parts exist for members of those groups. These collections are provided to aid application developers in filtering the concepts that should be presented to users and they may also be used for validation.
+Algunos valores particulares de `ac:subjectOrientation` son apropiados para algunos valores de `ac:subjectPart`. Las relaciones entre los conceptos en estos dos esquemas se describen mediante una [Colección SKOS serializada JSON-LD para cada parte del sujeto](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient_collection.json) que designa qué orientaciones temáticas son apropiadas para esa parte. De manera similar, [se han establecido colecciones SKOS serializadas JSON-LD para algunos grupos de organismos](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart_collection.json) para indicar qué partes del sujeto existen para los miembros de esos grupos. Estas colecciones se proporcionan para ayudar a los desarrolladores de aplicaciones a filtrar los conceptos que deben presentarse a los usuarios y también pueden usarse para la validación.
-Human-readable collection lists of controlled value strings are available for [subjectPart](https://ac.tdwg.org/part_collections) and [subjectOrientation](https://ac.tdwg.org/orient_collections).
+Hay disponibles listas de colecciones legibles por humanos de cadenas de valores controlados para [subjectPart](https://ac.tdwg.org/part_collections) y [subjectOrientation](https://ac.tdwg.org/orient_collections).
-Neither of these Collections are normative and they are maintained outside of the Audiovisual Core standards framework in order to make their development agile.
+Ninguna de estas colecciones es normativa y se mantienen fuera del marco de estándares del Audiovisual Core para agilizar su desarrollo.
## 3 Índice de Términos
diff --git a/code/orient-template/termlist-header.fr.md b/code/orient-template/termlist-header.fr.md
index f53a5ca9..fdfe01bc 100644
--- a/code/orient-template/termlist-header.fr.md
+++ b/code/orient-template/termlist-header.fr.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ Version précédente
: {previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Contributeurs
: {contributors}
diff --git a/code/orient-template/termlist-header.ja.md b/code/orient-template/termlist-header.ja.md
index 4a02d907..66e93f89 100644
--- a/code/orient-template/termlist-header.ja.md
+++ b/code/orient-template/termlist-header.ja.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ TDWG標準での該当箇所
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
貢献者
: {contributors}
diff --git a/code/orient-template/termlist-header.km.md b/code/orient-template/termlist-header.km.md
index b412e2f2..6c74bb12 100644
--- a/code/orient-template/termlist-header.km.md
+++ b/code/orient-template/termlist-header.km.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Contributors
: {contributors}
diff --git a/code/orient-template/termlist-header.ko.md b/code/orient-template/termlist-header.ko.md
index b412e2f2..6c74bb12 100644
--- a/code/orient-template/termlist-header.ko.md
+++ b/code/orient-template/termlist-header.ko.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Contributors
: {contributors}
diff --git a/code/orient-template/termlist-header.nl.md b/code/orient-template/termlist-header.nl.md
index b412e2f2..6c74bb12 100644
--- a/code/orient-template/termlist-header.nl.md
+++ b/code/orient-template/termlist-header.nl.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Contributors
: {contributors}
diff --git a/code/orient-template/termlist-header.pt.md b/code/orient-template/termlist-header.pt.md
index b412e2f2..cdd144c1 100644
--- a/code/orient-template/termlist-header.pt.md
+++ b/code/orient-template/termlist-header.pt.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Contributors
: {contributors}
@@ -40,7 +40,7 @@ Bibliographic citation
## 1 Introduction (informative)
-This document includes terms intended to be used as controlled values for the Audiovisual Core terms `ac:subjectOrientation` and `ac:subjectOrientationLiteral`. A [JSON-LD representation](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient.json) (including translations to multiple languages) of this SKOS Concept Scheme is available. For more information about how to use this vocabulary, see the [subjectPart and subjectOrientation Controlled Vocabularies User Guide](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
+This document includes terms intended to be used as controlled values for the Audiovisual Core terms `ac:subjectOrientation` and `ac:subjectOrientationLiteral`. A [JSON-LD representation](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient.json) (including translations to multiple languages) of this SKOS Concept Scheme is available. Para maiores informações sobre como utilizar este vocabulário, veja [o Guia de Usuário para Vocabulários Controlados subjectPart e subjectOrientation](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
### 1.1 Status of the content of this document
diff --git a/code/orient-template/termlist-header.ru.md b/code/orient-template/termlist-header.ru.md
index 3f3d1451..a88d2e6a 100644
--- a/code/orient-template/termlist-header.ru.md
+++ b/code/orient-template/termlist-header.ru.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
Предыдущая версия {previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Авторы: {contributors}
diff --git a/code/orient-template/termlist-header.zh-Hans.md b/code/orient-template/termlist-header.zh-Hans.md
index b412e2f2..6c74bb12 100644
--- a/code/orient-template/termlist-header.zh-Hans.md
+++ b/code/orient-template/termlist-header.zh-Hans.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
Contributors
: {contributors}
diff --git a/code/orient-template/termlist-header.zh-Hant.md b/code/orient-template/termlist-header.zh-Hant.md
index 79e28c56..31349565 100644
--- a/code/orient-template/termlist-header.zh-Hant.md
+++ b/code/orient-template/termlist-header.zh-Hant.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectOrientation: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectOrientation describes the viewing orientation relative to an organism or part of an organism depicted in a media item or region of interest. The subjectOrientation Controlled Vocabulary provides terms that should be used as values for ac:subjectOrientation and its literal-valued analog ac:subjectOrientationLiteral.
貢獻者
: {contributors}
diff --git a/code/part-template/termlist-header.ar.md b/code/part-template/termlist-header.ar.md
index 7384993d..48cfe27c 100644
--- a/code/part-template/termlist-header.ar.md
+++ b/code/part-template/termlist-header.ar.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Contributors
: {contributors}
diff --git a/code/part-template/termlist-header.cs.md b/code/part-template/termlist-header.cs.md
index 567251f8..679f4cd5 100644
--- a/code/part-template/termlist-header.cs.md
+++ b/code/part-template/termlist-header.cs.md
@@ -1,12 +1,12 @@
-# {document_title}
+# Řízený slovník pro Audiovisual Core subjectPart: Seznam termínů
-Title
-: {document_title}
+Název
+: Řízený slovník pro Audiovisual Core subjectPart: Seznam termínů
-Namespace IRI
+IRI Jmenného prostoru
:
-Preferred namespace abbreviation
+Preferovaná zkratka jmenného prostoru
: acpart:
Datum vydání verze
@@ -26,8 +26,8 @@ Aktuální verze
{previous_version_slot}
-Abstract
-: {abstract}
+Abstrakt
+: Termín subjectPart z Audiovisual Core popisuje část morfologie organismu, chování, prostředí zobrazenou v mediálním obsahu nebo oblasti zájmu. Předmětová část řízeného slovníku poskytuje termíny, které by měly být použity jako hodnoty pro ac:subjectPart a jeho doslovný ekvivalent ac:subjectPartLiteral.
Přispěvatelé
: {contributors}
@@ -38,40 +38,40 @@ Tvůrce
Bibliografická citace
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1 Úvod (informativní)
-This document includes terms intended to be used as controlled values for the Audiovisual Core terms `ac:subjectPart` and `ac:subjectPartLiteral`. A [JSON-LD representation](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart.json) (including translations to multiple languages) of this SKOS Concept Scheme is available. For more information about how to use this vocabulary, see the [subjectPart and subjectOrientation Controlled Vocabularies User Guide](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
+Tento dokument obsahuje termíny, které mají být použity jako kontrolované hodnoty pro audiovizuální základní termíny `ac:subjectPart` a `ac:subjectPartLiteral`. K dispozici je [JSON-LD reprezentace](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart.json) (včetně překladů do více jazyků) tohoto schématu pojmů SKOS. Další informace o používání této slovní zásoby naleznete v [uživatelské příručce k řízeným slovníkům subjectPart a subjectOrientation](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
### 1.1 Status obsahu tohoto dokumentu
-Section 1 is informative (non-normative).
+Oddíl 1 je informativní (nenormativní).
-Section 2 is normative except as noted.
+Oddíl 2 je normativní, pokud není uvedeno jinak.
-Section 3 is informative.
+Oddíl 3 je informativní.
-V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnota `Má širší pojem` je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Label` and the values of all other properties (such as `Examples` or `Notes`) are non-normative.
+V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnota `Má širší pojem` je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Štítek` a hodnoty všech ostatních vlastností (například `Příklady` nebo `Poznámky`) nejsou normativní.
### 1.2 Klíčová slova RFC 2119
Klíčová slova "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" a "OPTIONAL" v tomto dokumentu je třeba interpretovat tak, jak je popsáno v [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) a [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174), pokud a pouze pokud jsou uvedena velkými písmeny, jak je uvedeno zde.
-### 1.3 User feedback reports
+### 1.3 Hodnocení od uživatelů
-For perspective on the development of this [vocabulary enhancement](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements), refer to the [final Feature Report](https://github.com/tdwg/ac/blob/master/views/final-requirements.md) used to determine the requirements for the vocabulary. The Implementation Experience Report was published in _Biodiversity Information Science and Standards_ 7:e94188 and is available at
+Pro přehled o vývoji tohoto [rozšíření slovníku](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements) se podívejte na [závěrečnou zprávu o funkcích](https://github.com/tdwg/ac/blob/master/views/ final-requirements.md), která byla použita k určení požadavků na slovník. Zpráva o zkušenostech s implementací byla publikována v časopise _Biodiversity Information Science and Standards_ 7:e94188 a je k dispozici na
## 2 Použití termínů
-### 2.1 Relationship of value types to property terms
+### 2.1 Vztah hodnotových typů k pojmům vlastnictví
-In accordance with the [Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) document, unabbreviated term IRIs MUST be used as values of the property `ac:subjectPart`. Controlled value strings SHOULD be used as values of the property `ac:subjectPartLiteral`.
+V souladu s dokumentem [Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) MUSÍ být jako hodnoty vlastnosti `ac:subjectPart` použity nezkrácené termíny IRI. Jako hodnoty vlastnosti `ac:subjectPartLiteral` by se MĚLY používat řízené hodnotové řetězce.
-### 2.2 Relationships with other concept schemes and collections (informative)
+### 2.2 Vztahy k jiným koncepčním schématům a sbírkám (informativní)
-Particular `ac:subjectOrientation` values are appropriate for some `ac:subjectPart` values. The relationships between concepts in these two schemes are described by a [JSON-LD serialized SKOS Collection for each subject part](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient_collection.json) that designates which subject orientations are appropriate for that part. Similarly, [JSON-LD serialized SKOS Collections have been established for some organism groups](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart_collection.json) to indicate which subject parts exist for members of those groups. These collections are provided to aid application developers in filtering the concepts that should be presented to users and they may also be used for validation.
+Konkrétní hodnoty `ac:subjectOrientation` jsou vhodné pro některé hodnoty `ac:subjectPart`. Vztahy mezi pojmy v těchto dvou schématech jsou popsány pomocí [JSON-LD serializované SKOS kolekce pro každou část předmětu](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient_collection.json), která určuje, které orientace předmětu jsou pro danou část vhodné. Podobně byly [pro některé skupiny organismů vytvořeny serializované SKOS kolekce JSON-LD](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart_collection.json), které označují, které části předmětu existují pro členy těchto skupin. Tyto sbírky jsou poskytovány s cílem pomoci vývojářům aplikací při filtrování pojmů, které by měly být uživatelům prezentovány, a mohou být také použity pro ověřování.
-Human-readable collection lists of controlled value strings are available for [subjectPart](https://ac.tdwg.org/part_collections) and [subjectOrientation](https://ac.tdwg.org/orient_collections).
+Seznamy řízených hodnotových řetězců, které jsou čitelné pro člověka, jsou k dispozici pro [subjectPart](https://ac.tdwg.org/part_collections) a [subjectOrientation](https://ac.tdwg.org/orient_collections).
-Neither of these Collections are normative and they are maintained outside of the Audiovisual Core standards framework in order to make their development agile.
+Žádná z těchto sbírek není normativní a jsou spravovány mimo rámec standardů Audiovisual Core, aby byl jejich vývoj agilní.
## 3 Index termínů
diff --git a/code/part-template/termlist-header.de.md b/code/part-template/termlist-header.de.md
index 7384993d..48cfe27c 100644
--- a/code/part-template/termlist-header.de.md
+++ b/code/part-template/termlist-header.de.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Contributors
: {contributors}
diff --git a/code/part-template/termlist-header.es.md b/code/part-template/termlist-header.es.md
index a0ca4c96..a7eb5394 100644
--- a/code/part-template/termlist-header.es.md
+++ b/code/part-template/termlist-header.es.md
@@ -1,12 +1,12 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
-Namespace IRI
+IRI del espacio de nombres
:
-Preferred namespace abbreviation
+Abreviatura de espacio de nombres preferida
: acpart:
Fecha de publicación de la versión
@@ -27,7 +27,7 @@ Esta versión
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Colaboradores
: {contributors}
@@ -38,40 +38,40 @@ Creador
Cita bibliográfica
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1. Introducción (Informativa)
-This document includes terms intended to be used as controlled values for the Audiovisual Core terms `ac:subjectPart` and `ac:subjectPartLiteral`. A [JSON-LD representation](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart.json) (including translations to multiple languages) of this SKOS Concept Scheme is available. For more information about how to use this vocabulary, see the [subjectPart and subjectOrientation Controlled Vocabularies User Guide](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
+Este documento incluye términos destinados a ser utilizados como valores controlados para los términos del Audiovisual Core `ac:subjectPart` y `ac:subjectPartLiteral`. Una [representación JSON-LD](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart.json) de este esquema de concepto SKOS está disponible (incluyendo traducciones a varios idiomas). Para más información sobre cómo utilizar este vocabulario, consulte la [guía del usuario de vocabularios controlados subjectPart y subjectOrientation](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
### 1.1 Estado del contenido de este documento
-Section 1 is informative (non-normative).
+La Sección 1 es informativa (no normativa).
-Section 2 is normative except as noted.
+La Sección 2 es normativa salvo que se indique lo contrario.
-Section 3 is informative.
+La Sección 3 es informativa.
-En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. El valor de `tiene un concepto más amplio` es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. `Label` and the values of all other properties (such as `Examples` or `Notes`) are non-normative.
+En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. El valor de `tiene un concepto más amplio` es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. `Etiqueta` y los valores de todas las demás propiedades (como `Ejemplos` o `Notas`) no son normativos.
### 1.2 Palabras clave RFC 2119
Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" y "OPTIONAL" en este documento deben interpretarse como se describe en [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) y [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174), únicamente cuando aparezcan en mayúsculas, tal como se muestra aquí.
-### 1.3 User feedback reports
+### 1.3 Reportes de comentarios de los usuarios
-For perspective on the development of this [vocabulary enhancement](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements), refer to the [final Feature Report](https://github.com/tdwg/ac/blob/master/views/final-requirements.md) used to determine the requirements for the vocabulary. The Implementation Experience Report was published in _Biodiversity Information Science and Standards_ 7:e94188 and is available at
+Para obtener una perspectiva sobre el desarrollo de esta [mejora de vocabulario](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements), consulte el [Informe de requerimientos finales](https://github.com/tdwg/ac/blob/master/views/final-requirements.md) utilizado para determinar los requisitos del vocabulario. El Informe sobre la Experiencia de Implementación se publicó en _Biodiversity Information Science and Standards_ 7:e94188 y está disponible en
## 2 Uso de los Términos
-### 2.1 Relationship of value types to property terms
+### 2.1 Relación de los tipos de valor con los términos de propiedad
-In accordance with the [Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) document, unabbreviated term IRIs MUST be used as values of the property `ac:subjectPart`. Controlled value strings SHOULD be used as values of the property `ac:subjectPartLiteral`.
+De acuerdo con el documento [Lista de términos del Audiovisual Core](http://rs.tdwg.org/ac/doc/termlist/), los IRI de los términos no abreviados DEBEN usarse como valores de la propiedad `ac:subjectOrientation`. Las cadenas de valores controlados DEBEN usarse como valores de la propiedad `ac:subjectOrientationLiteral`.
-### 2.2 Relationships with other concept schemes and collections (informative)
+### 2.2 Relaciones con otros esquemas conceptuales y colecciones (informativo)
-Particular `ac:subjectOrientation` values are appropriate for some `ac:subjectPart` values. The relationships between concepts in these two schemes are described by a [JSON-LD serialized SKOS Collection for each subject part](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient_collection.json) that designates which subject orientations are appropriate for that part. Similarly, [JSON-LD serialized SKOS Collections have been established for some organism groups](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart_collection.json) to indicate which subject parts exist for members of those groups. These collections are provided to aid application developers in filtering the concepts that should be presented to users and they may also be used for validation.
+Algunos valores particulares de `ac:subjectOrientation` son apropiados para algunos valores de `ac:subjectPart`. Las relaciones entre los conceptos en estos dos esquemas se describen mediante una [Colección SKOS serializada JSON-LD para cada parte del sujeto](https://tdwg.github.io/rs.tdwg.org/cvJson/acorient_collection.json) que designa qué orientaciones temáticas son apropiadas para esa parte. De manera similar, [se han establecido colecciones SKOS serializadas JSON-LD para algunos grupos de organismos](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart_collection.json) para indicar qué partes del sujeto existen para los miembros de esos grupos. Estas colecciones se proporcionan para ayudar a los desarrolladores de aplicaciones a filtrar los conceptos que deben presentarse a los usuarios y también pueden usarse para la validación.
-Human-readable collection lists of controlled value strings are available for [subjectPart](https://ac.tdwg.org/part_collections) and [subjectOrientation](https://ac.tdwg.org/orient_collections).
+Hay disponibles listas de colecciones legibles por humanos de cadenas de valores controlados para [subjectPart](https://ac.tdwg.org/part_collections) y [subjectOrientation](https://ac.tdwg.org/orient_collections).
-Neither of these Collections are normative and they are maintained outside of the Audiovisual Core standards framework in order to make their development agile.
+Ninguna de estas colecciones es normativa y se mantienen fuera del marco de estándares del Audiovisual Core para agilizar su desarrollo.
## 3 Índice de Términos
diff --git a/code/part-template/termlist-header.fr.md b/code/part-template/termlist-header.fr.md
index 346a63a9..201fec09 100644
--- a/code/part-template/termlist-header.fr.md
+++ b/code/part-template/termlist-header.fr.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ Version précédente
: {previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Contributeurs
: {contributors}
diff --git a/code/part-template/termlist-header.ja.md b/code/part-template/termlist-header.ja.md
index 133d69df..cc18bb16 100644
--- a/code/part-template/termlist-header.ja.md
+++ b/code/part-template/termlist-header.ja.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ TDWG標準での該当箇所
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
貢献者
: {contributors}
diff --git a/code/part-template/termlist-header.km.md b/code/part-template/termlist-header.km.md
index 7384993d..48cfe27c 100644
--- a/code/part-template/termlist-header.km.md
+++ b/code/part-template/termlist-header.km.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Contributors
: {contributors}
diff --git a/code/part-template/termlist-header.ko.md b/code/part-template/termlist-header.ko.md
index 7384993d..48cfe27c 100644
--- a/code/part-template/termlist-header.ko.md
+++ b/code/part-template/termlist-header.ko.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Contributors
: {contributors}
diff --git a/code/part-template/termlist-header.nl.md b/code/part-template/termlist-header.nl.md
index 7384993d..48cfe27c 100644
--- a/code/part-template/termlist-header.nl.md
+++ b/code/part-template/termlist-header.nl.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Contributors
: {contributors}
diff --git a/code/part-template/termlist-header.pt.md b/code/part-template/termlist-header.pt.md
index 7384993d..a5383017 100644
--- a/code/part-template/termlist-header.pt.md
+++ b/code/part-template/termlist-header.pt.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Contributors
: {contributors}
@@ -40,7 +40,7 @@ Bibliographic citation
## 1 Introduction (informative)
-This document includes terms intended to be used as controlled values for the Audiovisual Core terms `ac:subjectPart` and `ac:subjectPartLiteral`. A [JSON-LD representation](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart.json) (including translations to multiple languages) of this SKOS Concept Scheme is available. For more information about how to use this vocabulary, see the [subjectPart and subjectOrientation Controlled Vocabularies User Guide](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
+This document includes terms intended to be used as controlled values for the Audiovisual Core terms `ac:subjectPart` and `ac:subjectPartLiteral`. A [JSON-LD representation](https://tdwg.github.io/rs.tdwg.org/cvJson/acpart.json) (including translations to multiple languages) of this SKOS Concept Scheme is available. Para maiores informações sobre como utilizar este vocabulário, veja [o Guia de Usuário para Vocabulários Controlados subjectPart e subjectOrientation](https://github.com/tdwg/ac/blob/master/views/views_user_guide.pdf).
### 1.1 Status of the content of this document
diff --git a/code/part-template/termlist-header.ru.md b/code/part-template/termlist-header.ru.md
index 7654a4a4..3dcd4b7f 100644
--- a/code/part-template/termlist-header.ru.md
+++ b/code/part-template/termlist-header.ru.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
Предыдущая версия {previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Авторы: {contributors}
diff --git a/code/part-template/termlist-header.zh-Hans.md b/code/part-template/termlist-header.zh-Hans.md
index 7384993d..48cfe27c 100644
--- a/code/part-template/termlist-header.zh-Hans.md
+++ b/code/part-template/termlist-header.zh-Hans.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
Contributors
: {contributors}
diff --git a/code/part-template/termlist-header.zh-Hant.md b/code/part-template/termlist-header.zh-Hant.md
index 6aaa1b91..aafcef07 100644
--- a/code/part-template/termlist-header.zh-Hant.md
+++ b/code/part-template/termlist-header.zh-Hant.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subjectPart: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core term subjectPart describes the part of an organism morphology, behaviour, environment depicted in a media item or region of interest. The subjectPart Controlled Vocabulary provides terms that should be used as values for ac:subjectPart and its literal-valued analog ac:subjectPartLiteral.
貢獻者
: {contributors}
diff --git a/code/subtype-template/termlist-header.ar.md b/code/subtype-template/termlist-header.ar.md
index 7a1da7f2..b53776e6 100644
--- a/code/subtype-template/termlist-header.ar.md
+++ b/code/subtype-template/termlist-header.ar.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Contributors
: {contributors}
diff --git a/code/subtype-template/termlist-header.cs.md b/code/subtype-template/termlist-header.cs.md
index 135914f8..95468545 100644
--- a/code/subtype-template/termlist-header.cs.md
+++ b/code/subtype-template/termlist-header.cs.md
@@ -1,12 +1,12 @@
-# {document_title}
+# Řízený slovník pro Audiovisual Core subtype: Seznam termínů
-Title
-: {document_title}
+Název
+: Řízený slovník pro Audiovisual Core subtype: Seznam termínů
-Namespace IRI
+IRI Jmenného prostoru
:
-Preferred namespace abbreviation
+Preferovaná zkratka jmenného prostoru
: acsubtype:
Datum vydání verze
@@ -26,8 +26,8 @@ Aktuální verze
{previous_version_slot}
-Abstract
-: {abstract}
+Abstrakt
+: Audiovisual Core používá termíny ac:subtype a ac:subtypeLiteral k upřesnění typu mediálního prvku na úroveň, která je konkrétnější než slovník Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. Tento řízený slovník poskytuje hodnoty pro ac:subtype a ac:subtypeLiteral.
Přispěvatelé
: {contributors}
@@ -38,19 +38,19 @@ Tvůrce
Bibliografická citace
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1 Úvod (informativní)
-This document includes terms intended to be used as a controlled value for Audiovisual Core terms `ac:subtype` and `ac:subtypeLiteral`. **Note:** Although this is a controlled vocabulary, the type of its terms is `rdfs:Class` rather than `skos:Concept` as in other controlled vocabularies because it indicates the type of the media item.
+Tento dokument obsahuje termíny, které mají být použity jako řízené hodnoty pro audiovizuální základní termíny `ac:subtype` a `ac:subtypeLiteral`. **Poznámka:** Ačkoli se jedná o řízený slovník, typ jeho termínů je `rdfs:Class`, nikoli `skos:Concept` jako v jiných kontrolovaných slovnících, protože označuje typ mediálního prvku.
### 1.1 Status obsahu tohoto dokumentu
-Section 1 is informative (non-normative).
+Oddíl 1 je informativní (nenormativní).
Oddíl 2 je normativní.
-Section 3 is informative (non-normative).
+Oddíl 3 je informativní (nenormativní).
-V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Label` and the values of all other properties are non-normative.
+V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Štítek` a hodnoty všech ostatních vlastností nejsou normativní.
### 1.2 Klíčová slova RFC 2119
@@ -58,12 +58,12 @@ Klíčová slova "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
## 2 Použití termínů
-### 2.1 Relationship of value types to property terms
+### 2.1 Vztah hodnotových typů k pojmům vlastnictví
-In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/ac/doc/termlist/), unabbreviated term IRIs SHOULD be used as values of the property `ac:subtype`. Controlled value strings SHOULD be used as values of the property `ac:subtypeLiteral`.
+V souladu s [dokumentem Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) by se jako hodnoty vlastnosti `ac:subtype` MĚLY používat nezkrácené termíny IRI. Jako hodnoty vlastnosti `ac:subtypeLiteral` by se MĚLY používat řízené hodnotové řetězce.
-### 2.2 Relationship between values of ac:subtypeLiteral and ac:subtype
+### 2.2 Vztah mezi hodnotami ac:subtypeLiteral a ac:subtype
-An IRI for a term in this vocabulary denotes the same class as the class denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `ac:subtype` given a controlled value string for `ac:subtypeLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `ac:subtype` property in cases where providers only provide values for `ac:subtypeLiteral`.
+IRI pro termín v tomto slovníku označuje stejnou třídu jako třída označená řetězcem řízené hodnoty pro stejný termín. Klient tedy MŮŽE odvodit hodnotu IRI pro `ac:subtype` na základě kontrolovaného řetězce hodnoty pro `ac:subtypeLiteral`, i když tato hodnota IRI není výslovně uvedena. Praktickým důsledkem je, že agregátoři dat MOHOU materializovat hodnoty pro preferovanou vlastnost `ac:subtype` v případech, kdy poskytovatelé poskytují pouze hodnoty pro `ac:subtypeLiteral`.
## 3 Index termínů
diff --git a/code/subtype-template/termlist-header.de.md b/code/subtype-template/termlist-header.de.md
index 1f1fa218..15da7436 100644
--- a/code/subtype-template/termlist-header.de.md
+++ b/code/subtype-template/termlist-header.de.md
@@ -1,9 +1,7 @@
-CreatorTranslator
-: [translator name](https://orcid.org/) ([translator institution](http://www.wikidata.org/entity/Q))
-=======================================================================================================================================
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -29,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Contributors
: {contributors}
diff --git a/code/subtype-template/termlist-header.es.md b/code/subtype-template/termlist-header.es.md
index 5a3edcef..4b518375 100644
--- a/code/subtype-template/termlist-header.es.md
+++ b/code/subtype-template/termlist-header.es.md
@@ -1,13 +1,13 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
-Namespace IRI
+IRI del espacio de nombres
:
-Preferred namespace abbreviation
-: acsubtype:
+Abreviatura de espacio de nombres preferida
+: acpart:
Fecha de publicación de la versión
: {ratification_date}
@@ -27,7 +27,7 @@ Esta versión
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Colaboradores
: {contributors}
@@ -38,19 +38,19 @@ Creador
Cita bibliográfica
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1 Introducción (Informativa)
-This document includes terms intended to be used as a controlled value for Audiovisual Core terms `ac:subtype` and `ac:subtypeLiteral`. **Note:** Although this is a controlled vocabulary, the type of its terms is `rdfs:Class` rather than `skos:Concept` as in other controlled vocabularies because it indicates the type of the media item.
+Este documento incluye términos destinados a ser utilizados como valores controlados para los términos del Audiovisual Core `ac:subjectPart` y `ac:subjectPartLiteral`. **Nota:** Aunque este es un vocabulario controlado, el tipo de sus términos es `rdfs:Class` en lugar de `skos:Concept` como en otros vocabularios controlados, porque indica el tipo del elemento multimedia.
### 1.1 Estado del contenido de este documento
-Section 1 is informative (non-normative).
+La Sección 1 es informativa (no normativa).
La sección 2 es normativa.
-Section 3 is informative (non-normative).
+La Sección 3 es informativa (no normativa).
-En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. `Label` and the values of all other properties are non-normative.
+En la Sección 4, los valores de `IRI del Término`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. La `Etiqueta` y los valores de todas las demás propiedades no son normativos.
### 1.2 Palabras clave RFC 2119
@@ -58,12 +58,12 @@ Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD
## 2 Uso de los Términos
-### 2.1 Relationship of value types to property terms
+### 2.1 Relación de los tipos de valor con los términos de propiedad
-In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/ac/doc/termlist/), unabbreviated term IRIs SHOULD be used as values of the property `ac:subtype`. Controlled value strings SHOULD be used as values of the property `ac:subtypeLiteral`.
+De acuerdo con el [documento de la Lista de términos del Audiovisual Core](http://rs.tdwg.org/ac/doc/termlist/), los términos IRI no abreviados DEBEN usarse como valores de la propiedad `dcterms:format`. Las cadenas de valores controlados DEBEN usarse como valores de la propiedad `ac:subtypeLiteral`.
-### 2.2 Relationship between values of ac:subtypeLiteral and ac:subtype
+### 2.2 Relación entre los valores de ac:subtypeLiteral y ac:subtype
-An IRI for a term in this vocabulary denotes the same class as the class denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `ac:subtype` given a controlled value string for `ac:subtypeLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `ac:subtype` property in cases where providers only provide values for `ac:subtypeLiteral`.
+Una IRI para un término en este vocabulario denota la misma clase que la clase denotada por la cadena de valor controlado para el mismo término. De esta manera, un usuario PUEDE inferir un valor IRI para `ac:subtype` dada una cadena de valor controlado para `ac:subtypeLiteral` incluso si ese IRI no se indica explícitamente. La implicación práctica es que los agregadores de datos PUEDEN materializar valores para la propiedad `ac:subtype` preferida en casos donde los proveedores solo proporcionan valores para `ac:subtypeLiteral`.
## 3 Índice de Términos
diff --git a/code/subtype-template/termlist-header.fr.md b/code/subtype-template/termlist-header.fr.md
index 0021df84..e89c4357 100644
--- a/code/subtype-template/termlist-header.fr.md
+++ b/code/subtype-template/termlist-header.fr.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ Version précédente
: {previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Contributeurs
: {contributors}
diff --git a/code/subtype-template/termlist-header.ja.md b/code/subtype-template/termlist-header.ja.md
index 6ff1e4f9..1b4a028a 100644
--- a/code/subtype-template/termlist-header.ja.md
+++ b/code/subtype-template/termlist-header.ja.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ TDWG標準での該当箇所
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
貢献者
: {contributors}
diff --git a/code/subtype-template/termlist-header.km.md b/code/subtype-template/termlist-header.km.md
index 7a1da7f2..b53776e6 100644
--- a/code/subtype-template/termlist-header.km.md
+++ b/code/subtype-template/termlist-header.km.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Contributors
: {contributors}
diff --git a/code/subtype-template/termlist-header.ko.md b/code/subtype-template/termlist-header.ko.md
index 7a1da7f2..b53776e6 100644
--- a/code/subtype-template/termlist-header.ko.md
+++ b/code/subtype-template/termlist-header.ko.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Contributors
: {contributors}
diff --git a/code/subtype-template/termlist-header.nl.md b/code/subtype-template/termlist-header.nl.md
index 7a1da7f2..b53776e6 100644
--- a/code/subtype-template/termlist-header.nl.md
+++ b/code/subtype-template/termlist-header.nl.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Contributors
: {contributors}
diff --git a/code/subtype-template/termlist-header.pt.md b/code/subtype-template/termlist-header.pt.md
index 7a1da7f2..b53776e6 100644
--- a/code/subtype-template/termlist-header.pt.md
+++ b/code/subtype-template/termlist-header.pt.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Contributors
: {contributors}
diff --git a/code/subtype-template/termlist-header.ru.md b/code/subtype-template/termlist-header.ru.md
index 52204f02..c86b2438 100644
--- a/code/subtype-template/termlist-header.ru.md
+++ b/code/subtype-template/termlist-header.ru.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
Предыдущая версия {previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Авторы: {contributors}
diff --git a/code/subtype-template/termlist-header.zh-Hans.md b/code/subtype-template/termlist-header.zh-Hans.md
index 7a1da7f2..b53776e6 100644
--- a/code/subtype-template/termlist-header.zh-Hans.md
+++ b/code/subtype-template/termlist-header.zh-Hans.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
Contributors
: {contributors}
diff --git a/code/subtype-template/termlist-header.zh-Hant.md b/code/subtype-template/termlist-header.zh-Hant.md
index ac10491f..fe4d018d 100644
--- a/code/subtype-template/termlist-header.zh-Hant.md
+++ b/code/subtype-template/termlist-header.zh-Hant.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core subtype: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:subtype and ac:subtypeLiteral to refine the type of a media item to a level more specific than the Dublin Core Type Vocabulary, http://purl.org/dc/dcmitype/. This controlled vocabulary provides values for ac:subtype and ac:subtypeLiteral.
貢獻者
: {contributors}
diff --git a/code/termlist-dictionary.cs.json b/code/termlist-dictionary.cs.json
index 7e8a6473..91b2c60b 100644
--- a/code/termlist-dictionary.cs.json
+++ b/code/termlist-dictionary.cs.json
@@ -3,14 +3,20 @@
"term_indices": "Indexy termínů",
"index_by_term_name": "Index podle názvu termínu",
"index_by_label": "Index podle štítku",
+ "see_also": "Viz také",
"vocabulary": "Slovník",
+ "vocabularies": "Slovníky",
"term_name": "Název termínu",
"term_iri": "Termín IRI",
"modified": "Změněno",
"term_version_iri": "Verze termínu IRI",
"label": "Štítek",
+ "required": "Vyžadováno",
+ "repeatable": "Opakovatelné",
"definition": "Definice",
+ "notes": "Poznámky",
"controlled_value": "Řízená hodnota",
+ "definition_derived_from": "Definice odvozená z",
"usage": "Použití",
"examples": "Příklady",
"type": "Typ",
@@ -20,5 +26,12 @@
"executive_committee_decision": "Rozhodnutí výkonného výboru",
"term_deprecated": "Tento termín je zastaralý a již by se neměl používat.",
"term_replaced_by": "Je nahrazen",
- "has_broader_concept": "Má širší pojem"
+ "has_broader_concept": "Má širší pojem",
+ "has_exact_match": "Má přesnou shodu",
+ "geography_vocabulary_comments": "Všimněte si, že lze použít [dwc:locality](http://rs.tdwg.org/dwc/terms/locality), ale v souvislosti s médii může být tento termín nejednoznačný, pokud jde o to, zda se vztahuje k zobrazenému místu nebo k místu, kde bylo médium vytvořeno. Pokud jsou k dispozici informace umožňující odstranění nejednoznačnosti, je lepší použít termíny „Místo zobrazení“ a „Místo vytvoření“. Druhý z nich je uveden ve slovníku Resource Creation Vocabulary.\n\n\nMísto vytvoření a Místo zobrazení jsou v aktuální verzi IPTC odděleny a pracovní skupina pro metadata ([Metadata Working Group Guidelines for Handling Image Metadata, Version 2.0, November 2010](https://web.archive.org/web/20180919181934/ http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf)) to také doporučuje. Níže se tímto doporučením řídíme, abychom podpořili očekávaný budoucí nárůst automatického zaznamenávání souřadnic pomocí GPS. Jako zvláštní případ doporučuje skupina AC změnit sémantiku pojmu „Místo zobrazení“ v případě vzorků biologické rozmanitosti, kde se původní místo může lišit od aktuálního místa, kde je vzorek uchováván ve sbírce. V tomto případě by se Místo zobrazení mělo vztahovat výhradně na místo, kde byl exemplář původně odebrán (místo sběru nebo odběru vzorku). Místo vytvoření se používá k vyjádření místa, kde byl zdroj vytvořen (exemplář byl digitalizován).\n\n",
+ "service_access_point_vocabulary_comments": "Tyto termíny jsou metadata závislá na reprezentaci, která odkazují na konkrétní digitální reprezentace zdroje (např. konkrétní rozlišení, kvalita nebo formát). Používají se v rámci jakékoli konkrétní implementace AC přiřazené hodnotě `ac:hasServiceAccessPoint`, jejíž označení je jednoduše „Service Access Point“ (Přístupový bod služby). Upozorňujeme, že implementace může používat syntaktické konvence, které se vyhýbají přímému použití `ac:hasServiceAccessPoint`, jak je znázorněno v posledním příkladu v části [Multiplicity/Cardinality in the Audiovisual Core Structure document](structure.md#3-multiplicity-and-cardinality).",
+ "region_of_interest_vocabulary_comments": "Regiony zájmu (ROI) označují konkrétní části mediálních položek. Funkce v těchto regionech lze taxonomicky identifikovat nebo propojit se záznamy o výskytu. Metadata ROI lze také použít k generování anotací mediální položky nebo k usnadnění zobrazení či zvýraznění konkrétních částí. \n\nV současné době jsou prostorové ROI omezeny na dvě dimenze a lze je definovat pouze pomocí obdélníků nebo oblouků (včetně kruhů). Termíny v této skupině nelze v rámci jedné instance ROI opakovat, i když mediální položka může být propojena s více než jednou ROI pomocí vlastnosti `ac:hasROI`.\n\n Příklady použití těchto termínů najdete na stránce ROI Recipes.\n\n",
+ "concept_schemes": "Koncepční schémata",
+ "media_types_and_physical_media_concept_scheme": "Typy médií a schéma koncepce fyzických médií",
+ "file_extensions_concept_scheme": "Schéma pojmů přípon souborů"
}
diff --git a/code/termlist-dictionary.es.json b/code/termlist-dictionary.es.json
index 1292da1a..e11e1efa 100644
--- a/code/termlist-dictionary.es.json
+++ b/code/termlist-dictionary.es.json
@@ -11,9 +11,12 @@
"modified": "Modificado",
"term_version_iri": "Versión de Término IRI",
"label": "Etiqueta",
+ "required": "Requerido",
+ "repeatable": "Repetible",
"definition": "Definición",
"notes": "Notas",
"controlled_value": "Valor controlado",
+ "definition_derived_from": "Definición derivada de",
"usage": "Uso",
"examples": "Ejemplos",
"type": "Tipo",
@@ -23,5 +26,7 @@
"executive_committee_decision": "Decisión del Comité Ejecutivo",
"term_deprecated": "Este término está obsoleto y no debería utilizarse más.",
"term_replaced_by": "Es reemplazado por",
- "has_broader_concept": "Tiene un concepto más amplio"
+ "has_broader_concept": "Tiene un concepto más amplio",
+ "has_exact_match": "Tiene coincidencia exacta",
+ "3d_resources_vocabulary": "Recursos de Vocabulario 3D"
}
diff --git a/code/termlist-template/termlist-header.ar.md b/code/termlist-template/termlist-header.ar.md
index 4c177957..4438abd7 100644
--- a/code/termlist-template/termlist-header.ar.md
+++ b/code/termlist-template/termlist-header.ar.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Date version issued
: {ratification_date}
@@ -21,7 +21,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Contributors
: {contributors}
@@ -126,4 +126,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.cs.md b/code/termlist-template/termlist-header.cs.md
index e4f98de1..791da3f7 100644
--- a/code/termlist-template/termlist-header.cs.md
+++ b/code/termlist-template/termlist-header.cs.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Seznam termínů Audiovisual Core
-Title
-: {document_title}
+Název
+: Seznam termínů Audiovisual Core
Datum vydání verze
: {ratification_date}
@@ -20,8 +20,8 @@ Aktuální verze
{previous_version_slot}
-Abstract
-: {abstract}
+Abstrakt
+: Audiovisual Core je soubor slovníků určených k reprezentaci metadat pro multimediální zdroje a sbírky týkající se biologické rozmanitosti. Jeho cílem je poskytnout informace, které pomohou před pořízením média určit, zda je daný zdroj nebo sbírka vhodná pro konkrétní vědecké účely v oblasti biologické rozmanitosti. Slovníky se mimo jiné zabývají otázkami, jako je správa médií a sbírek, popisy jejich obsahu, jejich taxonomické, geografické a časové pokrytí a vhodné způsoby jejich vyhledávání, přiřazování a reprodukce. Tento dokument obsahuje seznam atributů každého základního audiovizuálního termínu, včetně názvu dokumentace, specifikovaného URI, doporučeného anglického označení pro uživatelská rozhraní, definice a některých doplňujících poznámek. Tento dokument obsahuje normativní obsah, který nelze měnit bez řádného procesu.
Přispěvatelé
: {contributors}
@@ -34,96 +34,95 @@ Bibliografická citace
## 1. Úvod
-There are a number of documents included in the Audiovisual Core Standard. This document provides details about the terms included in the {ratification_date} version of the Audiovisual Core vocabulary. The [Audiovisual Core Introduction](../introduction/) document provides a brief introduction to the Audiovisual Core Standard. For information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/) document. For a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide/) document.
+Audiovisual Core Standard obsahuje řadu dokumentů. Tento dokument obsahuje podrobné informace o podmínkách obsažených ve verzi {ratification_date} slovníku Audiovisual Core. Dokument [Audiovisual Core Introduction](../introduction/) poskytuje stručný úvod do Audiovisual Core Standard. Informace o struktuře Audiovisual Core naleznete v dokumentu [Audiovisual Core Structure](../structure/). Podrobnější návod k používání Audiovisual Core naleznete v dokumentu [Audiovisual Core Guide](../guide/).
### 1.1 Status obsahu tohoto dokumentu
-Sections 1.3 through 5 are normative, except for Table 1. In Section 7 and its subparts, the values of the Normative URI, Definition, Required, and Repeatable are normative. The value of Usage (if it exists for a given term) is normative in that it specifies how a borrowed term should be used as part of Audiovisual Core. The values of Term Name is non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. Labels and the values of all other properties (such as notes) are non-normative.
+Oddíly 1.3 až 5 jsou normativní, s výjimkou tabulky 1. V oddíle 7 a jeho pododdílech jsou hodnoty Normativní URI, Definice, Požadované a Opakovatelné normativní. Hodnota použití (pokud existuje pro daný termín) je normativní v tom smyslu, že určuje, jak by měl být vypůjčený termín používán jako součást Audiovisual Core. Hodnoty Term Name nejsou normativní, i když lze očekávat, že předpona zkratky jmenného prostoru je běžně používaná pro jmenný prostor termínů. Štítky a hodnoty všech ostatních vlastností (například poznámky) nejsou normativní.
### 1.2 Klíčová slova RFC 2119
Klíčová slova "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" a "OPTIONAL" v tomto dokumentu je třeba interpretovat tak, jak je popsáno v [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) a [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174), pokud a pouze pokud jsou uvedena velkými písmeny, jak je uvedeno zde.
-### 1.3 Categories of terms
-
-An Audiovisual Core (AC) record is a description of a multimedia resource
-using the AC vocabularies. Three kinds of terms are specified by this
-document: those terms which describe representation-independent aspects
-of the media, those which describe representation-dependent aspects, and those that designate specified parts of the media item.
-Most terms are representation-independent, referring to an "abstract
-multimedia resource". One such term, `ac:hasServiceAccessPoint`, refers to
-or contains representation-dependent service access point metadata
-describing a digital representation of the abstract multimedia resource (an instance of the `ac:ServiceAccessPoint` class).
-These metadata describe such things as a web address at which a digital
-representation can be retrieved, and the format, extent, or licenses
-that describe a particular such representation. A multimedia resource
-may provide several access points for different representations (e.g.,
-different resolutions). The resource may also be linked to one or more Regions of Interest (ROI) that define parts within the media item (instances of the `ac:RegionOfInterest` class).
-
-## 2 Borrowed Vocabulary
-
-When terms are borrowed from other vocabularies, AC uses the URIs,
-common abbreviations, and namespace prefixes in use in those
-vocabularies. The URIs are normative, but abbreviations and namespace
-prefixes have no impact except as an aid to reading the documentation.
-
-Table 1. Vocabularies from which terms have been borrowed (non-normative)
-
-Note: URIs for terms in most of these namespaces do not dereference to anything. The authoritative documentation can be obtained by clicking on the vocabulary names in the table.
-
-| Slovník | Abbreviation | Namespaces and abbreviations |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------ | --------------------------------------------------------------------------------------- |
-| [Darwin Core](http://rs.tdwg.org/dwc/doc/list/) | DwC | `dwc: = http://rs.tdwg.org/dwc/terms/` |
-| [Dublin Core](http://dublincore.org/documents/dcmi-terms/) | DC | `dc: = http://purl.org/dc/elements/1.1/, dcterms: = http://purl.org/dc/terms/` |
-| [Adobe XMP Core Properties](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart1.pdf) | XMP | `xmp: = http://ns.adobe.com/xap/1.0/, xmpRights: = http://ns.adobe.com/xap/1.0/rights/` |
-| [Adobe XMP Additional Properties](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart2.pdf) | XMP | `photoshop: = http://ns.adobe.com/photoshop/1.0/` |
-| [International Press and Telecommunications Council Photo Metadata Standard,Extension Schema 1.1](http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf) | IPTC | `Iptc4xmpExt: = http://iptc.org/std/Iptc4xmpExt/2008-02-29/` |
-| [Camera and Imaging Products Association Exchangeable Image File Format](http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf) | EXIF | `exif: = http://ns.adobe.com/exif/1.0/` |
-| [Music Ontology](http://musicontology.com/specification/) | MO | `mo: = http://purl.org/ontology/mo/` |
-
-## 3 Namespaces, Prefixes and Term Names
-
-The namespace of terms borrowed from other vocabularies is that of the
-original. The namespace of de novo AC terms is
-`http://rs.tdwg.org/ac/terms/`. In the table of terms, each term entry has
-a row with the term name. This term name is generally an "unqualified
-name" preceded by a widely accepted prefix designating an abbreviation
-for the namespace It is RECOMMENDED that implementers who need a
-namespace prefix for the AC namespace use `ac`. In this web document,
-hovering over a term in the [Index By Term Name](#61-index-by-term-name)
-list below will reveal a complete URL that can be used in other web
-documents to link to _this_ document's treatment of that term, even if
-it is from a borrowed vocabulary. It is very important to note that some
-vocabularies, e.g those of the
+### 1.3 Kategorie pojmů
+
+Záznam Audiovisual Core (AC) je popis multimediálního zdroje
+pomocí slovníků AC. Tento dokument specifikuje tři druhy termínů:
+termíny, které popisují aspekty médií nezávislé na reprezentaci,
+termíny, které popisují aspekty závislé na reprezentaci, a termíny, které označují specifikované části mediálního prvku.
+Většina termínů je nezávislá na reprezentaci a odkazuje na „abstraktní
+multimediální zdroj“. Jeden z těchto termínů, `ac:hasServiceAccessPoint`, odkazuje na
+nebo obsahuje metadata přístupového bodu služby závislá na reprezentaci,
+která popisují digitální reprezentaci abstraktního multimediálního zdroje (instance třídy `ac:ServiceAccessPoint`).
+Tato metadata popisují například webovou adresu, na které lze digitální
+reprezentaci získat, a formát, rozsah nebo licence,
+které popisují konkrétní reprezentaci. Multimediální zdroj
+může poskytovat několik přístupových bodů pro různé reprezentace (např.
+různá rozlišení). Zdroj může být také propojen s jednou nebo více oblastmi zájmu (ROI), které definují části v rámci mediální položky (instance třídy `ac:RegionOfInterest`).
+
+## 2 Převzatý slovník
+
+Při přebírání termínů z jiných slovníků používá AC URI,
+běžné zkratky a předpony jmenných prostorů používané v těchto
+slovnících. URI jsou normativní, ale zkratky a předpony jmenných prostorů
+nemají žádný vliv, kromě toho, že usnadňují čtení dokumentace.
+
+Tabulka 1. Slovníky, ze kterých byly termíny převzaty (nenormativní)
+
+Poznámka: URI pro termíny ve většině těchto jmenných prostorů neodkazují na nic. Autoritativní dokumentaci lze získat kliknutím na názvy slovníku v tabulce.
+
+| Slovník | Zkratka | Jmenné prostory a zkratky |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- | --------------------------------------------------------------------------------------- |
+| [Darwin Core](http://rs.tdwg.org/dwc/doc/list/) | DwC | `dwc: = http://rs.tdwg.org/dwc/terms/` |
+| [Dublin Core](http://dublincore.org/documents/dcmi-terms/) | DC | `dc: = http://purl.org/dc/elements/1.1/, dcterms: = http://purl.org/dc/terms/` |
+| [Adobe XMP Core Properties](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart1.pdf) | XMP | `xmp: = http://ns.adobe.com/xap/1.0/, xmpRights: = http://ns.adobe.com/xap/1.0/rights/` |
+| [Adobe XMP Additional Properties](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart2.pdf) | XMP | `photoshop: = http://ns.adobe.com/photoshop/1.0/` |
+| [International Press and Telecommunications Council Photo Metadata Standard,Extension Schema 1.1](http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf) | IPTC | `Iptc4xmpExt: = http://iptc.org/std/Iptc4xmpExt/2008-02-29/` |
+| [Camera and Imaging Products Association Exchangeable Image File Format](http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf) | EXIF | `exif: = http://ns.adobe.com/exif/1.0/` |
+| [Music Ontology](http://musicontology.com/specification/) | MO | `mo: = http://purl.org/ontology/mo/` |
+
+## 3 Jmenné prostory, předpony a názvy termínů
+
+Jmenný prostor termínů převzatých z jiných slovníků je stejný jako
+původní. Jmenný prostor termínů de novo AC je
+`http://rs.tdwg.org/ac/terms/`. V tabulce termínů má každý termínový záznam
+řádek s názvem termínu. Tento termín je obecně „nekvalifikovaným
+názvem“, před kterým je široce přijímaná předpona označující zkratku
+pro jmenný prostor. DOPORUČUJE se, aby implementátoři, kteří potřebují
+předponu jmenného prostoru pro jmenný prostor AC, použili `ac`. V tomto webovém dokumentu
+se po najetí kurzorem na termín v seznamu [Index podle názvu termínu](#61-index-by-term-name)
+zobrazí úplná URL adresa, kterou lze použít v jiných webových
+dokumentech k odkazování na _tento_ dokument, který se zabývá daným termínem, i když
+pochází z převzatého slovníku. Je velmi důležité si uvědomit, že některé
+slovníky, např. slovníky
[Dublin Core Metadata Initiative (DCMI)](https://www.dublincore.org/),
-provide versions of the same term in two different namespaces, one
-providing for string values and one providing for URIs, even where that
-separation is simply a recommendation, not a mandate. See this
-[DCMI wiki entry](https://web.archive.org/web/20171126043657/https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md)
-on this topic. For vocabularies where such a practice is in place, we
-often follow it and signal a reference in the Notes of our term
-descriptions to the sister version of the term. An example is the pair
-[dc:type](#dc_type) and [dcterms:type](#dcterms_type). When such a pair allows repeated instances (e.g. as for [dc:source](#dc_source) and [dcterms:source](#dcterms_source)), particular care may be required in some
-implementations of AC, because
-some implementations may not provide enough structure to clearly state
-the association between the members of a pair in the case of multiple
-values of each. This is a special case of the issue treated in the
-normative material on [Multiplicity and Cardinality](../structure/#3-multiplicity-and-cardinality) in the Audiovisual Core Structure document.
-
-## 4 Layers
-
-(The Audiovisual Core layer property has been deprecated as of 2020-01-27)
-
-## 5 Literal- vs. URI-valued Terms
-
-Some terms have two versions, one expecting a string literal value and
-the other a URI. In these circumstances, the version expecting a string
-is named with the suffix "Literal", e.g. `ac:metadataLanguageLiteral`. In
-such cases, both forms MAY be provided, but care should be taken to
-ensure that the uses reflect the same intent. In case of ambiguity, the
-URI version prevails. All terms, including those whether or not with a
-specific "Literal" suffix, specify in their definition whether the
-required values are strings or URIs.
-
-## 6 Vocabulary Indices (non-normative)
-
+poskytují verze stejného termínu ve dvou různých jmenných prostorech, z nichž jeden
+poskytuje řetězcové hodnoty a druhý poskytuje URI, i když je toto
+oddělení pouze doporučením, nikoli povinností. Viz tento
+[záznam na wiki DCMI](https://web.archive.org/web/20171126043657/https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md)
+k tomuto tématu. U slovníků, kde se taková praxe používá, ji
+často dodržujeme a v poznámkách k popisu termínů odkazujeme
+na sesterskou verzi termínu. Příkladem je dvojice
+[dc:type](#dc_type) a [dcterms:type](#dcterms_type). Pokud takový pár umožňuje opakované instance (např. jako u [dc:source](#dc_source) a [dcterms:source](#dcterms_source)), může být v některých
+implementacích AC zapotřebí zvláštní opatrnost, protože
+některé implementace nemusí poskytovat dostatečnou strukturu k jasnému vyjádření
+vztahu mezi členy páru v případě více
+hodnot každého z nich. Jedná se o zvláštní případ problému, který je řešen v
+normativním materiálu o [multiplicitě a kardinalitě](../structure/#3-multiplicity-and-cardinality) v dokumentu Audiovisual Core Structure.
+
+## 4 Vrstvy
+
+(Vlastnost Audiovisual Core layer byla k 27. 1. 2020 označena jako zastaralá)
+
+## 5 Termíny s doslovnou hodnotou vs. termíny s hodnotou URI
+
+Některé termíny mají dvě verze, jedna očekává hodnotu doslovného řetězce a
+druhá URI. Za těchto okolností je verze očekávající řetězec
+pojmenována s příponou „Literal“, např. `ac:metadataLanguageLiteral`. V
+takových případech MŮŽOU být poskytnuty obě formy, ale je třeba dbát na to,
+aby použití odráželo stejný záměr. V případě nejednoznačnosti má přednost
+verze URI. Všechny termíny, včetně těch, které mají nebo nemají
+specifickou příponu „Literal“, specifikují ve své definici, zda jsou
+požadované hodnoty řetězce nebo URI.
+
+## 6 Slovníkové indexy (nenormativní)
diff --git a/code/termlist-template/termlist-header.de.md b/code/termlist-template/termlist-header.de.md
index 4c177957..4438abd7 100644
--- a/code/termlist-template/termlist-header.de.md
+++ b/code/termlist-template/termlist-header.de.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Date version issued
: {ratification_date}
@@ -21,7 +21,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Contributors
: {contributors}
@@ -126,4 +126,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.es.md b/code/termlist-template/termlist-header.es.md
index b243d92a..8a6b1307 100644
--- a/code/termlist-template/termlist-header.es.md
+++ b/code/termlist-template/termlist-header.es.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Fecha de publicación de la versión
: {ratification_date}
@@ -20,8 +20,8 @@ Esta versión
{previous_version_slot}
-Abstract
-: {abstract}
+Resumen:
+El Audiovisual Core es un conjunto de vocabularios diseñados para representar metadatos de recursos y colecciones multimedia sobre biodiversidad. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Entre otras cosas, los vocabularios abordan cuestiones como la gestión de los medios y las colecciones, las descripciones de su contenido, su cobertura taxonómica, geográfica y temporal, y las formas apropiadas de recuperarlos, atribuirlos y reproducirlos. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Colaboradores
: {contributors}
@@ -34,96 +34,54 @@ Cita bibliográfica
## 1 Introducción
-There are a number of documents included in the Audiovisual Core Standard. This document provides details about the terms included in the {ratification_date} version of the Audiovisual Core vocabulary. The [Audiovisual Core Introduction](../introduction/) document provides a brief introduction to the Audiovisual Core Standard. For information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/) document. For a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide/) document.
+Hay una serie de documentos incluidos en el Estándar Audiovisual Core. Este documento proporciona detalles sobre los términos incluidos en la versión {ratification_date} del vocabulario Audiovisual Core. El documento [Introducción al Audiovisual Core](../introduction/) proporciona una breve introducción al Estándar Audiovisual Core. Para obtener información sobre la estructura del Audiovisual Core, consulte el documento [Estructura del Audiovisual Core](../structure/). Para obtener una guía más detallada sobre el uso del Audiovisual Core, consulte el documento [Guía del Audiovisual Core](../guide/).
### 1.1 Estado del contenido de este documento
-Sections 1.3 through 5 are normative, except for Table 1. In Section 7 and its subparts, the values of the Normative URI, Definition, Required, and Repeatable are normative. The value of Usage (if it exists for a given term) is normative in that it specifies how a borrowed term should be used as part of Audiovisual Core. The values of Term Name is non-normative, although one can expect that the namespace abbreviation prefix is one commonly used for the term namespace. Labels and the values of all other properties (such as notes) are non-normative.
+Las secciones 1.3 a 5 son normativas, excepto la Tabla 1. En la Sección 7 y sus subsecciones, los valores de URI normativo, Definición, Obligatorio y Repetible son normativos. El valor de Uso (si existe para un término determinado) es normativo, ya que especifica cómo debe usarse un término prestado como parte del Audiovisual Core. Los valores del nombre del término no son normativos, aunque se puede esperar que el prefijo de la abreviatura del espacio de nombres sea uno de uso común para el espacio de nombres del término. Las etiquetas y los valores de todas las demás propiedades (como las notas) no son normativos.
### 1.2 Palabras clave RFC 2119
Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" y "OPTIONAL" en este documento deben interpretarse como se describe en [BCP 14](https://www.rfc-editor.org/info/bcp14) [\[RFC 2119\]](https://datatracker.ietf.org/doc/html/rfc2119) y [\[RFC 8174\]](https://datatracker.ietf.org/doc/html/rfc8174), únicamente cuando aparezcan en mayúsculas, tal como se muestra aquí.
-### 1.3 Categories of terms
-
-An Audiovisual Core (AC) record is a description of a multimedia resource
-using the AC vocabularies. Three kinds of terms are specified by this
-document: those terms which describe representation-independent aspects
-of the media, those which describe representation-dependent aspects, and those that designate specified parts of the media item.
-Most terms are representation-independent, referring to an "abstract
-multimedia resource". One such term, `ac:hasServiceAccessPoint`, refers to
-or contains representation-dependent service access point metadata
-describing a digital representation of the abstract multimedia resource (an instance of the `ac:ServiceAccessPoint` class).
-These metadata describe such things as a web address at which a digital
-representation can be retrieved, and the format, extent, or licenses
-that describe a particular such representation. A multimedia resource
-may provide several access points for different representations (e.g.,
-different resolutions). The resource may also be linked to one or more Regions of Interest (ROI) that define parts within the media item (instances of the `ac:RegionOfInterest` class).
-
-## 2 Borrowed Vocabulary
-
-When terms are borrowed from other vocabularies, AC uses the URIs,
-common abbreviations, and namespace prefixes in use in those
-vocabularies. The URIs are normative, but abbreviations and namespace
-prefixes have no impact except as an aid to reading the documentation.
-
-Table 1. Vocabularies from which terms have been borrowed (non-normative)
-
-Note: URIs for terms in most of these namespaces do not dereference to anything. The authoritative documentation can be obtained by clicking on the vocabulary names in the table.
-
-| Vocabulario | Abbreviation | Namespaces and abbreviations |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------ | --------------------------------------------------------------------------------------- |
-| [Darwin Core](http://rs.tdwg.org/dwc/doc/list/) | DwC | `dwc: = http://rs.tdwg.org/dwc/terms/` |
-| [Dublin Core](http://dublincore.org/documents/dcmi-terms/) | DC | `dc: = http://purl.org/dc/elements/1.1/, dcterms: = http://purl.org/dc/terms/` |
-| [Adobe XMP Core Properties](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart1.pdf) | XMP | `xmp: = http://ns.adobe.com/xap/1.0/, xmpRights: = http://ns.adobe.com/xap/1.0/rights/` |
-| [Adobe XMP Additional Properties](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart2.pdf) | XMP | `photoshop: = http://ns.adobe.com/photoshop/1.0/` |
-| [International Press and Telecommunications Council Photo Metadata Standard,Extension Schema 1.1](http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf) | IPTC | `Iptc4xmpExt: = http://iptc.org/std/Iptc4xmpExt/2008-02-29/` |
-| [Camera and Imaging Products Association Exchangeable Image File Format](http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf) | EXIF | `exif: = http://ns.adobe.com/exif/1.0/` |
-| [Music Ontology](http://musicontology.com/specification/) | MO | `mo: = http://purl.org/ontology/mo/` |
-
-## 3 Namespaces, Prefixes and Term Names
-
-The namespace of terms borrowed from other vocabularies is that of the
-original. The namespace of de novo AC terms is
-`http://rs.tdwg.org/ac/terms/`. In the table of terms, each term entry has
-a row with the term name. This term name is generally an "unqualified
-name" preceded by a widely accepted prefix designating an abbreviation
-for the namespace It is RECOMMENDED that implementers who need a
-namespace prefix for the AC namespace use `ac`. In this web document,
-hovering over a term in the [Index By Term Name](#61-index-by-term-name)
-list below will reveal a complete URL that can be used in other web
-documents to link to _this_ document's treatment of that term, even if
-it is from a borrowed vocabulary. It is very important to note that some
-vocabularies, e.g those of the
-[Dublin Core Metadata Initiative (DCMI)](https://www.dublincore.org/),
-provide versions of the same term in two different namespaces, one
-providing for string values and one providing for URIs, even where that
-separation is simply a recommendation, not a mandate. See this
-[DCMI wiki entry](https://web.archive.org/web/20171126043657/https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md)
-on this topic. For vocabularies where such a practice is in place, we
-often follow it and signal a reference in the Notes of our term
-descriptions to the sister version of the term. An example is the pair
-[dc:type](#dc_type) and [dcterms:type](#dcterms_type). When such a pair allows repeated instances (e.g. as for [dc:source](#dc_source) and [dcterms:source](#dcterms_source)), particular care may be required in some
-implementations of AC, because
-some implementations may not provide enough structure to clearly state
-the association between the members of a pair in the case of multiple
-values of each. This is a special case of the issue treated in the
-normative material on [Multiplicity and Cardinality](../structure/#3-multiplicity-and-cardinality) in the Audiovisual Core Structure document.
-
-## 4 Layers
-
-(The Audiovisual Core layer property has been deprecated as of 2020-01-27)
-
-## 5 Literal- vs. URI-valued Terms
-
-Some terms have two versions, one expecting a string literal value and
-the other a URI. In these circumstances, the version expecting a string
-is named with the suffix "Literal", e.g. `ac:metadataLanguageLiteral`. In
-such cases, both forms MAY be provided, but care should be taken to
-ensure that the uses reflect the same intent. In case of ambiguity, the
-URI version prevails. All terms, including those whether or not with a
-specific "Literal" suffix, specify in their definition whether the
-required values are strings or URIs.
-
-## 6 Vocabulary Indices (non-normative)
+### 1.3 Categorías de términos
+Un registro de Audiovisual Core (AC) es una descripción de un recurso multimedia que utiliza los vocabularios del AC. Este documento especifica tres tipos de términos: aquellos que describen aspectos independientes de la representación de los medios, aquellos que describen aspectos dependientes de la representación y aquellos que designan partes específicas del elemento mediático.
+La mayoría de los términos son independientes de la representación y se refieren a un "recurso multimedia abstracto". Uno de estos términos, `ac:hasServiceAccessPoint`, se refiere a
+o contiene metadatos de punto de acceso al servicio dependientes de la representación,
+que describen una representación digital del recurso multimedia abstracto (una instancia de la clase `ac:ServiceAccessPoint`).
+Estos metadatos describen aspectos como la dirección web donde se puede recuperar una representación digital y el formato, la extensión o las licencias que describen dicha representación en particular. Un recurso multimedia puede proporcionar varios puntos de acceso para diferentes representaciones (por ejemplo, diferentes resoluciones). El recurso también puede estar vinculado a una o más regiones de interés (ROI) que definen partes dentro del elemento multimedia (instancias de la clase `ac:RegionOfInterest`).
+
+## 2 Vocabulario prestado
+
+Cuando los términos se toman prestados de otros vocabularios, AC utiliza los URI, las abreviaturas comunes y los prefijos de espacios de nombres que se usan en esos vocabularios. Las URI son normativas, pero las abreviaturas y los prefijos de espacios de nombres no tienen ningún impacto, excepto como ayuda para leer la documentación.
+
+Tabla 1. Vocabularios de los cuales se han tomado prestados términos (no normativos)
+
+Nota: Los URI de los términos en la mayoría de estos espacios de nombres no desvían la referencia a nada. La documentación autorizada se puede obtener haciendo clic en los nombres del vocabulario en la tabla.
+
+| Vocabulario | Abreviatura | Espacios de nombres y abreviaturas |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------------------------------------------------------------- |
+| [Darwin Core](http://rs.tdwg.org/dwc/doc/list/) | DwC | `dwc: = http://rs.tdwg.org/dwc/terms/` |
+| [Dublin Core](http://dublincore.org/documents/dcmi-terms/) | DC | `dc: = http://purl.org/dc/elements/1.1/, dcterms: = http://purl.org/dc/terms/` |
+| [Propiedades de Adobe XMP Core](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart1.pdf) | XMP | `xmp: = http://ns.adobe.com/xap/1.0/, xmpRights: = http://ns.adobe.com/xap/1.0/rights/` |
+| [Propiedades adicionales de Adobe XMP](https://github.com/adobe/XMP-Toolkit-SDK/blob/main/docs/XMPSpecificationPart2.pdf) | XMP | `photoshop: = http://ns.adobe.com/photoshop/1.0/` |
+| [Estándar de metadatos de fotografías del Consejo Internacional de Prensa y Telecomunicaciones, esquema de extensión 1.1](http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf) | IPTC | `Iptc4xmpExt: = http://iptc.org/std/Iptc4xmpExt/2008-02-29/` |
+| [Formato de archivo de imagen intercambiable de la Asociación de productos de imágenes y cámaras] (http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf) | EXIF | `exif: = http://ns.adobe.com/exif/1.0/` |
+| [Ontología de la Música](http://musicontology.com/specification/) | MO | `lo//purl.org/ontology/mo/` |
+
+## 3 Espacios de nombres, prefijos y nombres de términos
+
+El espacio de nombres de los términos tomados de otros vocabularios es el del original. El espacio de nombres de los términos de AC de novo es `http://rs.tdwg.org/ac/terms/`. En la tabla de términos, cada entrada de término tiene una fila con el nombre del término. Este término es generalmente un "nombre no calificado" precedido por un prefijo ampliamente aceptado que designa una abreviatura para el espacio de nombres. Se RECOMIENDA que los implementadores que necesiten un prefijo para el espacio de nombres AC utilicen "ac". En este documento web, al pasar el cursor sobre un término de la lista [Índice por nombre de término](#61-index-by-term-name) a continuación, se mostrará una URL completa que puede usarse en otros documentos web para enlazar con el tratamiento que _este_ documento da a ese término, incluso si proviene de un vocabulario prestado. Es muy importante tener en cuenta que algunos vocabularios, como los de la [Iniciativa de Metadatos Dublin Core (DCMI)](https://www.dublincore.org/), ofrecen versiones del mismo término en dos espacios de nombres diferentes: uno para valores de cadena y otro para URI, incluso cuando dicha separación es simplemente una recomendación, no un mandato. Consulte esta
+[entrada wiki de DCMI](https://web.archive.org/web/20171126043657/https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md)
+sobre este tema. En los vocabularios donde se utiliza esta práctica, a menudo la seguimos e indicamos una referencia en las notas de nuestras descripciones de términos a la versión hermana del término. Un ejemplo es el par [dc:type](#dc_type) y [dcterms:type](#dcterms_type). Cuando un par de este tipo permite instancias repetidas (por ejemplo, como en el caso de [dc:source](#dc_source) y [dcterms:source](#dcterms_source)), puede ser necesario tener especial cuidado en algunas implementaciones de AC, ya que algunas implementaciones pueden no proporcionar la estructura suficiente para indicar claramente la asociación entre los miembros de un par en el caso de múltiples valores de cada uno. Este es un caso especial de la cuestión tratada en el material normativo sobre [Multiplicidad y Cardinalidad](../structure/#3-multiplicity-and-cardinality) en el documento Estructura del Audiovisual Core.
+
+## 4 capas
+
+(La propiedad de capa del Audiovisual Core ha quedado obsoleta a partir de 2020-01-27)
+
+## 5 Términos literales vs. términos con valores URI
+
+Algunos términos tienen dos versiones: una que espera un valor literal de cadena y la otra, un URI. En estas circunstancias, la versión que espera una cadena se nombra con el sufijo "Literal", por ejemplo, `ac:metadataLanguageLiteral`. En tales casos, se PUEDEN proporcionar ambas formas, pero se debe tener cuidado para garantizar que los usos reflejen la misma intención. En caso de ambigüedad, prevalece la versión URI. Todos los términos, incluidos aquellos con o sin el sufijo "Literal" específico, especifican en su definición si los valores requeridos son cadenas o URI.
+
+## 6 Índices de vocabulario (no normativos)
diff --git a/code/termlist-template/termlist-header.fr.md b/code/termlist-template/termlist-header.fr.md
index 0e02439b..716c289c 100644
--- a/code/termlist-template/termlist-header.fr.md
+++ b/code/termlist-template/termlist-header.fr.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Date de publication de la dernière mise à jour
: {ratification_date}
@@ -22,7 +22,7 @@ Version précédente
: {previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Contributeurs
: {contributors}
@@ -127,4 +127,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.ja.md b/code/termlist-template/termlist-header.ja.md
index 919291a2..6370f51a 100644
--- a/code/termlist-template/termlist-header.ja.md
+++ b/code/termlist-template/termlist-header.ja.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
バージョン発行日
: {ratification_date}
@@ -22,7 +22,7 @@ TDWG標準での該当箇所
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
貢献者
: {contributors}
@@ -127,4 +127,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.km.md b/code/termlist-template/termlist-header.km.md
index 4c177957..4438abd7 100644
--- a/code/termlist-template/termlist-header.km.md
+++ b/code/termlist-template/termlist-header.km.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Date version issued
: {ratification_date}
@@ -21,7 +21,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Contributors
: {contributors}
@@ -126,4 +126,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.ko.md b/code/termlist-template/termlist-header.ko.md
index 4c177957..4438abd7 100644
--- a/code/termlist-template/termlist-header.ko.md
+++ b/code/termlist-template/termlist-header.ko.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Date version issued
: {ratification_date}
@@ -21,7 +21,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Contributors
: {contributors}
@@ -126,4 +126,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.nl.md b/code/termlist-template/termlist-header.nl.md
index 4c177957..4438abd7 100644
--- a/code/termlist-template/termlist-header.nl.md
+++ b/code/termlist-template/termlist-header.nl.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Date version issued
: {ratification_date}
@@ -21,7 +21,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Contributors
: {contributors}
@@ -126,4 +126,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.pt.md b/code/termlist-template/termlist-header.pt.md
index 4c177957..4438abd7 100644
--- a/code/termlist-template/termlist-header.pt.md
+++ b/code/termlist-template/termlist-header.pt.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Date version issued
: {ratification_date}
@@ -21,7 +21,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Contributors
: {contributors}
@@ -126,4 +126,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.ru.md b/code/termlist-template/termlist-header.ru.md
index dba1d541..dcf831e7 100644
--- a/code/termlist-template/termlist-header.ru.md
+++ b/code/termlist-template/termlist-header.ru.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Дата публикации версии
: {ratification_date}
@@ -20,7 +20,7 @@ Title
Предыдущая версия {previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Авторы: {contributors}
@@ -122,4 +122,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.zh-Hans.md b/code/termlist-template/termlist-header.zh-Hans.md
index 4c177957..4438abd7 100644
--- a/code/termlist-template/termlist-header.zh-Hans.md
+++ b/code/termlist-template/termlist-header.zh-Hans.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
Date version issued
: {ratification_date}
@@ -21,7 +21,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
Contributors
: {contributors}
@@ -126,4 +126,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/termlist-template/termlist-header.zh-Hant.md b/code/termlist-template/termlist-header.zh-Hant.md
index b8ddb95c..f5e2fb7a 100644
--- a/code/termlist-template/termlist-header.zh-Hant.md
+++ b/code/termlist-template/termlist-header.zh-Hant.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Audiovisual Core List of Terms
Title
-: {document_title}
+: Audiovisual Core List of Terms
版本發行日期
: {ratification_date}
@@ -20,7 +20,7 @@ Title
{previous_version_slot}
Abstract
-: {abstract}
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. It aims to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them. This document contains a list of attributes of each Audiovisual Core term, including a documentation name, a specified URI, a recommended English label for user interfaces, a definition, and some ancillary notes. This document contains normative content that may not be changed without due process.
貢獻者
: {contributors}
@@ -125,4 +125,3 @@ specific "Literal" suffix, specify in their definition whether the
required values are strings or URIs.
## 6 Vocabulary Indices (non-normative)
-
diff --git a/code/variant-template/termlist-header.ar.md b/code/variant-template/termlist-header.ar.md
index 97abb0ca..6029d02c 100644
--- a/code/variant-template/termlist-header.ar.md
+++ b/code/variant-template/termlist-header.ar.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Contributors
: {contributors}
diff --git a/code/variant-template/termlist-header.cs.md b/code/variant-template/termlist-header.cs.md
index 767f7b75..9f03ea0a 100644
--- a/code/variant-template/termlist-header.cs.md
+++ b/code/variant-template/termlist-header.cs.md
@@ -1,12 +1,12 @@
-# {document_title}
+# Řízený slovník pro Audiovisual Core variant: Seznam termínů
-Title
-: {document_title}
+Název
+: Řízený slovník pro Audiovisual Core variant: Seznam termínů
-Namespace IRI
+IRI Jmenného prostoru
:
-Preferred namespace abbreviation
+Preferovaná zkratka jmenného prostoru
: acvariant:
Datum vydání verze
@@ -26,8 +26,8 @@ Aktuální verze
{previous_version_slot}
-Abstract
-: {abstract}
+Abstrakt
+: Audiovisual Core používá termíny ac:variant a ac:variantLiteral k poskytování informací o velikosti, rozsahu a dostupnosti přístupového bodu služby pro mediální položku. Tento řízený slovník poskytuje hodnoty pro tyto termíny.
Přispěvatelé
: {contributors}
@@ -38,19 +38,19 @@ Tvůrce
Bibliografická citace
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1 Úvod (informativní)
-This document includes terms intended to be used as a controlled value for Audiovisual Core terms `ac:variant` and `ac:variantLiteral`.
+Tento dokument obsahuje termíny, které mají být použity jako řízené hodnoty pro Audiovisual Core termíny `ac:variant` and `ac:variantLiteral`.
### 1.1 Status obsahu tohoto dokumentu
-Section 1 is informative (non-normative).
+Oddíl 1 je informativní (nenormativní).
Oddíl 2 je normativní.
-Section 3 is informative (non-normative).
+Oddíl 3 je informativní (nenormativní).
-V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Label` and the values of all other properties are non-normative.
+V oddíle 4 jsou hodnoty `Term IRI`, `Definice` a `Kontrolovaná hodnota` normativní. Hodnota `Použití` (pokud pro daný termín existuje) je normativní. Hodnoty `Název termínu` nejsou normativní, ačkoli lze očekávat, že prefix zkratky jmenného prostoru je prefix běžně používaný pro jmenný prostor termínu. `Štítek` a hodnoty všech ostatních vlastností nejsou normativní.
### 1.2 Klíčová slova RFC 2119
@@ -58,12 +58,12 @@ Klíčová slova "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
## 2 Použití termínů
-### 2.1 Relationship of value types to property terms
+### 2.1 Vztah hodnotových typů k pojmům vlastnictví
-In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/ac/doc/termlist/), unabbreviated term IRIs SHOULD be used as values of the property `ac:variant`. Controlled value strings SHOULD be used as values of the property `ac:variantLiteral`.
+V souladu s [dokumentem Audiovisual Core Term List](http://rs.tdwg.org/ac/doc/termlist/) by se jako hodnoty vlastnosti `ac:variant` MĚLY používat nezkrácené termíny IRI. Jako hodnoty vlastnosti `ac:variantLiteral` by se MĚLY používat řízené hodnotové řetězce.
-### 2.2 Relationship between values of ac:variantLiteral and ac:variant
+### 2.2 Vztah mezi hodnotami ac:variantLiteral a ac:variant
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `ac:variant` given a controlled value string for `ac:variantLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `ac:variant` property in cases where providers only provide values for `ac:variantLiteral`.
+IRI pro termín v tomto slovníku označuje stejný pojem jako pojem označený řízeným řetězcem hodnot pro stejný termín. Klient tedy MŮŽE odvodit hodnotu IRI pro `ac:variant` na základě řízeného řetězce hodnot pro `ac:variantLiteral`, i když tato hodnota IRI není výslovně uvedena. Praktickým důsledkem je, že agregátoři dat MOHOU materializovat hodnoty pro preferovanou vlastnost `ac:variant` v případech, kdy poskytovatelé poskytují pouze hodnoty pro `ac:variantLiteral`.
## 3 Index termínů
diff --git a/code/variant-template/termlist-header.de.md b/code/variant-template/termlist-header.de.md
index 97abb0ca..6029d02c 100644
--- a/code/variant-template/termlist-header.de.md
+++ b/code/variant-template/termlist-header.de.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Contributors
: {contributors}
diff --git a/code/variant-template/termlist-header.es.md b/code/variant-template/termlist-header.es.md
index 1fadcf10..ee228607 100644
--- a/code/variant-template/termlist-header.es.md
+++ b/code/variant-template/termlist-header.es.md
@@ -1,12 +1,12 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
-Namespace IRI
+IRI del espacio de nombres
:
-Preferred namespace abbreviation
+Abreviatura preferida del espacio de nombres
: acvariant:
Fecha de publicación de la versión
@@ -27,7 +27,7 @@ Esta versión
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Colaboradores
: {contributors}
@@ -38,19 +38,19 @@ Creador
Cita bibliográfica
: {creator}. {year}. {document_title}. {publisher}. <{current_iri}{ratification_date}>
-## 1 Introduction (informative)
+## 1. Introducción (Informativa)
-This document includes terms intended to be used as a controlled value for Audiovisual Core terms `ac:variant` and `ac:variantLiteral`.
+Este documento incluye términos destinados a ser utilizados como un valor controlado para los términos del Audiovisual Core `ac:variant` y `ac:variantLiteral`.
### 1.1 Estado del contenido de este documento
-Section 1 is informative (non-normative).
+La Sección 1 es informativa (no normativa).
La sección 2 es normativa.
-Section 3 is informative (non-normative).
+La Sección 3 es informativa (no normativa).
-En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. `Label` and the values of all other properties are non-normative.
+En la Sección 4, los valores de `Término IRI`, `Definición` y `Valor controlado` son normativos. El valor de `Uso` (si existe para un término determinado) también es normativo. Los valores del `Nombre del término` no son normativos, aunque se puede esperar que el prefijo del namespace abreviado sea uno comúnmente utilizado para ese namespace. La `Etiqueta` y los valores de todas las demás propiedades no son normativos.
### 1.2 Palabras clave RFC 2119
@@ -58,12 +58,12 @@ Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD
## 2 Uso de los Términos
-### 2.1 Relationship of value types to property terms
+### 2.1 Relación de los tipos de valor con los términos de propiedad
-In accordance with [the Audiovisual Core Term List document](http://rs.tdwg.org/ac/doc/termlist/), unabbreviated term IRIs SHOULD be used as values of the property `ac:variant`. Controlled value strings SHOULD be used as values of the property `ac:variantLiteral`.
+De acuerdo con el [documento de la Lista de términos del Audiovisual Core](http://rs.tdwg.org/ac/doc/termlist/), los términos IRI no abreviados DEBEN usarse como valores de la propiedad `ac:variant`. Las cadenas de valores controlados DEBEN usarse como valores de la propiedad ac:variantLiteral\`.
-### 2.2 Relationship between values of ac:variantLiteral and ac:variant
+### 2.2 Relación entre los valores de ac:variantLiteral y ac:variant
-An IRI for a term in this vocabulary denotes the same concept as the concept denoted by the controlled value string for the same term. Thus a client MAY infer an IRI value for `ac:variant` given a controlled value string for `ac:variantLiteral` even if that IRI is not explicitly stated. The practical implication is that data aggregators MAY materialize values for the preferred `ac:variant` property in cases where providers only provide values for `ac:variantLiteral`.
+Una IRI para un término en este vocabulario denota la misma clase que la clase denotada por la cadena de valor controlado para el mismo término. De esta manera, un usuario PUEDE inferir un valor IRI para `ac:subtype` dada una cadena de valor controlado para `ac:subtypeLiteral` incluso si ese IRI no se indica explícitamente. La implicación práctica es que los agregadores de datos PUEDEN materializar valores para la propiedad `ac:variant` preferida en casos donde los proveedores solo proporcionan valores para `ac:variantLiteral`.
## 3 Índice de Términos
diff --git a/code/variant-template/termlist-header.fr.md b/code/variant-template/termlist-header.fr.md
index f7a93f4c..f35a1e3b 100644
--- a/code/variant-template/termlist-header.fr.md
+++ b/code/variant-template/termlist-header.fr.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ Version précédente
: {previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Contributeurs
: {contributors}
diff --git a/code/variant-template/termlist-header.ja.md b/code/variant-template/termlist-header.ja.md
index cd91abae..7290e29a 100644
--- a/code/variant-template/termlist-header.ja.md
+++ b/code/variant-template/termlist-header.ja.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -28,7 +28,7 @@ TDWG標準での該当箇所
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
貢献者
: {contributors}
diff --git a/code/variant-template/termlist-header.km.md b/code/variant-template/termlist-header.km.md
index 97abb0ca..6029d02c 100644
--- a/code/variant-template/termlist-header.km.md
+++ b/code/variant-template/termlist-header.km.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Contributors
: {contributors}
diff --git a/code/variant-template/termlist-header.ko.md b/code/variant-template/termlist-header.ko.md
index 97abb0ca..6029d02c 100644
--- a/code/variant-template/termlist-header.ko.md
+++ b/code/variant-template/termlist-header.ko.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Contributors
: {contributors}
diff --git a/code/variant-template/termlist-header.nl.md b/code/variant-template/termlist-header.nl.md
index 97abb0ca..6029d02c 100644
--- a/code/variant-template/termlist-header.nl.md
+++ b/code/variant-template/termlist-header.nl.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Contributors
: {contributors}
diff --git a/code/variant-template/termlist-header.pt.md b/code/variant-template/termlist-header.pt.md
index 97abb0ca..6029d02c 100644
--- a/code/variant-template/termlist-header.pt.md
+++ b/code/variant-template/termlist-header.pt.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Contributors
: {contributors}
diff --git a/code/variant-template/termlist-header.ru.md b/code/variant-template/termlist-header.ru.md
index 0d2d66a5..c0caded4 100644
--- a/code/variant-template/termlist-header.ru.md
+++ b/code/variant-template/termlist-header.ru.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
Предыдущая версия {previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Авторы: {contributors}
diff --git a/code/variant-template/termlist-header.zh-Hans.md b/code/variant-template/termlist-header.zh-Hans.md
index 97abb0ca..6029d02c 100644
--- a/code/variant-template/termlist-header.zh-Hans.md
+++ b/code/variant-template/termlist-header.zh-Hans.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -27,7 +27,7 @@ Latest version
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
Contributors
: {contributors}
diff --git a/code/variant-template/termlist-header.zh-Hant.md b/code/variant-template/termlist-header.zh-Hant.md
index 5196beb7..250208f0 100644
--- a/code/variant-template/termlist-header.zh-Hant.md
+++ b/code/variant-template/termlist-header.zh-Hant.md
@@ -1,7 +1,7 @@
-# {document_title}
+# Controlled Vocabulary for Audiovisual Core variant: List of Terms
Title
-: {document_title}
+: Controlled Vocabulary for Audiovisual Core variant: List of Terms
Namespace IRI
:
@@ -26,7 +26,7 @@ Preferred namespace abbreviation
{previous_version_slot}
Abstract
-: {abstract}
+: Audiovisual Core uses the terms ac:variant and ac:variantLiteral to provide information about the size, extent, and availability of the Service Access Point of a media item. This controlled vocabulary provides values for those terms.
貢獻者
: {contributors}
diff --git a/docs/_data/navigation_ar.json b/docs/_data/navigation_ar.json
index e0688b84..475e1b56 100644
--- a/docs/_data/navigation_ar.json
+++ b/docs/_data/navigation_ar.json
@@ -25,23 +25,27 @@
},
{
"text": "",
- "href": "/ar/format/"
+ "href": ""
},
{
"text": "",
- "href": "/ar/orient/"
+ "href": ""
},
{
"text": "",
- "href": "/ar/part/"
+ "href": ""
},
{
"text": "",
- "href": "/ar/subtype/"
+ "href": ""
},
{
"text": "",
- "href": "/ar/variant/"
+ "href": ""
+ },
+ {
+ "text": "",
+ "href": ""
}
]
},
diff --git a/docs/_data/navigation_cs.json b/docs/_data/navigation_cs.json
index 8d11a23a..90d723a3 100644
--- a/docs/_data/navigation_cs.json
+++ b/docs/_data/navigation_cs.json
@@ -4,43 +4,47 @@
"href": "/cs/"
},
{
- "text": "",
+ "text": "Úvod",
"href": "/cs/introduction/"
},
{
"text": "Termíny",
"menu": [
{
- "text": ""
+ "text": "Hlavní slovník"
},
{
- "text": "",
+ "text": "Audiovisual Core",
"href": "/cs/termlist/"
},
{
- "text": ""
+ "text": "---"
},
{
- "text": ""
+ "text": "Řízené slovníky"
},
{
- "text": "",
+ "text": "content description",
+ "href": "/cs/cd/"
+ },
+ {
+ "text": "format",
"href": "/cs/format/"
},
{
- "text": "",
+ "text": "subjectOrientation",
"href": "/cs/orient/"
},
{
- "text": "",
+ "text": "subjectPart",
"href": "/cs/part/"
},
{
- "text": "",
+ "text": "subtype",
"href": "/cs/subtype/"
},
{
- "text": "",
+ "text": "variant",
"href": "/cs/variant/"
}
]
@@ -49,18 +53,18 @@
"text": "Návody",
"menu": [
{
- "text": "",
+ "text": "Uživatelská příručka",
"href": "/cs/guide/"
},
{
- "text": "",
+ "text": "Struktura",
"href": "/cs/structure/"
}
]
},
{
"text": "GitHub",
- "href": ""
+ "href": "https://github.com/tdwg/ac"
},
{
"text": "文A",
diff --git a/docs/_data/navigation_de.json b/docs/_data/navigation_de.json
index 43f8ec3c..7631a884 100644
--- a/docs/_data/navigation_de.json
+++ b/docs/_data/navigation_de.json
@@ -23,6 +23,10 @@
{
"text": ""
},
+ {
+ "text": "",
+ "href": "/de/cd/"
+ },
{
"text": "",
"href": "/de/format/"
diff --git a/docs/_data/navigation_es.json b/docs/_data/navigation_es.json
index df67e9b7..93e95608 100644
--- a/docs/_data/navigation_es.json
+++ b/docs/_data/navigation_es.json
@@ -4,43 +4,47 @@
"href": "/es/"
},
{
- "text": "",
- "href": ""
+ "text": "Introducción",
+ "href": "/introducción/"
},
{
"text": "Términos",
"menu": [
{
- "text": ""
+ "text": "Vocabulario Principal"
},
{
- "text": "",
+ "text": "Audiovisual Core",
"href": "/es/termlist/"
},
{
- "text": ""
+ "text": "---"
},
{
- "text": ""
+ "text": "Vocabularios controlados"
},
{
- "text": "",
+ "text": "descripción del contenido",
+ "href": "/es/cd/"
+ },
+ {
+ "text": "formato",
"href": "/es/format/"
},
{
- "text": "",
+ "text": "subjectOrientation",
"href": "/es/orient/"
},
{
- "text": "",
+ "text": "subjectPart",
"href": "/es/part/"
},
{
- "text": "",
+ "text": "subtipo",
"href": "/es/subtype/"
},
{
- "text": "",
+ "text": "variante",
"href": "/es/variant/"
}
]
@@ -49,18 +53,18 @@
"text": "Guías",
"menu": [
{
- "text": "",
+ "text": "Manual del Usuario",
"href": "/es/guide/"
},
{
- "text": "",
+ "text": "Estructura",
"href": "/es/structure/"
}
]
},
{
"text": "GitHub",
- "href": ""
+ "href": "https://github.com/tdwg/ac"
},
{
"text": "文A",
diff --git a/docs/_data/navigation_fr.json b/docs/_data/navigation_fr.json
index ff7d4be8..3daf9075 100644
--- a/docs/_data/navigation_fr.json
+++ b/docs/_data/navigation_fr.json
@@ -23,6 +23,10 @@
{
"text": ""
},
+ {
+ "text": "",
+ "href": "/fr/cd/"
+ },
{
"text": "",
"href": "/fr/format/"
diff --git a/docs/_data/navigation_ja.json b/docs/_data/navigation_ja.json
index b7adcc76..55e9a737 100644
--- a/docs/_data/navigation_ja.json
+++ b/docs/_data/navigation_ja.json
@@ -25,23 +25,27 @@
},
{
"text": "",
- "href": "/ja/format/"
+ "href": ""
},
{
"text": "",
- "href": "/ja/orient/"
+ "href": ""
},
{
"text": "",
- "href": "/ja/part/"
+ "href": ""
},
{
"text": "",
- "href": "/ja/subtype/"
+ "href": ""
},
{
"text": "",
- "href": "/ja/variant/"
+ "href": ""
+ },
+ {
+ "text": "",
+ "href": ""
}
]
},
diff --git a/docs/_data/navigation_km.json b/docs/_data/navigation_km.json
index b8c454f8..1e9aa183 100644
--- a/docs/_data/navigation_km.json
+++ b/docs/_data/navigation_km.json
@@ -39,6 +39,10 @@
"text": "",
"href": ""
},
+ {
+ "text": "",
+ "href": ""
+ },
{
"text": "",
"href": ""
diff --git a/docs/_data/navigation_ko.json b/docs/_data/navigation_ko.json
index c9872043..3f592ebd 100644
--- a/docs/_data/navigation_ko.json
+++ b/docs/_data/navigation_ko.json
@@ -25,23 +25,27 @@
},
{
"text": "",
- "href": "/ko/format/"
+ "href": ""
},
{
"text": "",
- "href": "/ko/orient/"
+ "href": ""
},
{
"text": "",
- "href": "/ko/part/"
+ "href": ""
},
{
"text": "",
- "href": "/ko/subtype/"
+ "href": ""
},
{
"text": "",
- "href": "/ko/variant/"
+ "href": ""
+ },
+ {
+ "text": "",
+ "href": ""
}
]
},
diff --git a/docs/_data/navigation_nl.json b/docs/_data/navigation_nl.json
index ad2251d9..ea92bb95 100644
--- a/docs/_data/navigation_nl.json
+++ b/docs/_data/navigation_nl.json
@@ -25,23 +25,27 @@
},
{
"text": "",
- "href": "/nl/format/"
+ "href": ""
},
{
"text": "",
- "href": "/nl/orient/"
+ "href": ""
},
{
"text": "",
- "href": "/nl/part/"
+ "href": ""
},
{
"text": "",
- "href": "/nl/subtype/"
+ "href": ""
},
{
"text": "",
- "href": "/nl/variant/"
+ "href": ""
+ },
+ {
+ "text": "",
+ "href": ""
}
]
},
diff --git a/docs/_data/navigation_pt.json b/docs/_data/navigation_pt.json
index c03ca7b8..cbd9290a 100644
--- a/docs/_data/navigation_pt.json
+++ b/docs/_data/navigation_pt.json
@@ -25,23 +25,27 @@
},
{
"text": "",
- "href": "/pt/format/"
+ "href": ""
},
{
"text": "",
- "href": "/pt/orient/"
+ "href": ""
},
{
"text": "",
- "href": "/pt/part/"
+ "href": ""
},
{
"text": "",
- "href": "/pt/subtype/"
+ "href": ""
},
{
"text": "",
- "href": "/pt/variant/"
+ "href": ""
+ },
+ {
+ "text": "",
+ "href": ""
}
]
},
diff --git a/docs/_data/navigation_ru.json b/docs/_data/navigation_ru.json
index 8cd24b38..8ceaa643 100644
--- a/docs/_data/navigation_ru.json
+++ b/docs/_data/navigation_ru.json
@@ -25,23 +25,27 @@
},
{
"text": "",
- "href": "/ru/format/"
+ "href": ""
},
{
"text": "",
- "href": "/ru/orient/"
+ "href": ""
},
{
"text": "",
- "href": "/ru/part/"
+ "href": ""
},
{
"text": "",
- "href": "/ru/subtype/"
+ "href": ""
},
{
"text": "",
- "href": "/ru/variant/"
+ "href": ""
+ },
+ {
+ "text": "",
+ "href": ""
}
]
},
diff --git a/docs/_data/navigation_zh-Hans.json b/docs/_data/navigation_zh-Hans.json
index 7168b144..bbff073a 100644
--- a/docs/_data/navigation_zh-Hans.json
+++ b/docs/_data/navigation_zh-Hans.json
@@ -25,23 +25,27 @@
},
{
"text": "",
- "href": "/zh-Hans/format/"
+ "href": ""
},
{
"text": "",
- "href": "/zh-Hans/orient/"
+ "href": ""
},
{
"text": "",
- "href": "/zh-Hans/part/"
+ "href": ""
},
{
"text": "",
- "href": "/zh-Hans/subtype/"
+ "href": ""
},
{
"text": "",
- "href": "/zh-Hans/variant/"
+ "href": ""
+ },
+ {
+ "text": "",
+ "href": ""
}
]
},
diff --git a/docs/_data/navigation_zh-Hant.json b/docs/_data/navigation_zh-Hant.json
index b8451f90..15734aee 100644
--- a/docs/_data/navigation_zh-Hant.json
+++ b/docs/_data/navigation_zh-Hant.json
@@ -25,23 +25,27 @@
},
{
"text": "",
- "href": "/zh-Hant/format/"
+ "href": ""
},
{
"text": "",
- "href": "/zh-Hant/orient/"
+ "href": ""
},
{
"text": "",
- "href": "/zh-Hant/part/"
+ "href": ""
},
{
"text": "",
- "href": "/zh-Hant/subtype/"
+ "href": ""
},
{
"text": "",
- "href": "/zh-Hant/variant/"
+ "href": ""
+ },
+ {
+ "text": "",
+ "href": ""
}
]
},
diff --git a/docs/ar/guide/index.md b/docs/ar/guide/index.md
new file mode 100644
index 00000000..93b189ca
--- /dev/null
+++ b/docs/ar/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Status of the content of this document
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Label |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Label |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/ar/introduction/index.md b/docs/ar/introduction/index.md
index fbace2b6..9175b943 100644
--- a/docs/ar/introduction/index.md
+++ b/docs/ar/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 Introduction
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/ar/structure/index.md b/docs/ar/structure/index.md
new file mode 100644
index 00000000..95eb7c14
--- /dev/null
+++ b/docs/ar/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Status of the content of this document
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 key words
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/cs/guide/index.md b/docs/cs/guide/index.md
new file mode 100644
index 00000000..b615d62b
--- /dev/null
+++ b/docs/cs/guide/index.md
@@ -0,0 +1,747 @@
+# Příručka Audiovisual Core
+
+Název
+: Příručka Audiovisual Core
+
+Datum vydání verze
+: 2023-02-24
+
+Datum vytvoření
+: 2013-10-15
+
+Součást TDWG Standardu
+:
+
+Tato verze
+:
+
+Poslední verze
+:
+
+Předchozí verze
+:
+
+Abstrakt
+: Audiovisual Core je soubor slovníků určených k reprezentaci metadat pro multimediální zdroje a sbírky týkající se biologické rozmanitosti. Tento nenormativní dokument poskytuje některé základní informace o cílech a použití normy.
+
+Přispěvatelé
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Tvůrce
+: GBIF/TDWG Pracovní skupina pro multimediální zdroje a Skupina pro údržbu audiovizuálního jádra
+
+Bibliografická citace
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Příručka Audiovisual Core. Biodiversity Information Standards (TDWG).
+
+## 1. Úvod
+
+Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) je datový standard pro výměnu dat popisujících multimediální zdroje a sbírky týkající se biologické rozmanitosti, který vytvořila společná pracovní skupina GBIF/TDWG pro metadata multimediálních zdrojů (MRTG). Norma se skládá ze čtyř dokumentů. Tento dokument je průvodcem po cílech a použití normy. Dokument Úvod do Audiovisual
+Core poskytuje stručný úvod do Audiovisual Core Standard. Podrobné informace o struktuře Audiovisual Core naleznete v dokumentu [Audiovisual Core Structure](structure). Podrobnosti o termínech najdete v dokumentu [Seznam termínů Audiovisual Core](terms).
+
+Zkratky a názvy institucí a projektů jsou uvedeny ve slovníku v
+příloze I.
+
+### 1.1 Status obsahu tohoto dokumentu
+
+Všechny části tohoto dokumentu jsou nenormativní.
+
+## 2 Shrnutí
+
+Audiovisual Core Multimedia Resources Metadata schema („schéma AC“ nebo
+jednoduše „AC“) je soubor slovníků metadat pro popis
+multimediálních zdrojů a sbírek souvisejících s biologickou rozmanitostí. Specifikace
+je nezávislá na tom, jak mohou být tyto slovníky
+zobrazeny pro strojové využití.
+
+Multimediální zdroje jsou digitální nebo fyzické artefakty, které obvykle
+obsahují více než jen text. Mezi ně patří obrázky, umělecká díla, kresby,
+fotografie, zvukové záznamy, videa, animace, prezentační materiály a
+interaktivní online média, včetně např. identifikačních nástrojů. Multimediální
+sbírka je souborem takovýchto objektů, ať už kurátorských
+či nikoli, a ať už elektronicky přístupných či nikoli. Pro účely
+tohoto dokumentu považujeme soubor multimediálních zdrojů sám o sobě
+za ‘multimediální zdroj’. Kdykoli se diskuse nebo specifikace může
+vztahovat pouze na sbírku nebo pouze na jeden mediální zdroj, výslovně to uvádíme.
+
+Multimediální popisy jsou digitální záznamy, které dokumentují základní
+multimediální zdroje nebo sbírky. AC se zaměřuje na
+multimediální zdroje související s biologickou rozmanitostí. Sdílí terminologii a
+zájmy s mnoha známými a důležitými standardy pro popis
+přístupu k zdrojům, jako jsou Dublin Core (DC), Darwin Core (DwC),
+Adobe Extensible Metadata Platform (XMP), International Press and
+Telecommunications Council (IPTC), Metadata Working Group (MWG)
+schema, Natural Collections Schema (NCD) a další. V případě
+přesné shody s použitím těchto standardů přijímá AC jejich
+identifikátory a definice. Mnohé sbírky multimédií o biologické rozmanitosti
+již obsahují popisy svých médií vyjádřené v DwC nebo DC. Použitím
+těchto slovníků tam, kde je to vhodné, chce AC zejména usnadnit
+opětovné použití stávajících popisů v těchto sbírkách,
+v případě potřeby doplněných o další termíny.
+
+Tato příručka doprovází normativní části standardu AC,
+které jsou obsaženy ve dvou dokumentech: v dokumentu popisujícím strukturu dokumentu [\[1\]](#fn-1)
+a v dokumentu se seznamem termínů [\[2\]](#fn-2). Seznam termínů
+dokumentuje řadu termínů, z nichž každý je identifikován jedinečným
+identifikátorem URI (Uniform Resource Identifier), spolu s normativními definicemi.
+Kromě toho může skupina Audiovisual Core Maintenance Group vyvinout doporučené reprezentace pro popisy AC v několika důležitých formátech, včetně RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4) a Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Obrázek 1 níže doplňuje část obrázku 2 nenormativní
+části dokumentu NCD [\[6\]](#fn-6). Ukazuje řadu druhů
+zdrojů zaměřených na data o biologické rozmanitosti a ilustruje typické uživatelské
+komunity, standardy dat a metadat a síťové služby, které
+podporují vyhledávání, analýzu a integraci dat. Z údajů NCD jsme extrahovali
+zdroje a vztahy mezi nimi, které
+jsme doplnili o tři typy, které nespadají do hlavní působnosti NCD. Jedná se o:
+Pozorování, ekologické modely a zaměření této práce, multimediální
+zdroje. Aplikace využívající každý z těchto druhů zdrojů nacházejí
+uplatnění, nebo někdy vyžadují použití multimediálních zdrojů k
+jejich dokumentaci. Například Biological Heritage Library je projekt,
+který poskytuje naskenované obrázky starší literatury v mnohem větším rozsahu,
+než kolik může poskytnout digitalizovaných verzí založených na optickém rozpoznávání znaků,
+a tyto obrázky zůstávají k dispozici jako zdroje pro jakékoli
+následné odvozené produkty. Digitálně zpracovaná historická literatura je tedy
+dokumentována pomocí obrázků stránek. Většina vědecké literatury je samozřejmě také ilustrována fotografiemi, grafy nebo jinými artefakty, které spadají do působnosti Audiovisual Core. Dokonce i poskytovatelé zdrojů „molekulární DNA“ někdy nabízejí původní data ve formě digitálních obrazů na mikročipech.
+
+
+
+Obrázek 1. Vztahy multimediálních zdrojů k primárním typům
+zdrojů biologické rozmanitosti
+
+## 3 termíny Audiovisual Core
+
+Záznam Audiovisual Core je popis multimediálního zdroje pomocí termínů Audiovisual Core. AC specifikuje dva druhy termínů:
+_termíny na úrovni záznamu_ a _termíny na úrovni přístupu._ Termíny na úrovni záznamu se vztahují
+k popisovanému mediálnímu zdroji. Téměř všechny termíny jsou termíny na úrovni záznamu. Jeden z těchto termínů, _serviceAccessPoint_, hraje zvláštní roli při
+vyhledávání zdroje, který záznam popisuje. Multimediální
+zdroj může mít více než jeden serviceAccessPoint, z nichž každý je
+popsán hodnotami jednoho nebo více termínů přístupové úrovně. Termíny na úrovni přístupu
+poskytují informace, jako je webová adresa, na které lze získat digitální
+zobrazení zdroje, velikost takového
+získaného objektu atd.
+
+Záznam Audiovisual Core je tedy soubor termínů, který je v souladu s
+normativními dokumenty, obsahuje alespoň čtyři povinné termíny
+popsané níže a poskytuje metadata popisující jeden
+multimediální zdroj (případně včetně sbírky). Obvykle obsahuje identifikátor, který mohl být zdroji přidělen externí autoritou nebo poskytovatelem záznamu metadat.
+
+Každý termín Audiovisual Core má prostý textový název, URI a prostý textový
+normativní definici. Termíny mohou také obsahovat pokyny k použití, které vysvětlují, jak se termín používá v kontextu Audiovisual Core, a poznámky, které poskytují další informace a příklady. URI pro termíny odpovídají schématu http URI.
+Neformálně lze toto pochopit takto: http URI má syntaxi
+http URL, ale neočekává se, že jeho zadání do webového
+prohlížeče povede k vrácení jakýchkoli informací do prohlížeče,
+a pokud ano, vrácené informace nemusí mít žádný význam.
+
+Protože adresy URL jsou poměrně dlouhé, dokumenty AC se řídí standardní
+praxí zavádění krátké předpony sestávající z „kvalifikátoru jmenného prostoru“
+odděleného dvojtečkou od mnemotechnického názvu úzce souvisejícího s
+názvem termínu. Jmenný prostor termínů převzatých z jiných slovníků je stejný jako jmenný prostor původních termínů. Jmenný prostor termínů denovo AC je
+http://rs.tdwg.org/ac/terms/. V tabulce termínů má každý termínový záznam
+řádek s názvem termínu. V souladu s praxí Darwin Core term
+list [\[7\]](#fn-7) je název tohoto termínu v případě vypůjčených termínů obecně
+„nekvalifikovaným názvem“, před kterým je uvedena široce přijímaná předpona označující
+zkratku pro jmenný prostor, zatímco u termínů AC denovo není taková
+předpona před termínem uvedena. Implementátorům, kteří potřebují předponu jmenného prostoru pro jmenný prostor AC, se doporučuje používat "ac", kdykoli je to možné. Výsledek
+se nazývá kvalifikovaný název. Například normativní wiki
+dokumentace pro vypůjčený termín dcterms:identifier má URI
+http://purl.org/dc/terms/identifier. V tomto dokumentu budeme dodržovat zavedenou
+konvenci kvalifikovaných názvů. Ve
+skutečnosti se většina URI pro termíny převzaté z externích slovníků
+(asi polovina z nich) ve skutečnosti odkazuje na něco v příslušné
+dokumentaci pro daný externí standard. Někdy to není přesné,
+protože dokumentace je ve formátu PDF a několik (různých\!)
+URI mohou zřejmě směřovat na stejné místo.
+
+Příklady z termínového seznamu jsou uvedeny
+níže.
+
+
+
+
+ | Název termínu: |
+ dcterms:type |
+
+
+ | Normativní URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Štítek |
+ Typ |
+
+
+ |
+ Vrstva: 1 — Požadováno: Ano — Opakovatelné: Ne |
+
+
+ | Definice: |
+ Povaha nebo druh zdroje. |
+
+
+ | Použití: |
+ Úplný URI, nejlépe z typu URI specifikovaného ve slovníku typů DCMI, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Doporučené termíny jsou ty URI, jejichž označení jsou Collection, StillImage, Sound, MovingImage, InteractiveResource nebo Text (např. . Doporučujeme také úplné URI adresy ac:PanAndZoomImage, ac:3DStillImage a ac: 3DMovingImage. Hodnoty NESMÍ být řetězcem, ale URI s úplným jmenným prostorem (např. z řízeného slovníku. Implementátoři a komunity praxe mohou určit, zda je nutné používat konkrétní řízené slovníky. Pokud je zdroj sbírkou, tato položka neurčuje, jaké typy objektů může obsahovat. V souladu s doporučeními DC na adrese http://purl.org/dc/dcmitype/Text by obrázky textu měly mít tuto URI. |
+
+
+ | Poznámky: |
+ V souladu s doporučeními DC pro typ textu http://purl.org/dc/terms/DCMIType by obrázky textu měly být uvedeny jako http://purl.org/dc/dcmitype/Text, pokud jsou uvedeny jako URI. Viz také heslo dc:type v dokumentu Audiovisual Core term list (Seznam základních audiovizuálních termínů) a viz DCMI FAQ on DC and DCTERMS Namespaces (Často kladené otázky týkající se jmenných prostorů DC a DCTERMS), https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, kde se diskutuje o důvodech pro použití termínů ve dvou jmenných prostorech. Obvyklým postupem je použít stejný štítek, pokud jsou k dispozici oba. Štítky nemají žádný vliv na vyhledávání informací a slouží pouze jako doporučení. Je nutné zadat alespoň jeden z údajů dc:type a dcterms:type, ale pokud je to možné, zadání obou údajů může zvýšit užitečnost metadat. Hodnoty každého z nich by měly označovat stejný typ, ale v případě nejednoznačnosti má přednost dcterms:type. |
+
+
+
+
+
+
+
+ | Název termínu: |
+ ac:reviewerLiteral |
+
+
+ | Normativní URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Štítek |
+ Recenzent |
+
+
+ |
+ Vrstva: 2 — Požadováno: Ne — Opakovatelné: Ano |
+
+
+ | Definice: |
+ Řetězec obsahující jméno recenzenta. Pokud je přítomen, pak je zdroj recenzován, i když komentáře recenzenta chybí nebo jsou prázdné. Jeho přítomnost udává, zda odborník na dané téma, o kterém se píše v médiích, recenzoval daný mediální příspěvek nebo sbírku a schválil popis jeho metadat; musí být uvedeno jméno nebo doslovný výraz „anonymní“ (= anonymně recenzováno). |
+
+
+ | Poznámky: |
+ Poskytovatel tvrdí, že tuto recenzi přijímá jako kompetentní. Viz také ac:reviewer a část Jmenné prostory, předpony a názvy termínů v dokumentu Audiovisual Core Term List, kde se diskutuje o důvodech pro oddělení termínů, které používají hodnoty URI, od termínů, které používají textové hodnoty, pokud jsou možné obě varianty. Obvyklým postupem je použít stejný štítek, pokud jsou k dispozici oba. Štítky nemají žádný vliv na vyhledávání informací a slouží pouze jako doporučení. |
+
+
+
+
+Hlavní kvalifikátory jmenného prostoru pro termínové URI v tomto dokumentu jsou
+
+- **dcterms:** a **dc:** Slovník DCMI dokumentovaný na adrese
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** Slovník Darwin Core popsaný na adrese
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geografická rozšíření IPTC s jmenným prostorem
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ zdokumentovaná v
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Termíny v jmenném prostoru http://rs.tdwg.org/ac/terms které nepocházejí
+ z jiných řízených slovníků. Normativní definice těchto dokumentů lze nalézt v [dokumentu Seznam termínů Audiovisual Core](termlist.md)
+
+- **xmp:** Slovníky Adobe XMP s jmenným prostorem
+ http://ns.adobe.com/xap/1.0/, dokumentované v oddíle 8.4 dokumentu
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** Slovník práv Adobe XMP s jmenným prostorem
+ http://ns.adobe.com/xap/1.0/rights, dokumentovaný v oddíle 8.5 na adrese
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Další vlastnosti Adobe XMP s jmenným prostorem http://ns.adobe.com/photoshop/1.0/ jsou dokumentovány na adrese http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** slovník formátu Exchangeable Image File Format asociace Camera and Imaging Products Association s jmenným prostorem http://ns.adobe.com/exif/1.0/ zdokumentovaný v http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivace a odůvodnění
+
+Existuje mnoho cenných multimediálních zdrojů, které neobsahují žádné informace uložené v databázích. Někteří mohou mít webovou prezentaci, jiní nikoli. I ty, které jsou
+dostupné online, nemusí být pro vyhledávače dostatečně zjistitelné,
+nebo se mohou ztratit v záplavě obrázků z nespolehlivých zdrojů. Stručný
+popisný záznam, jak je definován standardem Audiovisual Core, může sloužit jako
+„vizitka“ multimediálního zdroje a poskytovat dostatek
+informací k identifikaci a vyhledání mediálních zdrojů výzkumníky,
+agregátory, rozhodovacími činiteli, pedagogy nebo širokou veřejností.
+
+Standard umožňuje agregaci popisů multimediálních zdrojů
+z mnoha zdrojů a usnadňuje vyhledávání zdrojů, včetně
+vytváření vztahů mezi multimediálními zdroji na několika
+místech. Záznamy AC lze také použít jako pomůcku pro procesy správy multimediálních
+zdrojů, což umožňuje instituci udělat krok
+zpět a zjistit, které sbírky nejvíce potřebují konzervaci nebo by
+měly vyšší prioritu pro katalogizaci na úrovni jednotlivých položek.
+
+Mezi důležité využití identifikované pracovní skupinou, které jsou usnadněny
+metadaty, patří:
+
+1. Objevování;
+
+2. Hodnocení vhodnosti použití před načtením zdroje
+ (zejména relevantní pro offline zdroje);
+
+3. Použití záznamů metadat jako potenciálního důkazu výskytu taxonu nebo
+ jiných biologických závěrů, jako jsou důkazy o interakcích druhů, stanovištích a fenotypových variacích;
+
+4. Identifikační pomůcky;
+
+5. Snížení zátěže poskytovatelů a producentů multimediálních zdrojů při
+ shromažďování a poskytování zdrojů od široké škály
+ producentů a správců, zejména těch, kteří mají malé nebo žádné znalosti
+ v oblasti IT nebo podpory.
+
+Aby byly překážky použití co nejmenší, jsou pouze čtyři
+vlastnosti záznamu Audiovisual Core považovány za povinné:
+
+1. Identifikátor (dcterms:identifier): libovolný kód, který je jedinečný
+ pro daný zdroj, přičemž zdrojem může být poskytovatel,
+ sbírka nebo mediální položka. Zatímco identifikátor musí být globálně
+ jedinečný pro poskytovatele a sbírky (např. URI), identifikátory pro
+ mediální položky mohou být jedinečné pouze v kontextu sbírky nebo
+ poskytovatele. Ve skutečnosti standard důrazně doporučuje, ale nevyžaduje
+ identifikátor pro mediální položky, ačkoli jej vyžaduje pro
+ poskytovatele nebo sbírku.
+
+2. Typ (dcterms:type): Lze použít jakýkoli termín typu dcmi z
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary.
+ Doporučené termíny jsou Collection (sbírka), StillImage (statický obrázek), Sound (zvuk), MovingImage (pohyblivý obrázek),
+ InteractiveResource (interaktivní zdroj) a Text.
+
+3. Jazyk metadat (ac:MetadataLanguage): Jazyk popisu a
+ dalších metadat (ale ne nutně samotného obrázku)
+
+4. Prohlášení o autorských právech (dcterms:rights): Informace o právech držených
+ v rámci daného zdroje a nad ním. Úplné znění čitelného prohlášení o autorských právech,
+ jak vyžadují vnitrostátní právní předpisy držitele autorských práv. U
+ sbírek se to vztahuje na všechny obsažené objekty, pokud
+ objekt sám nemá jiné prohlášení. Pokud je to možné, doporučuje se také
+ uvedení vlastníka autorských práv pomocí xmpRights:Owner
+
+Kromě toho se důrazně doporučuje uvést stručný název zdroje
+pomocí dcterms:title
+
+## 5 Stávající normy
+
+Audiovisual Core má v úmyslu poskytovat metadata, která popisují buď samotné mediální
+zdroje, nebo jejich sbírky. Existuje několik
+známých nebo nově vznikajících standardů, které se těmito otázkami zabývají, takže
+by se dalo položit otázku: proč je prostě nepoužít? Ve skutečnosti AC dělá přesně to v
+přibližně polovině svých 80 prvků, z nichž téměř všechny jsou volitelné. Jak je
+uvedeno výše, většina povinných termínů pochází z externích
+řízených slovníků. Všechny existující řízené slovníky,
+zejména široce používaný Dublin Core, však nabízejí velmi málo možností
+poskytovat metadata obsahu mediálních zdrojů, která jsou specificky
+biologicky relevantní. Použití samotného Dublin Core by
+ztěžovalo vyhledávání mediálních zdrojů s vysokou přesností. Jedním z důsledků použití pouze Dublin Core by tedy bylo, že dotazy nebudou dostatečně selektivní. Naproti tomu standard Darwin Core TDWG [\[8\]](#fn-8)
+některé z těchto otázek více podporuje, ale málo se zabývá důležitými
+otázkami práv duševního vlastnictví nebo způsoby vyjádření vztahů
+mezi alternativními verzemi mediálních zdrojů (např. verzemi s různým rozlišením). Na druhou stranu ani jeden z těchto kontrolovaných slovníků nemá
+mechanismy pro zachycení technických metadat, jako jsou EXIF, které
+samotné zobrazovací systémy nebo nástroje pro vkládání metadat, jako je Adobe
+Photoshop(tm) a open source editor obrázků GIMP, mohou vkládat do
+mediálních souborů a streamů. Abychom tento problém vyřešili a podpořili výše uvedené cíle,
+mělo by být Audiovisual Core považováno za syntézu DC,
+DwC a, tam kde jsou tyto formáty nedostatečné, některých progresivních standardů metadat,
+které výrobci kamer v současné době plánují
+podporovat v samotných kamerách, podobně jako nyní používají EXIF [\[9\]](#fn-9).
+Pokud některá z těchto norem postačuje, jsou termíny a definice metadat AC
+termíny a definicemi těchto norem. V některých případech jsme zjistili, že žádný z
+těchto návrhů neřeší problémy, které podle našich zkušeností trápí širokou
+škálu přispěvatelů obrázků, zejména těch, kteří mají omezený přístup k
+sofistikovaným IT pracovníkům nebo digitálním knihovníkům. Schéma AC lze považovat za rozšíření sjednocení malých podskupin několika přijatých standardů (spolu s rámcem, který zajišťuje, že použití metadat z těchto standardů mohou lidé i stroje chápat jako odkaz na stejný zdroj). Jinými slovy, velkou část AC lze
+považovat za obal kolem DwC, DC, XMP a IPTC [\[10\]](#fn-10).
+
+Vzhledem k tomu, že drtivá většina polí metadat AC je volitelná,
+poskytovatel zdrojů, který již může poskytovat metadata Dublin Core, by
+v podstatě nemohl poskytovat nic jiného než to, plus vhodný globálně jedinečný
+identifikátor, který by propojil všechna metadata se stejným objektem. Podobně
+poskytovatel, který popisuje obsah obrázku výhradně pomocí termínů Darwin Core, nemusí
+dělat o moc víc. Oba tito poskytovatelé by však zjistili, že
+služby s přidanou hodnotou, jako jsou indexovače metadat a agregátory mezipaměti,
+by byly méně pravděpodobné, že by uchovávaly odkazy na své mediální zdroje a
+metadata, než kdyby měly bohatší metadata. To poskytovatelům dává jasnou strategii,
+jak zvýšit užitečnost svých multimediálních zdrojů s
+malým nebo žádným dopadem na jejich služby IT kyberinfrastruktury. Možná budou
+potřebovat pouze aktualizovat přiřazení mezi svými interními názvy polí a
+metadatovými termíny specifikovanými AC, jakmile budou mít k dispozici personál, který to provede.
+Jakmile bude k dispozici více zdrojů pro zaznamenávání dalších metadat a jakmile
+vzniknou mechanismy komunitních anotací, které to podpoří, budou moci přidávat
+další metadata tempem, které si samy určí podle svých zdrojů. Pokud
+sběratelé metadat sledují (volitelnou) vlastnost Metadata Date
+(xmp:MetadataDate), mohou být aktualizovaná metadata automaticky načtena
+těmito službami s přidanou hodnotou a více dotazů vrátí metadata poskytovatele
+a odkazy na jeho mediální zdroje.
+
+## 6 Časté obavy týkající se jiných standardů pro informace o biologické rozmanitosti
+
+Audiovisual Core považuje sbírky multimediálních zdrojů samotné
+za druh zdroje. Mnoho typů sbírek lze popsat v
+navrhovaném standardu TDWG Natural History Collections (NCD). Pokud
+poskytovatel chce pouze umožnit vyhledávání multimediální sbírky
+bez ohledu na vyhledávání a přístup k jejímu obsahu (kromě
+podsbírek), často nebude mít význam, zda jsou poskytována metadata NCD nebo AC,
+nebo obojí. To platí tím spíše, pokud mají NCD
+CollectionIdentifier a Audiovisual Core Identifier stejnou
+hodnotu. Zatímco typy Audiovisual Core Collection jsou bohatší než typy NCD,
+zůstává otevřenou otázkou, zda je rozmanitost Audiovisual Core v tomto případě
+užitečná.
+
+Existuje značné překrývání s používáním termínů Darwin Core, zejména pokud jde o
+taxonomické, geografické a časové pokrytí dat
+popisovaných záznamem metadat. Pro většinu těchto metadat používáme termíny DwC a celý slovník geolokace Darwin Core
+je zahrnut jako reference. GPS souřadnice, které jsou stále častěji součástí
+obrazových dat pořízených fotoaparáty, lze snadno přiřadit k „doslovným“
+lokálním termínům Darwin Core.
+
+## 7 Problémy, které nejsou zdůrazněny v jiných standardech pro informace o biologické rozmanitosti
+
+Některé z zde zmíněných problémů se týkají také bibliografických
+metadat, jako je Dublin Core. Tyto otázky však nejsou výslovně
+podrobně řešeny ve stávajících standardech TDWG pro biologickou rozmanitost a některé z nich
+nejsou dostatečně řešeny ani v DC. Některé z těchto obav jsou uvedeny níže.
+
+**Velikost**: Jednotlivé multimediální zdroje, jako jsou obrázky a zejména
+videa a zvuky, jsou ve srovnání se záznamy o vzorcích, pozorovacími
+údaji nebo popisy druhů velmi velké. Hlavním důsledkem toho je, že
+multimediální metadata musí podporovat případy použití, ve kterých lidé nebo softwaroví
+agenti mohou, aniž by museli načítat zdroj, pokusit se posoudit vhodnost
+podkladového mediálního zdroje pro požadované použití, obvykle pomocí
+vyhledávání založeného na podrobném kontrolovaném slovníku. Bez
+náhodného vyhledávání v přirozeném jazyce však není možné, ani při
+použití DC a DwC, aby poskytovatel metadat odpověděl na požadavek typu
+„Poskytněte mi velikosti a přístupové body URL pro statické obrázky
+_Dictyophora indusiata_, které mají k dispozici španělská metadata“.
+
+**Práva duševního vlastnictví**: DwC popisuje fyzické objekty, jejichž vlastnictví se obecně řídí majetkovými zákony, které nejsou považovány za součást souboru práv duševního vlastnictví. Některé připravované normy týkající se vědecké literatury se těmito otázkami zabývají, ale málokdy jsou otázky týkající se povolení k reprodukci publikací tak rozmanité jako v případě multimédií, která byla v minulosti považována za kreativní umělecká díla, nikoli nutně za fakta.
+
+**Původ**: U všech vědeckých údajů je samozřejmě důležité vědět, jak a kdy mohly být údaje od svého původního shromáždění změněny.
+To je zvláště důležité pro média, která jsou běžně upravována pro ten či onen účel. Pokud se to provede neopatrně, může to zničit část užitečnosti upraveného objektu. Žádné normy TDWG ani navrhované normy se nezdají být velmi robustní, pokud jde o provenienci, včetně Audiovisual Core, který poskytuje pouze vlastnost Derived From (odvozeno z) za účelem poskytnutí odkazu na jiný zdroj. To je do jisté míry podobné termínu NCD DerivedCollection, který identifikuje záznam kolekce jako vytvořený dotazem na jinou kolekci. To však zjevně neidentifikuje zdrojovou sbírku ani dotaz. Budoucí verze Audiovisual Core přidá další termíny týkající se původu.
+
+## 8 Popisy multimediálních zdrojů
+
+Termín multimediální zdroje zahrnuje širokou škálu objektů, které jsou zajímavé pro biology a komunity, s nimiž spolupracují v oblasti výzkumu, vzdělávání a veřejných služeb. Některé příklady multimédií jsou známé. To zahrnuje:
+
+- Statické snímky z fotoaparátů, skenerů nebo lékařských a průmyslových zobrazovacích zařízení
+
+- Filmy se zvukem nebo bez zvuku
+
+- Zvukové nahrávky
+
+V některých z výše uvedených případů mohou tyto zdroje existovat v elektronické nebo neelektronické podobě nebo v obou. Elektronická forma může být analogová nebo digitální, přičemž digitální forma je vhodnější pro ukládání a výměnu s počítači. Digitální forma může být digitální od počátku, tj. původně zachycena jako digitální objekt, nebo může být vytvořena z nedigitálního objektu. Stejně jako v případě záznamů o biologických vzorcích, publikací, terénních poznámek, experimentálních dat a dalších artefaktů vědecké praxe existuje velké množství takového materiálu, který dosud nebyl digitalizován, ale který může být k dispozici, i když s většími náklady a nepohodlím než digitální zdroje. Tyto analogové (včetně papírových) zdroje stále vyžadují popisná metadata, aby se usnadnilo jejich vyhledávání a ověřila se jejich vhodnost pro použití. Stejně důležité je, že některá metadata mají sama o sobě vědecký a vzdělávací význam, i když daný objekt není snadno přístupný. Jedním z takových použití je důkaz o výskytu georeferencovaného taxonu.
+
+Metadata Audiovisual Core mohou také popisovat zdroje, které nejsou tak často považovány za multimediální objekty. To zahrnuje:
+
+- Interaktivní softwarové aplikace, buď na webu, nebo dostupné
+ pro samostatné použití
+
+- Taxonomické identifikační klíče
+
+- Sbírky multimediálních zdrojů
+
+- Webové stránky, které nespadají do žádné z výše uvedených kategorií
+
+## 9 záznamy Audiovisual Core
+
+Normativní specifikace záznamů audiovizuálních základních metadat je nezávislá
+na způsobu, jakým jsou tyto záznamy převáděny do elektronické podoby.
+MRTG má v úmyslu zveřejnit specifikace pro takové zobrazení reprezentované
+v XML omezeném XML schématem a reprezentované v
+prostém textu jako hodnoty oddělené čárkami (CSV). [Části 4.4 až 4.5 specifikace dokumentace standardů TDWG](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) popisují, jak by měla být základní metadata termínů vyjádřena ve strojově čitelných formátech, jako jsou serializace RDF. Budoucí pracovní skupina by mohla vyvinout sémanticky bohatší strojově čitelnou ontologii podle postupů uvedených v [sekci 4 specifikace údržby slovníku TDWG](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+Jazykem normativní specifikace Audiovisual Core je angličtina, ale
+to nijak neomezuje aplikace v používání štítků nebo obsahu
+metadat v místních jazycích. Protože je jazykem normativního dokumentu angličtina, má každ
+metadatová položka v normativním dokumentu anglický název (který
+může být například součástí uživatelského rozhraní), ale ani tyto názvy
+nemusí být aplikacemi používány, ačkoli se jejich použití důrazně
+doporučuje, alespoň v dokumentaci.
+
+Jak již bylo zmíněno, záznam metadat Audiovisual Core je soubor termínů
+popisujících základní multimediální zdroj, který záznam popisuje.
+Každý termín je identifikován jednotným identifikátorem zdroje (URI). Jedná se o URI atributu, nikoli základního zdroje, a pouze specifikují, který termín je poskytován. Existuje mnoho schémat URI, z nichž některá byla zaregistrována u Internet Assigned Names Authority (IANA). Všechny URI Audiovisual Core termínů jsou v souladu se schématem http URI. Toto bylo zvoleno proto, že toto široce používané schéma URI používá jako syntaxi URI známou syntaxi internetových adres URL. Tato známost však vede k častému omylu, a to že vložení URI do adresního řádku prohlížeče nebo jeho zadání do jiné aplikace, která respektuje protokol http, by mělo vést k tomu, že aplikace vrátí nějaké informace o objektu identifikovaném URI. Takové chování se obvykle nazývá rozlišení (nebo, technicky řečeno, rozlišení a dereference) URI a není v žádném případě zaručeno pro URI termínů Audiovisual Core. Pokud je to možné, snažíme se, aby adresy URI protokolu HTTP byly rozlišitelné a aby vrácené informace obsahovaly dokumentaci o tom, jak je atribut metadat identifikovaný touto adresou URI definován nebo používán. Zopakuji: v případě URI Audiovisual Core termínů takové řešení nikdy nebude obsahovat informace o popsaném multimediálním zdroji. Z tohoto důvodu by jen málo Audiovisual Core aplikací zaměřených na člověka mělo uživatelům vůbec zobrazovat URI, ani je používat jako propojovací mechanismy. (Jednou z možných výjimek je aplikace pro přiřazování metadat k multimediálním zdrojům, kde takové použití může poskytnout heslo v tezauru, které uživateli pomůže v sémantice vlastnosti metadat. Nicméně, vzhledem k náhodné povaze tohoto řešení a jeho nedostatečné dlouhodobé udržitelnosti, je třeba i tento přístup zvažovat s velkou opatrností.) Na závěr je třeba poznamenat, že některé externí řízené slovníky jsou definovány v PDF nebo jiných dokumentech, které neobsahují přímé odkazy URL na jednotlivé definované termíny. V těchto případech může jakékoli usnesení dostupné z normativního dokumentu odkazovat pouze na začátek dokumentu, takže je nutné vyhledat v dokumentu odkazovanou definici.
+
+S každou vlastností Audiovisual Core je spojena její hodnota. Datový typ této hodnoty je rovněž specifikován v normativním dokumentu. Datové typy mohou zahrnovat volný text, konkrétní literály převzaté z kontrolovaného slovníku specifikovaného v normativním dokumentu nebo řadu dalších datových typů specifikovaných a popsaných v normativním dokumentu. V případě řízeného slovníku je důležité si uvědomit, že bez ohledu na to, co aplikace zobrazuje v uživatelském rozhraní, by při jakékoli výměně metadat Audiovisual Core měly být použity literály ze specifikovaného řízeného slovníku, pokud je specifikován, a to i v případě, že je záznam deklarován jako záznam v jiném jazyce než je jazyk řízeného termínu. Důležitým příkladem je pole metadat typu, které by mělo pocházet z odpovídajícího slovníku Dublin Core, doplněného o některá doporučení uvedená v normativním dokumentu. (K tomu přidáváme také volitelné pole Subtype.) Podobně agenti odpovídající na dotazy týkající se metadat Audiovisual Core MUSÍ být schopni zpracovávat a odpovídat na dotazy formulované pomocí kontrolovaného slovníku. Nic v normativním dokumentu nebrání poskytovateli dat Audiovisual Core tvrdit, že nemá žádné záznamy s daným řízeným termínem, ani provádět interní mapování mezi řízeným slovníkem a jeho interními atributy, jejichž názvy mohou být v jiném jazyce než v angličtině. Pouze malý počet vlastností Audiovisual Core má hodnoty v konkrétním, na angličtině založeném řízeném slovníku. To bude relevantní pouze pro výměnu metadat. Z povinných podmínek má takové požadavky pouze typ.
+
+Záznam Audiovisual Core se skládá minimálně ze čtyř povinných polí (identifikátor, typ, jazyk metadat a prohlášení o autorských právech).
+
+V některých případech jsou některé termíny metadat nutně spojeny s jinými (např. různé verze obrázku musí být spojeny s „hlavní“ verzí). Tabulky a jiné ploché zdroje metadat přispěvatelů jsou však považovány za obzvláště důležité a v mnoha z nich je obtížné takové strukturální vztahy znázornit. V důsledku toho je záznam Audiovisual Core sám o sobě převážně plochý, s výjimkou objektu vlastnosti s názvem _hasServiceAccessPoint_. Tento objekt sám o sobě má další vlastnosti, které popisují, jak načíst skutečná média popsaná záznamem AC. Jedním z důsledků toho je, že pro některé účely může být poskytovatel metadat nucen zpřístupnit několik záznamů metadat o stejném základním zdroji, protože specifikace Audiovisual Core, která je neutrální z hlediska reprezentace, ve většině případů neumožňuje „podvlastnosti“ svých vlastností ani vztahy. Důležitý případ se týká vícejazyčných metadat. Protože každý záznam metadat je v pevně daném jazyce specifikovaném vlastností Metadata Language (jedná se o jazyk záznamu, nikoli multimediálního zdroje, pokud nějaký má), může být nutné, aby poskytovatel nabídl několik záznamů metadat o stejném multimediálním zdroji. Hodnoty čtyř povinných termínů musí být uvedeny v každém záznamu metadat, i když se opakují v jiných záznamech metadat popisujících stejný zdroj.
+V době psaní tohoto článku normativní dokument neposkytuje mechanismus pro identifikaci záznamu metadat, který by mohl být zastřešující, v tom smyslu, že jeho volitelné termíny mohou být považovány za výchozí pro všechny termíny, které nejsou specifikovány v jiných záznamech o stejném zdroji. Tento bod je diskutován na MRTG Wiki.
+
+Mnohé položky se mohou v záznamu Audiovisual Core opakovat, ale některé nikoli, jak je uvedeno v normativním dokumentu. Například položka Modified odpovídá datu, kdy byl mediální zdroj upraven, a může se opakovat, aby odrážela historii zdroje. Naproti tomu datum dostupnosti je jedno datum nebo jeden rozsah dat, kdy se podkladový zdroj stal nebo stane dostupným.
+
+## 10 Implementace a soulad s předpisy
+
+Audiovisual Core je definován způsobem, který je co nejvíce neutrální z hlediska reprezentace. Poskytuje definice tříd, vlastností a instancí v přirozeném jazyce, které jsou identifikovány pomocí URI, a vydává doporučení ohledně použití a obsahu vlastností z jiných slovníků.
+
+Zde definované URI mohou být použity v řadě technologií, jako jsou prostory jmen v dokumentech XML Schema-valid table, RDF a záhlaví sloupců v textových souborech oddělených čárkami.
+
+Tento přístup usnadňuje:
+
+- Začlenění Audiovisual Core dat do jiných standardů, jako jsou popisy vzorků nebo literatura.
+
+- Rozšíření záznamů Audiovisual Core o další typy dat, jako jsou rozsáhlé geografické řízené slovníky Open Geospatial Consortium (OGC)
+
+- Křížové procházení mezi technologiemi, jako jsou soubory s hodnotami oddělenými čárkami, grafy RDF, dokumenty XML a objekty JSON.
+
+Samotný normativní standard Audiovisual Core, který je neutrální z hlediska reprezentace, neposkytuje hotový, samopotvrzující formát pro výměnu. Lze definovat více takových výměnných formátů splňujících různé požadavky a tato norma umožňuje jejich vzájemné mapování.
+
+## 11 Další informace
+
+- Charta skupiny pro údržbu Audiovisual Core
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Diskuse o Audiovisual Core probíhá na
+ https://github.com/tdwg/ac/issues
+
+- Zaregistrujte se do mailing listu tdwg-content@lists.tdwg.org na adrese http://lists.tdwg.org/mailman/listinfo/tdwg-content. Tato e-mailová konference sleduje veškerou diskusi o obsahu standardů TDWG.
+
+## 12 Příloha I: Slovníček pojmů
+
+
+
+
+ | DC |
+ Dublin Core. Sada metadatových prvků, která je standardem pro vyhledávání informačních zdrojů napříč doménami. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. Organizace zabývající se vývojem standardu metadat Dublin Core. |
+
+
+ | DwC |
+ Darwin Core je standard TDWG pro reprezentaci záznamů o vzorcích. Již několik let se široce používá v řadě nestandardních, někdy nekonzistentních verzí. Nedávno přijatá standardní verze je k dispozici na adrese http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Informace o mnoha druzích. |
+
+
+ | EXIF |
+ Široce používaný formát značek pro metadata digitálních obrázků, který je často vkládán do obrazových souborů, zejména moderními digitálními fotoaparáty. Mnoho aplikací pro vykreslování obrázků dokáže číst a zobrazovat data EXIF. Historie a popis viz http://en.wikipedia.org/wiki/Exchangeable_image_file_format. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperabilní síť databází biologické rozmanitosti a nástrojů informačních technologií. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifikuje formy a registruje instance názvů různých protokolů používaných na internetu. Viz zejména informace o schématu http URI IANA. |
+
+
+ | IPTC |
+ IPTC je vyspělý standard Mezinárodní rady pro tisk a telekomunikace. Jeho práva duševního vlastnictví podporují jemnější kontrolované slovníky než DC, což zajišťuje lepší strojové zpracování pro vyhledávání a vhodnost pro použití. Aktuální verze je slovník pro XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lehký formát pro výměnu dat. |
+
+
+ | Morphbank |
+ Úložiště obrázků vzorků. |
+
+
+ | MWG |
+ Pracovní skupina pro metadata je průmyslové konsorcium (Adobe, Apple, Canon, Microsoft, Nokia a Sony), které bylo založeno za účelem specifikace způsobu využití platformy Adobe Extensible Metadata Platform, XMP, pro vkládání metadat do běžných formátů obrazových souborů v několika široce používaných řízených slovnících. Ačkoli se MWG zaměřuje hlavně na spotřebitelské aplikace, více než dvě desítky open source a komerčních softwarových produktů a platforem podporují XMP a společnost Adobe uvolnila sadu nástrojů pro vývojáře pod open source licencí. |
+
+
+ | NBII |
+ Bývalá americká Národní infrastruktura biologických informací. Jeho obrazová knihovna, Library of Images From the Environment (LIFE), byla k dispozici na adrese http://images.nbii.gov/ nebo http://life.nbii.gov/. Pokud se LIFE obnoví v jakékoli formě, mohlo by tam být nějaké spojení. |
+
+
+ | NCD |
+ Popis přírodních sbírek je návrh datového standardu určený k popisu sbírek fyzických objektů, jako jsou například vzorky. Může pojmout sbírky mediálních objektů, ale nemůže je propojit s popisy samotných objektů. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Poskytuje standardy pro reprezentaci a výměnu geoprostorových dat. |
+
+
+ | RDF |
+ Resource Description Framework. Lehký ontologický systém na podporu online výměny znalostí. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Nyní známá jako Biodiversity Information Standards (TDWG), je to mezinárodní pracovní skupina, která vyvíjí standardy a protokoly pro sdílení dat o biologické rozmanitosti. |
+
+
+ | URI |
+ Unique Resource Identifier. Obecný termín pro propojení webových zdrojů včetně URL adres. |
+
+
+ | XML |
+ Extensible Markup Language. Jednoduchý flexibilní textový formát, který hraje stále důležitější roli při výměně široké škály dat na webu. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) je rámec pro vkládání metadat do mediálních souborů. Společnost Adobe poskytuje sadu nástrojů pro vývojáře XMP s licencí BSD, která obsahuje dokumentaci o tom, jak reprezentovat metadata v XMP. Specifikace XMP je licencována společností Adobe na základě "Public Patent License", kterou Adobe uděluje všem právo vytvářet komponenty svých aplikací kompatibilní s XMP, ale vyhrazuje si právo licenci odejmout v případě, že taková kompatibilní komponenta poruší "základní nároky" jakéhokoli patentu. Informace o stažení naleznete na http://www.adobe.com/devnet/xmp/. Viz také MWG v této tabulce. |
+
+
+
+
+## 13 Příloha II: Historie vývoje Audiovisual Core
+
+Standard Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) je vyvrcholením práce na popisech multimediálních zdrojů, kterou provedly organizace Key to Nature, NBII Digital Image Library, Morphbank a další, spolu s příspěvky řady dalších zainteresovaných komunit, včetně Encyclopedia of Life (EOL), Biodiversity Heritage Library (BHL) a University of Massachusetts-Boston. Globální informační systém o biologické rozmanitosti (GBIF) pověřil v březnu 2008 „Pracovní skupinu pro multimediální zdroje (MRTG)“ a v prosinci 2009 byla tato skupina schválena organizací Biodiversity Information Standards (TDWG) jako „Společná pracovní skupina GBIF-TDWG pro multimediální zdroje v oblasti biologické rozmanitosti“.
+
+Účastníci přípravy schématu (v abecedním pořadí)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+Tato norma byla vyvinuta společnou pracovní skupinou tak, aby odpovídala souboru standardizovaných zdrojů pro správu dat, které vyvíjí GBIF.
+
+Finanční prostředky poskytl Global Biodiversity Information Facility.
+
+Velký dík patří Woods Hole Marine Biological Laboratory a
+Encyclopedia of Life za uspořádání jednoho ze setkání. Tento dokument,
+včetně některých popisů, je upravenou verzí odpovídajícího dokumentu
+vypracovaného pracovní skupinou TDWG Natural Collections Descriptions (NCD).
+
+### 13.1 Časová osa
+
+2006, listopad Založena TDWG Image Interest Group
+
+2008, březen GBIF pověřuje pracovní skupinu pro multimediální zdroje (MRTG)
+
+2008, červen Pracovní skupina GBIF pro multimediální zdroje se sešla v Kodani, Dánsko
+
+2008, srpen Setkání pracovní skupiny GBIF pro multimediální zdroje ve Woods Hole, USA
+
+2008, říjen TDWG Image Interest Group se sešla ve Fremantle v Austrálii na ‘TDWG Annual Conference 2008’
+
+2008, prosinec Společná pracovní skupina GBIF-TDWG pro multimediální zdroje v oblasti biologické rozmanitosti pověřena
+
+2009, únor, se v dánské Kodani sešla pracovní skupina GBIF pro multimediální zdroje, aby zdokonalila schéma metadat
+
+2009, březen GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 vypracováno a otevřeno pro neformální připomínky, vyvíjející se přes verzi 0.9
+
+2010, únor Schéma v 0.9 předloženo TDWG k internímu hodnocení
+
+2010, červenec Dokončeno 1. interní hodnocení TDWG
+
+2010, listopad v1.0 předložena výkonnému výboru TDWG s odpovědí
+na 1. interní hodnocení. Navrhovaná norma přejmenována na Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, červen Probíhá reakce na 2. interní hodnocení.
+
+2011, září Dokončeny odpovědi na 2 a 3 interní hodnocení a předloženy výkonnému výboru TDWG.
+
+2011, listopad Připravené odpovědi na „Hodnocení g“ a „Hodnocení h“ a na některé připomínky vedoucího hodnocení, Stevea Baskaufa. Příprava podání žádosti o povolení k veřejnému připomínkování.
+
+Leden–listopad 2012 Další přípravy na podání žádosti o povolení k veřejnému připomínkování
+
+### 13.2 Historie revizí dokumentu
+
+**0.7v1**
+
+- Harmonizovaný dokument k tomu, že podtyp je v normativní verzi v0.7 volitelný
+
+- Oprava nesprávně umístěné závorky, nadbytečné mezery, chybějící mezery atd.
+
+**ACv1.0 docv1.0**
+
+- Harmonizováno s verzí 1.0: nahraďte „MRTG“ výrazem „Audiovisual Core“, pokud je použit jako název schématu. Opravy drobných překlepů. Přidána předpona „dcterms“.
+
+**ACv1.0 docv1.0**
+
+- Další nahrazení MRTG termínem „Audiovisual Core“ neboli „AC“.
+
+**AC v1.0 docv 1.2**
+
+- Adresovat komentáře 2. interního hodnocení
+
+- Oprava nesprávně umístěné závorky, nadbytečné mezery, chybějící mezery atd.
+
+**AC v1.0 docv1.3**
+
+- Odstranění požadavku na uvedení vlastníka autorských práv.
+
+**AC v1.0 docv1.4**
+
+- Vyčištění citací šesti povinných prvků namísto pěti.
+
+**AC v1.0 docv1.5**
+
+- Nahrazení „keytonature.eu“ za „species-id.net“, aby se zohlednilo přesunutí normativní wiki. Odebrání některých nepoužívaných termínů ze slovníku. Aktualizace docv na verzi 1.5
+
+**AC v1.0docv1.6**
+
+- Odebrání dcterms:title ze seznamu povinných položek. Přidání popisu je důrazně doporučeno. Přidání zmínky o xmpRights:Owner do položky Prohlášení o autorských právech v povinném seznamu. Změna počtu povinných prvků z „pěti“ na „čtyři“ nebo počet zcela vynechán, pokud je text jednoznačný. Uveden jmenný prostor acterms. Oprava jmenného prostoru Iptc4xmpExt na http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Aktualizace docv na verzi 1.6.
+
+**AC v1docv1.7**
+
+- Vyjasnění vztahu tohoto dokumentu k normativním dokumentům. Nastavení hlavního textu na zarovnání vlevo, nevyrovnané.
+
+**AC v1.0docv1.8**
+
+- Odstranění zmínky o přechodech, protože již nejsou v normativním seznamu termínů.
+
+- Na str. 5 vloženo URL termínů DwC do poznámky pod čarou.
+
+- Vylepšené formulace týkající se používání literálů s dcterms.
+
+**C v1.0docv1.91**
+
+- Různé drobné opravy gramatiky a interpunkce.
+
+- Sladění s aktuálními normativními dokumenty.
+
+**AC v1.0docv1.92**
+
+- Další drobné opravy gramatiky.
+
+**AC v1.0docv1.93**
+
+- Opraveny nekonzistentní odkazy na interní verzi aktuální verze. Žádné věcné ani gramatické změny. Na vědomí, že verze 1.92 byla předložena výkonnému výboru TDWG s žádostí o povolení k veřejné revizi.
+
+**AC v1.0docv1.94**
+
+- Změna odkazů z wiki species-id na wiki gbif terms. Upravení obr. 1
+
+**AC v1.0docv1.95**
+
+- Opraveno „hasAccentPoint“ na „hasAcccessPoint“. Odstranění textu naznačující, že se jedná o návrh
+
+## 14 Poznámky
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+Pracovní skupina pro metadata (MWG, [http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) je průmyslové konsorcium (Adobe, Apple, Canon, Microsoft, Nokia a Sony) založené za účelem specifikace způsobu využití platformy Adobe Extensible Metadata Platform, XMP ([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) pro vkládání metadat do běžných formátů obrazových souborů v několika široce používaných řízených slovnících. Ačkoli se MWG zaměřuje hlavně na
+spotřebitelské aplikace, více než dvě desítky open source a komerčních
+softwarových produktů a platforem podporují XMP a Adobe umístilo
+Developers' Toolkit pod open source licenci. Spolu s
+návrhy na standardní serializace reprezentace neutrálního
+schématu Audiovisual Core hodlá MRTG navrhnout TDWG Best Practice
+pro vkládání takových serializací do multimediálních souborů pomocí XMP.
+
+[\[10\]](#cit-10)
+IPTC je vyspělý standard Mezinárodní rady pro tisk a telekomunikace
+([http://www.iptc.org](http://www.iptc.org)). Jeho práva duševního vlastnictví podporují jemnější řízené slovníky než
+DC, což poskytuje lepší strojové zpracování pro vyhledávání a
+vhodnost pro použití.
diff --git a/docs/cs/index.md b/docs/cs/index.md
index 76049a18..f7f90b30 100644
--- a/docs/cs/index.md
+++ b/docs/cs/index.md
@@ -4,12 +4,12 @@ layout: home
# Audiovisual Core
-Audiovisual Core is a TDWG standard maintained by the Audiovisual Core Maintenance Interest Group. It includes a main vocabulary and several controlled vocabularies, as well as several guides that explain how the vocabularies should be used. The purpose of Audiovisual Core is to represent metadata for biodiversity multimedia resources and collections, and to make it possible for users to determine whether those resources would be fit for some biodiversity science application before acquiring the media.
+Audiovisual Core je standard TDWG spravovaný skupinou Audiovisual Core Maintenance Interest Group. Zahrnuje hlavní slovník a několik řízených slovníků, stejně jako několik příruček, které vysvětlují, jak by se slovníky měly používat. Účelem Audiovisual Core je reprezentovat metadata pro multimediální zdroje a sbírky týkající se biologické rozmanitosti a umožnit uživatelům před pořízením médií určit, zda jsou tyto zdroje vhodné pro některé aplikace v oblasti vědy o biologické rozmanitosti.
## Začínáme
-- [Introduction to Audiovisual Core](introduction/)
-- [Term list](termlist/): list of all terms included in the main Audiovisual Core vocabulary
-- Usage guides: [detailed guide to aims and uses](guide/) and [guide for structuring records](structure/)
-- Examples: work-in-progress pages to document how Audiovisual Core is used "in the wild" for [still images](https://github.com/tdwg/ac/blob/master/image/examples.md). Pages for sound and video to come...
-- [GitHub repository](https://github.com/tdwg/ac): where Audiovisual Core is maintained. It includes detailed records of the development of the standard and information about the day-to-day operations of the Maintenance Group. This is the place to go if you want to become involved in improving Audiovisual Core.
+- [Úvod do Audiovisual Core](introduction/)
+- [Seznam termínů](termlist/): seznam všech termínů obsažených v hlavním slovníku Audiovisual Core
+- Návody k použití: [podrobný návod k cílům a použití](guide/) a [návod ke strukturování záznamů](structure/)
+- Příklady: stránky ve vývoji, které dokumentují, jak se Audiovisual Core používá „v praxi“ pro [statické obrázky](https://github.com/tdwg/ac/blob/master/image/examples.md). Stránky pro zvuk a video budou brzy k dispozici...
+- [repozitář GitHub](https://github.com/tdwg/ac): kde je udržován Audiovisual Core. Obsahuje podrobné záznamy o vývoji normy a informace o každodenní činnosti skupiny pro údržbu. Toto je místo, kam se můžete obrátit, pokud se chcete zapojit do vylepšování Audiovisual Core.
diff --git a/docs/cs/introduction/index.md b/docs/cs/introduction/index.md
index 0e3fc319..abff437b 100644
--- a/docs/cs/introduction/index.md
+++ b/docs/cs/introduction/index.md
@@ -1,161 +1,158 @@
-# Audiovisual Core Introduction
+# Úvod do Audiovisual Core
-Title
-: Audiovisual Core Introduction
+Název
+: Úvod do Audiovisual Core
-Date version issued
+Datum vydání verze
: 2023-02-24
-Date created
+Datum vytvoření
: 2013-10-23
-Part of TDWG Standard
+Součást TDWG Standardu
:
-This version
+Tato verze
:
-Latest version
+Poslední verze
:
-Previous version
+Předchozí verze
:
-Abstract
-: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. These vocabularies aim to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them.
+Abstrakt
+: Audiovisual Core je soubor slovníků určených k reprezentaci metadat pro multimediální zdroje a sbírky týkající se biologické rozmanitosti. Cílem těchto slovníků je poskytnout informace, které pomohou před pořízením médií určit, zda je konkrétní zdroj nebo sbírka vhodná pro určitou aplikaci v oblasti vědy o biologické rozmanitosti. Slovníky se mimo jiné zabývají otázkami, jako je správa médií a sbírek, popisy jejich obsahu, jejich taxonomické, geografické a časové pokrytí a vhodné způsoby jejich vyhledávání, přiřazování a reprodukce.
-Contributors
+Přispěvatelé
: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
-Creator
-: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+Tvůrce
+: GBIF/TDWG Pracovní skupina pro multimediální zdroje a Skupina pro údržbu audiovizuálního jádra
-Bibliographic citation
-: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Introduction. Biodiversity Information Standards (TDWG).
+Bibliografická citace
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Úvod do Audiovisual Core. Biodiversity Information Standards (TDWG).
## 1. Úvod
-There are four documents included in the Aububon Core Standard. This document
-provides a general introduction to the Audiovisual Core Standard. For information
-about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
-document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
-For a more detailed guide to the use of Audiovisual Core, see the
-[Audiovisual Core Guide](../guide/) document.
+Audiovisual Core Standard obsahuje čtyři dokumenty. Tento dokument
+poskytuje obecný úvod do standardu Audiovisual Core. Informace
+o struktuře Audiovisual Core naleznete v dokumentu [Audiovisual Core Structure](../structure/). Podrobnosti o termínech naleznete v dokumentu [Audiovisual Core Terms List](../termlist/).
+Podrobnější návod k používání Audiovisual Core naleznete v dokumentu
+[Audiovisual Core Guide](../guide/).
### 1.1 Status obsahu tohoto dokumentu
-All sections of this document are non-normative.
-
-### 1.2 The scope of Audiovisual Core
-
-The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
-simply “AC”) is a set of metadata vocabularies for describing
-biodiversity-related multimedia resources and collections. The
-specification is independent of how these vocabularies may be
-represented for machine use.
-
-Multimedia Resources are digital or physical artifacts which normally
-comprise more than text. These include pictures, artwork, drawings,
-photographs, sound, video, animations, presentation materials, and
-interactive online media including, e.g., identification tools. A
-multimedia collection is an assemblage of such objects, whether curated
-or not, and whether electronically accessible or not. For the purposes
-of this document we regard a collection of multimedia resources itself
-as a ‘multimedia resource’. Wherever discussion or specification can
-apply only to a collection or only to a single media resource, we say so
-explicitly.
-
-Multimedia descriptions are digital records that document underlying
-multimedia resources or collections. AC is focused on
-biodiversity-related multimedia resources. It shares terminology and
-concerns with many well-known and important standards for describing
-access to resources such as Dublin Core (DC), Darwin Core (DwC), the
-Adobe Extensible Metadata Platform (XMP), the International Press and
-Telecommunications Council (IPTC), the Metadata Working Group (MWG)
-schema, the Natural Collections Schema (NCD), and others. Where there is
-an exact match to the usage of such standards, AC adopts their
-identifiers and definitions. Many collections of biodiversity multimedia
-already have descriptions of their media expressed in DwC or DC. By
-using those vocabularies where suitable, AC particularly intends to make
-it easy for such collections to reuse their existing descriptions,
-augmented where necessary by other
-terms
-
-**See also:** Discovery and Publishing of Primary Biodiversity Data
-associated with Multimedia Resources: The Audiovisual Core Strategies and
-Approaches. R.
-Morris et al., _Biodiversity Informatics,_ 8, jul. 2013.
-
-## 2 Audiovisual Core terms
-
-An Audiovisual Core record is a description of a multimedia resource using
-the [Audiovisual Core terms](./terms). Two kinds
-of terms are specified by AC: record-level terms and access-level terms.
-Record-level terms apply to the media resource being described. Almost
-all terms are record-level terms. One such term, _hasServiceAccessPoint_
-plays a special role in helping to retrieve the resource that the record
-describes. A multimedia resource may have more than one
-hasServiceAccessPoint, each of which provides values of one or more
-access-level terms. The access-level terms document such things as a web
-address at which a digital representation of the resource can be
-retrieved, the size of such a retrieved object, etc. An Audiovisual Core
-record is thus a description using a set of terms that conforms to the
-normative documents, and contains at least the four mandatory terms,
-which provide an identifier, a resource type, the language of the
-description, and copyright information. Every such record describes a
-single multimedia resource (possibly including a Collection). The
-identifier may have been assigned to the resource by an external
-authority or by the provider of the record. Strictly speaking, the
-identifier is required only for Collections, but is strongly recommended
-in general.
-
-Every Audiovisual Core term has a plain text Name, a term identifier and a
-plain text normative Definition. Term identifiers conform to the
-Universal Resource Identifier (URI)
-specification.
-Typically these identifiers have a form familiar to browser users as the
-addresses of web pages, beginning with "http://". Informally, one may
-understand this thusly: an http URI has the syntax of a web address, but
-there is no expectation that putting it in a web browser will result in
-any information being returned to the browser, and if it does, the
-return may have no relevance.
-
-Because http URIs are rather lengthy, AC documents follow a standard
-practice of introducing a short prefix comprising a "namespace
-qualifier" separated by a colon from a mnemonic name closely related to
-the term's Name. The namespace of the roughly 50% of the terms that are
-borrowed from other vocabularies is the namespace of the original. The
-namespace of de novo AC terms is http://rs.tdwg.org/ac/terms/. In the [Audiovisual Core Term List](../termlist/), each
-term entry has a row with the term name. Following the practice of the
-[Darwin Core terms](http://rs.tdwg.org/dwc/terms/), this term name
-is generally an "unqualified name" preceded by a widely accepted prefix
-designating an abbreviation for the namespace. The result is known as a
-qualified name. For example the normative wiki documentation for the
-borrowed term dcterms:identifier has URI
-http://purl.org/dc/terms/identifier. The first part,
-"http://purl.org/dc/terms/" corresponds to the namespace. Most of the
-URIs for terms borrowed from external vocabularies do in fact produce
-relevant documentation for that external standard when used as a web
-page URL. Sometimes it is not precise because the documentation is a PDF
-document and several (different!) URIs might apparently lead
-to the same place.
-
-## 3 Implementations
-
-The [AC Term List](../termlist/) and
+Všechny části tohoto dokumentu jsou nenormativní.
+
+### 1.2 Rozsah Audiovisual Core
+
+Audiovisual Core Multimedia Resources Metadata schema („schéma AC“ nebo
+jednoduše „AC“) je soubor slovníků metadat pro popis
+multimediálních zdrojů a sbírek souvisejících s biologickou rozmanitostí. Specifikace
+je nezávislá na tom, jak mohou být tyto slovníky
+zobrazeny pro strojové využití.
+
+Multimediální zdroje jsou digitální nebo fyzické artefakty, které obvykle
+obsahují více než jen text. Mezi ně patří obrázky, umělecká díla, kresby,
+fotografie, zvukové záznamy, videa, animace, prezentační materiály a
+interaktivní online média, včetně např. identifikačních nástrojů. Multimediální
+sbírka je souborem takovýchto objektů, ať už kurátorských
+či nikoli, a ať už elektronicky přístupných či nikoli. Pro účely
+tohoto dokumentu považujeme soubor multimediálních zdrojů sám o sobě
+za ‘multimediální zdroj’. Kdykoli se diskuse nebo specifikace může
+vztahovat pouze na sbírku nebo pouze na jeden mediální zdroj, výslovně to uvádíme.
+
+Multimediální popisy jsou digitální záznamy, které dokumentují základní
+multimediální zdroje nebo sbírky. AC se zaměřuje na
+multimediální zdroje související s biologickou rozmanitostí. Sdílí terminologii a
+zájmy s mnoha známými a důležitými standardy pro popis
+přístupu k zdrojům, jako jsou Dublin Core (DC), Darwin Core (DwC),
+Adobe Extensible Metadata Platform (XMP), International Press and
+Telecommunications Council (IPTC), Metadata Working Group (MWG)
+schema, Natural Collections Schema (NCD) a další. V případě
+přesné shody s použitím těchto standardů přijímá AC jejich
+identifikátory a definice. Mnohé sbírky multimédií o biologické rozmanitosti
+již obsahují popisy svých médií vyjádřené v DwC nebo DC. Používáním
+těchto slovníků tam, kde je to vhodné, chce AC zejména usnadnit
+opětovné použití stávajících popisů v těchto sbírkách,
+v případě potřeby doplněných o další
+termíny
+
+**Viz také:** Objevování a publikování primárních dat o biologické rozmanitosti
+spojených s multimediálními zdroji: Audiovizuální základní strategie a
+přístupy. R.
+Morris et al., _Biodiversity Informatics,_ 8, červenec. 2013.
+
+## 2 Základní pojmy Audiovisual Core
+
+Záznam Audiovisual Core je popis multimediálního zdroje pomocí
+[termínů Audiovisual Core](./terms). AC specifikuje dva druhy
+termínů: termíny na úrovni záznamů a termíny na úrovni přístupu.
+Termíny na úrovni záznamu se vztahují na popisovaný mediální zdroj. Téměř
+všechny termíny jsou termíny na úrovni záznamu. Jeden z těchto termínů, _hasServiceAccessPoint_,
+hraje zvláštní roli při získávání zdroje, který záznam
+popisuje. Multimediální zdroj může mít více než jeden
+hasServiceAccessPoint, z nichž každý poskytuje hodnoty jednoho nebo více
+termínů přístupové úrovně. Podmínky přístupu dokumentují takové věci, jako je webová
+adresa, na které lze získat digitální reprezentaci zdroje,
+velikost takového získaného objektu atd. Záznam Audiovisual Core
+je tedy popis používající sadu termínů, která odpovídá
+normativním dokumentům a obsahuje alespoň čtyři povinné termíny,
+které poskytují identifikátor, typ zdroje, jazyk
+popisu a informace o autorských právech. Každý takový záznam popisuje
+jediný multimediální zdroj (případně včetně sbírky). Identifikátor
+mohl být zdroji přidělen externím
+orgánem nebo poskytovatelem záznamu. Přísně vzato je
+identifikátor vyžadován pouze pro sbírky, ale obecně se jeho použití důrazně doporučuje.
+
+Každý termín Audiovisual Core má název v prostém textu, identifikátor termínu a
+normativní definici v prostém textu. Identifikátory termínů odpovídají
+specifikaci
+[Universal Resource Identifier (URI)](http://tools.ietf.org/html/rfc2616#section-3.2).
+Tyto identifikátory mají obvykle podobu, která je uživatelům prohlížečů známá jako
+adresy webových stránek, začínající „http://“. Neformálně lze
+toto pochopit takto: http URI má syntaxi webové adresy, ale
+nelze očekávat, že jeho zadání do webového prohlížeče povede k
+vrácení jakýchkoli informací do prohlížeče, a pokud ano,
+vrácené informace nemusí mít žádný význam.
+
+Protože adresy URL jsou poměrně dlouhé, dokumenty AC se řídí standardní
+praxí zavádění krátké předpony sestávající z „kvalifikátoru jmenného prostoru“
+odděleného dvojtečkou od mnemotechnického názvu úzce souvisejícího s
+názvem termínu. Jmenný prostor s přibližně 50 % termínů, které jsou
+převzaty z jiných slovníků, je jmenný prostor originálu. Jmenný prostor
+termínů de novo AC je http://rs.tdwg.org/ac/terms/. V [Audiovisual Core Term List](../termlist/) má každý
+záznam termínu řádek s názvem termínu. V souladu s praxí
+[Darwin Core terms](http://rs.tdwg.org/dwc/terms/) je tento termín
+obecně „nekvalifikovaným názvem“, před kterým je široce přijímaná předpona
+označující zkratku pro jmenný prostor. Výsledek se nazývá
+kvalifikovaný název. Například normativní wiki dokumentace pro
+vypůjčený termín dcterms:identifier má URI
+http://purl.org/dc/terms/identifier. První část,
+"http://purl.org/dc/terms/", odpovídá jmennému prostoru. Většina
+URI pro termíny převzaté z externích slovníků ve skutečnosti vytváří
+relevantní dokumentaci pro daný externí standard, pokud jsou použity jako
+URL webové stránky. Někdy to není přesné, protože dokumentace je ve formátu PDF
+a několik (různých!) URI mohou zjevně vést
+na stejné místo.
+
+## 3 Implementace
+
+Dokumenty [AC Term List](../termlist/) a
[Audiovisual Core Structure](../structure/)
-documents represent a _data model._ For actual use of Audiovisual Core, it
-is necessary to select an implementation, preferably one with some
-status designated by [TDWG](http://www.tdwg.org/). Known
-implementations will be listed in ancillary documents not included as part of the Audiovisual Core standard.
-
-## 4 References
-
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+představují _datový model._ Pro skutečné použití Audiovisual Core je
+nutné vybrat implementaci, nejlépe takovou, která má nějaký
+status určený [TDWG](http://www.tdwg.org/). Známé
+implementace budou uvedeny v doplňkových dokumentech, které nejsou součástí standardu Audiovisual Core.
+
+## 4 Odkazy
+
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | Sledování problémů AC |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | Zásady změn slovníku TDWG |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Uživatelská příručka Dublin Core |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | Uživatelská příručka AC |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Úvod do struktury AC |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | Seznam termínů AC |
diff --git a/docs/cs/structure/index.md b/docs/cs/structure/index.md
new file mode 100644
index 00000000..30ed5ade
--- /dev/null
+++ b/docs/cs/structure/index.md
@@ -0,0 +1,282 @@
+# Struktura Audiovisual Core
+
+Název
+: Struktura Audiovisual Core
+
+Datum vydání verze
+: 2023-02-24
+
+Datum vytvoření
+: 2013-10-23
+
+Součást TDWG Standardu
+:
+
+Tato verze
+:
+
+Poslední verze
+:
+
+Předchozí verze
+:
+
+Abstrakt
+: Dokument Audiovisual Core Structure poskytuje pokyny, jak lze multimediální záznamy serializovat jako XML a v tabulkové formě. Navrhuje také, jak lze hodnoty textového seznamu oddělit.
+
+Přispěvatelé
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Tvůrce
+: GBIF/TDWG Pracovní skupina pro multimediální zdroje a Skupina pro údržbu audiovizuálního jádra
+
+Bibliografická citace
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Struktura Audiovisual Core. Biodiversity Information Standards (TDWG).
+
+## 1. Úvod
+
+Tato dokumentace popisuje strukturu standardu [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, nebo
+jednoduše AC).
+
+**Pokud nejste obeznámeni s Audiovisual Core, _prosím_ přečtěte si [Úvod do Audiovisual Core](../introduction) předtím, než začnete číst tento dokument.** Úvod vysvětluje, proč je vnímána potřeba metadatového schématu pro mediální zdroje týkající se biologické rozmanitosti a jak se standard snaží využívat stávající standardy metadat, kde je to možné.
+
+Podrobnosti o termínech naleznete v dokumentu [Seznam základních termínů audiovizuální oblasti](../termlist) a podrobnějšího průvodce používáním základních termínů audiovizuální oblasti naleznete v dokumentu [Průvodce základními termíny audiovizuální oblasti](../guide).
+
+Během vývoje bylo audiovizuální jádro neformálně známé jako MRTG, podle jeho vývojářů, společné pracovní skupiny GBIF-TDWG Joint Multimedia Resources Metadata Task Group. Podrobný popis historie vývoje naleznete v [Průvodci audiovizuálním jádrem](../guide) a také v [Historii vývoje MRTG](http://www.keytonature.eu/wiki/MRTG_Development_History).
+
+### 1.1 Status obsahu tohoto dokumentu
+
+Části 2 až 4 tohoto dokumentu jsou normativní, s výjimkou příkladových částí, které jsou označeny jako nenormativní.
+
+### 1.2 Klíčová slova RFC 2119
+
+Klíčová slova "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" a "OPTIONAL" v tomto dokumentu je třeba interpretovat podle popisu v [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminologie této specifikace
+
+Existuje mnoho způsobů, jak organizovat specifikace metadat, zejména pokud jde o
+názvosloví složek metadat. Vezměte na vědomí
+následující informace, které se vztahují k Audiovisual Core:
+
+- _Multimediální zdroj_ je cokoli, co poskytovatel identifikuje jako
+ patřící k jedné z možných hodnot termínu AC _Type_ a
+ volitelně k jedné nebo více hodnotám termínu _Subtype_. Je k dispozici mechanismus, pomocí kterého mohou poskytovatelé dodávat soukromě definovaný podtyp, který nebude kolidovat s hodnotami podtypu definovanými AC.
+- AC _záznam_ je soubor termínů s libovolnými hodnotami, které jsou v souladu s tímto dokumentem a které obsahují alespoň čtyři povinné termíny popsané v [Audiovisual Core Core Term List](../termlist) a které popisují jeden multimediální zdroj (případně včetně sbírky). Jednou z nich je hodnota _Identifier_, což je globálně jedinečný identifikátor (GUID), který může být přiřazen zdroji externí autoritou nebo poskytovatelem záznamu metadat.
+
+V [seznamu termínů Audiovisual Core](../termlist) má každý termín AC _název termínu_ následující po položce tabulky _„Termín:“_, _URI_, normativní _definici_ v prostém textu, doporučený anglický _název_ a volitelný atribut _poznámky_. Kromě toho má termín atribut, který udává, zda je povinný, a atribut, který udává, zda je opakovatelný.
+
+Metadata AC mohou popisovat buď jednotlivé multimediální zdroje, nebo sbírky zdrojů. Některé, ale ne všechny, vlastnosti AC mají pro sbírky jiné hodnoty než pro jednotlivá média. Pokud není takové rozlišení uvedeno, AC ho nepředpokládá.
+
+Názvy termínů převzatých z jiných slovníků jsou ty, které se používají pro odpovídající termín v těchto slovnících. Názvy termínů jsou určeny především pro orientaci v dokumentaci AC. Štítky Term Labels jsou návrhy anglických označení v aplikacích. Jedná se pouze o doporučení, která jsou k dispozici pouze v angličtině, s tím, že by měla objasnit zamýšlené použití daného termínu.
+Komunity mohou chtít vydat doporučení pro štítky v jiných jazycích nebo dokonce alternativní anglické štítky pro specializované publikum, např. školní děti. Štítky MOHOU být použity pro navigaci v rámci seznamu termínů a často se používají v samotném seznamu termínů, když je termín zmíněn v dokumentaci jiného termínu. Seznam termínů poskytuje rejstříky podle názvu i označení.
+
+URI pro termíny odpovídají schématu http URI (viz http://en.wikipedia.org/wiki/URI_scheme, http://www.w3.org/TR/uri-clarification nebo http://www.ietf.org/rfc/rfc2396.txt). Neformálně lze toto pochopit následovně: http URI má syntaxi http URL, ale nelze očekávat, že jeho zadání do webového prohlížeče povede k vrácení jakýchkoli informací do prohlížeče, a pokud ano, nemusí to mít žádný význam. Tento požadavek na shodu se vztahuje pouze na URI, které identifikují termíny AC. Několik termínů AC umožňuje převzít **hodnoty** z jiného řízeného slovníku vybraného uživatelem. V tomto případě mohou tyto hodnoty zahrnovat URI odpovídající schématu danému tímto externím slovníkem a AC se k tomu, co je tím schématem, nevyjadřuje.
+
+Pole Poznámky v dokumentaci k termínu odkazuje na další informace o termínu, pokud existují. Zejména u termínů převzatých z
+jiných slovníků obsahuje toto pole obvykle odkaz na
+dokumentaci původního slovníku pro daný
+termín.
+
+## 3 Multiplicita a kardinalita
+
+Řada termínů se opakuje. Způsob implementace opakovatelnosti v
+dané serializaci není definován Audiovisual Core. Následující
+část obsahuje rady ohledně osvědčených postupů v kontextu
+opakovatelnosti.
+
+Nejjednodušším případem je jediný opakovatelný termín (např.
+dcterms:identifier). V reprezentacích založených na schématu XML, které
+umožňuje opakování prvků, lze takový termín jednoduše opakovat (např.
+"`...http://example.com/123http://example.com...`").
+V serializacích, které se nehodí pro opakovatelné
+prvky (např. „plochá“ schémata, kde se všechny prvky vyskytují pouze jednou
+v jinak nestrukturovaném záznamu), je možné definovat
+oddělovače pro podporu seznamu hodnot v rámci jednoho prvku (např.
+„...http://example.com/123;
+http://example.com/456...\`").
+
+V některých případech se páry nebo dvojice vlastností opakují. V Audiovisual
+Core k této situaci dochází například v následujících případech:
+
+- Metadata závislá na jazyku, jako je název, popis atd., musí
+ být spojena s `ac:metadataLanguage`. Jedním z přístupů je
+ použít kompletní záznamy Audiovisual Core společně s vlastností [Metadata Language](../termlist#ac_metadataLanguage); další podrobnosti naleznete tam.
+- Hodnoty vlastností týkající se přístupového bodu služby MUSÍ zůstat
+ spojeny s tímto přístupovým bodem služby, i když existuje více
+ přístupových bodů služby. Viz
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ pro další podrobnosti.
+- Termíny `dwc:scientificName` a `dwc:identificationQualifier` MOHOU
+ být volitelně strukturovány do párů. (Viz poznámky k
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- Termíny [Recenzent](../termlist#ac_reviewer), což je jméno osoby poskytující odbornou recenzi zdroje, a samotný text recenze v [Komentáře recenzenta](../termlist#ac_reviewerComments) je vhodné ukládat jako páry.
+
+### 3.1 Strukturované serializace
+
+Mnoho serializačních jazyků poskytuje dostatečně strukturované formy, aby
+jednoznačně zpracovaly opakující se termíny. V XML můžeme definovat
+kontejnerový prvek a použít vnořenou strukturu, jak je uvedeno v oddíle 3.1.1. Alternativně můžeme v XML odkazovat na přístupové body pomocí identifikátoru, jak je uvedeno v oddíle 3.1.2. Pokud takové struktury nejsou možné nebo nejsou žádoucí, alternativním
+řešením je povolit pouze jeden přístupový bod na
+kontejnerový prvek, ale opakovat kontejnerový prvek pro jeden mediální zdroj, jak je uvedeno v části 3.1.3. To je podobné
+jedné z možností diskutovaných pro vícejazyčná metadata (viz [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Poznámka: V příkladech byly pro lepší srozumitelnost použity doslovné výrazy „dc:format“ a „ac:variantLiteral“. Za nejlepší postup se však považuje použití termínů s hodnotou IRI „dcterms:format“ a „ac:variant“ s kontrolovanými hodnotami IRI z [kontrolovaného slovníku pro formát](http://rs.tdwg.org/ac/doc/format/) a [kontrolovaného slovníku pro variantu](http://rs.tdwg.org/ac/doc/variant/). Další informace naleznete v poznámkách k [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) a [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral).
+
+#### 3.1.1 Příklad vnořené struktury XML (nenormativní)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 Příklad odkazu XML podle identifikátoru (nenormativní)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Příklad opakovaného prvku kontejneru XML (nenormativní)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ List červeného buku
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabulkové serializace
+
+Stejná data jako v příkladech 3.1.1 až 3.1.3 lze serializovat jako „plochou“ tabulku podobnou tabulce v tabulkovém procesoru.
+
+V příkladu v oddíle 3.2.1 se opakuje pouze požadovaný identifikátor, nikoli však
+pole názvu. Zda se mají opakovat všechna pole, nebo zda se mají poskytnout všechna
+pole pouze v prvním záznamu, přičemž pozdější záznamy se omezí na
+identifikátor a vlastnosti přístupového bodu služby, je ponecháno na konkrétních
+implementacích. V příkladu v části 3.2.1 je vlastnost `ac:hasServiceAccessPoint` potlačena
+jako zbytečná.
+
+#### 3.2.1 Příklad tabulky, ve které je každý přístupový bod služby uveden v samostatném řádku (nenormativní)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ List červeného buku |
+ Nejvyšší kvalita |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Nejvyšší kvalita |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Náhled |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Další přístup (sekce 3.2.2) také eliminuje potřebu vlastnosti `ac:hasServiceAccessPoint` při
+zploštění struktury ac. Je založeno na zavedení nových termínů
+využívajících hodnoty [ac:variantLiteral](../termlist#ac_variantLiteral):
+„Thumbnail“, „Trailer“, „Lower Quality“, „Medium Quality“, „Good
+Quality“, „Best Quality“, „Offline“ jako předpony pro další
+vlastnosti v novém jmenném prostoru.
+
+#### 3.2.2 Příklad tabulky s metadaty pro všechny přístupové body služby ve stejném řádku (nenormativní)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ List červeného buku |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Poznámka: `acf:` (zkratka pro „Audiovisual Core Flat“) je vymyšlený jmenný prostor. Zájmové komunity mohou takové termíny vytvářet, aby mohly využívat tento druh struktury.
+
+## 4 Seznamy hodnot v prostém textu
+
+Některé termíny AC povolují hodnoty, které jsou seznamy, aby byly reprezentovány jako prostý
+text. Volba způsobu oddělení položek seznamu je nakonec ponechána na
+implementátorech AC. Typickým použitím je volba interpunkčního znaménka, jako je
+„,“, „;“ nebo „|“. V těchto případech je třeba definovat speciální únikovou syntaxi
+pro případy, kdy je oddělovač součástí hodnoty metadat.
+Bohužel i u standardních formátů seznamů, jako je CSV, používají různé
+softwarové balíčky různé metody únikových znaků, což brání
+výměně dat. V případě, že neexistuje možnost volby specifická pro danou implementaci,
+DOPORUČUJEME použít jako oddělovač znak "|" a jako escapovaný svislý pruh znak "\\|".
diff --git a/docs/de/guide/index.md b/docs/de/guide/index.md
new file mode 100644
index 00000000..93b189ca
--- /dev/null
+++ b/docs/de/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Status of the content of this document
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Label |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Label |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/de/introduction/index.md b/docs/de/introduction/index.md
index fbace2b6..9175b943 100644
--- a/docs/de/introduction/index.md
+++ b/docs/de/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 Introduction
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/de/structure/index.md b/docs/de/structure/index.md
new file mode 100644
index 00000000..95eb7c14
--- /dev/null
+++ b/docs/de/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Status of the content of this document
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 key words
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/es/guide/index.md b/docs/es/guide/index.md
new file mode 100644
index 00000000..9745b83b
--- /dev/null
+++ b/docs/es/guide/index.md
@@ -0,0 +1,898 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Fecha de publicación de la versión
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Parte del Estándar TDWG
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Resumen:
+El Audiovisual Core es un conjunto de vocabularios diseñados para representar metadatos de recursos y colecciones multimedia sobre biodiversidad. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creador
+: Grupo de Trabajo de Recursos Multimedia y Grupo de Mantenimiento del Audiovisual Core de GBIF/TDWG
+
+Citación bibliográfica
+: Grupo de Trabajo de Recursos Multimedia y Grupo de Mantenimiento del Audiovisual Core de GBIF/TDWG. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introducción
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Estado del contenido de este documento
+
+Todas las secciones de este documento no son normativas.
+
+## 2 Summary
+
+El esquema de metadatos de recursos multimedia del Audiovisual Core ("esquema AC" o simplemente "AC") es un conjunto de vocabularios de metadatos para describir recursos y colecciones multimedia relacionados con la biodiversidad. La especificación es independiente de cómo se puedan representar estos vocabularios para su uso por máquinas.
+
+Los recursos multimedia son artefactos digitales o físicos que normalmente comprenden más que texto. Estos incluyen imágenes, obras de arte, dibujos, fotografías, sonido, videos, animaciones, materiales de presentación y medios interactivos en línea, incluidas, por ejemplo, herramientas de identificación. Una colección multimedia es un conjunto de dichos objetos, ya sean curados o no, y accesibles electrónicamente o no. A los efectos de este documento, consideramos que una colección de recursos multimedia en sí misma es un «recurso multimedia». Siempre que una discusión o especificación pueda aplicarse únicamente a una colección o a un único recurso multimedia, lo decimos explícitamente.
+
+Las descripciones multimedia son registros digitales que documentan recursos o colecciones multimedia subyacentes. AC se enfoca en recursos multimedia relacionados con la biodiversidad. Comparte terminología y asuntos con muchos estándares conocidos e importantes para describir el acceso a recursos, como Dublin Core (DC), Darwin Core (DwC), Adobe Extensible Metadata Platform (XMP), el Consejo Internacional de Prensa y Telecomunicaciones (IPTC), el esquema del Grupo de Trabajo de Metadatos (MWG), el Esquema de Colecciones Naturales (NCD) y otros. Cuando existe una coincidencia exacta con el uso de dichos estándares, AC adopta sus identificadores y definiciones. Muchas colecciones de multimedia sobre biodiversidad ya cuentan con descripciones de sus medios expresadas en DwC o DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Debido a que las URL http son bastante largas, los documentos AC siguen la práctica estándar de introducir un prefijo corto que comprende un "calificador de espacio de nombres" separado por dos puntos de un nombre mnemónico estrechamente relacionado con el nombre del término. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. En la tabla de términos, cada entrada de término tiene una fila con el nombre del término. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Etiqueta |
+ Tipo |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ La naturaleza o género del recurso. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Etiqueta |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/es/index.md b/docs/es/index.md
index 9e839a81..3daa8b50 100644
--- a/docs/es/index.md
+++ b/docs/es/index.md
@@ -4,12 +4,12 @@ layout: home
# Audiovisual Core
-Audiovisual Core is a TDWG standard maintained by the Audiovisual Core Maintenance Interest Group. It includes a main vocabulary and several controlled vocabularies, as well as several guides that explain how the vocabularies should be used. The purpose of Audiovisual Core is to represent metadata for biodiversity multimedia resources and collections, and to make it possible for users to determine whether those resources would be fit for some biodiversity science application before acquiring the media.
+Audiovisual Core es un estándar TDWG mantenido por el Grupo de interés de mantenimiento del Audiovisual Core. Incluye un vocabulario principal y varios vocabularios controlados, así como varias guías que explican cómo deben utilizarse los vocabularios. El propósito del Audiovisual Core es representar metadatos para recursos y colecciones multimedia sobre biodiversidad, y hacer posible que los usuarios determinen si esos recursos serían adecuados para alguna aplicación de la ciencia de la biodiversidad antes de adquirir los medios.
## Para comenzar
-- [Introduction to Audiovisual Core](introduction/)
-- [Term list](termlist/): list of all terms included in the main Audiovisual Core vocabulary
-- Usage guides: [detailed guide to aims and uses](guide/) and [guide for structuring records](structure/)
-- Examples: work-in-progress pages to document how Audiovisual Core is used "in the wild" for [still images](https://github.com/tdwg/ac/blob/master/image/examples.md). Pages for sound and video to come...
-- [GitHub repository](https://github.com/tdwg/ac): where Audiovisual Core is maintained. It includes detailed records of the development of the standard and information about the day-to-day operations of the Maintenance Group. This is the place to go if you want to become involved in improving Audiovisual Core.
+- [Introducción al Audiovisual Core](introduction/)
+- [Lista de términos](termlist/): lista de todos los términos incluidos en el vocabulario principal del Audiovisual Core
+- Guías de uso: [guía detallada de objetivos y usos](guide/) y [guía para estructurar registros](structure/)
+- Ejemplos: páginas de trabajo en progreso para documentar cómo se utiliza Audiovisual Core "en la práctica" para [imágenes fijas](https://github.com/tdwg/ac/blob/master/image/examples.md). Próximamente páginas de sonido y vídeo...
+- [Repositorio de GitHub](https://github.com/tdwg/ac): donde se mantiene el Audiovisual Core. Incluye registros detallados del desarrollo de la norma e información sobre las operaciones diarias del Grupo de Mantenimiento. Este es el lugar al que debes acudir si quieres involucrarte en la mejora del Audiovisual Core.
diff --git a/docs/es/introduction/index.md b/docs/es/introduction/index.md
index bb7fd806..de03800f 100644
--- a/docs/es/introduction/index.md
+++ b/docs/es/introduction/index.md
@@ -1,161 +1,78 @@
-# Audiovisual Core Introduction
+# Introducción al Audiovisual Core
-Title
-: Audiovisual Core Introduction
+Título
+: Introducción al Audiovisual Core
-Date version issued
+Fecha de publicación de la versión
: 2023-02-24
-Date created
+Fecha de creación
: 2013-10-23
-Part of TDWG Standard
+Parte del Estándar TDWG
:
-This version
+Esta versión
:
-Latest version
+Última versión
:
-Previous version
+Versión anterior
:
-Abstract
-: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. These vocabularies aim to represent information that will help to determine whether a particular resource or collection will be fit for some particular biodiversity science application before acquiring the media. Among others, the vocabularies address such concerns as the management of the media and collections, descriptions of their content, their taxonomic, geographic, and temporal coverage, and the appropriate ways to retrieve, attribute and reproduce them.
+Resumen:
+El Audiovisual Core es un conjunto de vocabularios diseñados para representar metadatos de recursos y colecciones multimedia sobre biodiversidad. Estos vocabularios tienen como objetivo representar información que ayudará a determinar si un recurso o colección en particular será adecuado para alguna aplicación particular de la ciencia de la biodiversidad antes de adquirir los medios. Entre otras cosas, los vocabularios abordan cuestiones como la gestión de los medios y las colecciones, las descripciones de su contenido, su cobertura taxonómica, geográfica y temporal, y las formas apropiadas de recuperarlos, atribuirlos y reproducirlos.
-Contributors
+Contribuyentes
: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
-Creator
-: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+Creador
+: Grupo de Trabajo de Recursos Multimedia y Grupo de Mantenimiento del Audiovisual Core de GBIF/TDWG
-Bibliographic citation
-: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Introduction. Biodiversity Information Standards (TDWG).
+Citación bibliográfica
+: Grupo de Trabajo de Recursos Multimedia y Grupo de Mantenimiento del Audiovisual Core de GBIF/TDWG. 2023. Introducción al Audiovisual Core. Biodiversity Information Standards (TDWG).
## 1 Introducción
-There are four documents included in the Aububon Core Standard. This document
-provides a general introduction to the Audiovisual Core Standard. For information
-about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
-document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
-For a more detailed guide to the use of Audiovisual Core, see the
-[Audiovisual Core Guide](../guide/) document.
+Hay cuatro documentos incluidos en el Estándar Audiovisual Core. Este documento ofrece una introducción general al Estándar Audiovisual Core. Para obtener información sobre la estructura del Audiovisual Core, consulte el documento [Estructura del Audiovisual Core](../structure/). Para conocer detalles de los términos, consulte el documento [Lista de términos del Audiovisual Core](../termlist/).
+Para obtener una guía más detallada sobre el uso de Audiovisual Core, consulte el documento [Guía de Audiovisual Core](../guide/).
### 1.1 Estado del contenido de este documento
-All sections of this document are non-normative.
-
-### 1.2 The scope of Audiovisual Core
-
-The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
-simply “AC”) is a set of metadata vocabularies for describing
-biodiversity-related multimedia resources and collections. The
-specification is independent of how these vocabularies may be
-represented for machine use.
-
-Multimedia Resources are digital or physical artifacts which normally
-comprise more than text. These include pictures, artwork, drawings,
-photographs, sound, video, animations, presentation materials, and
-interactive online media including, e.g., identification tools. A
-multimedia collection is an assemblage of such objects, whether curated
-or not, and whether electronically accessible or not. For the purposes
-of this document we regard a collection of multimedia resources itself
-as a ‘multimedia resource’. Wherever discussion or specification can
-apply only to a collection or only to a single media resource, we say so
-explicitly.
-
-Multimedia descriptions are digital records that document underlying
-multimedia resources or collections. AC is focused on
-biodiversity-related multimedia resources. It shares terminology and
-concerns with many well-known and important standards for describing
-access to resources such as Dublin Core (DC), Darwin Core (DwC), the
-Adobe Extensible Metadata Platform (XMP), the International Press and
-Telecommunications Council (IPTC), the Metadata Working Group (MWG)
-schema, the Natural Collections Schema (NCD), and others. Where there is
-an exact match to the usage of such standards, AC adopts their
-identifiers and definitions. Many collections of biodiversity multimedia
-already have descriptions of their media expressed in DwC or DC. By
-using those vocabularies where suitable, AC particularly intends to make
-it easy for such collections to reuse their existing descriptions,
-augmented where necessary by other
-terms
-
-**See also:** Discovery and Publishing of Primary Biodiversity Data
-associated with Multimedia Resources: The Audiovisual Core Strategies and
-Approaches. R.
-Morris et al., _Biodiversity Informatics,_ 8, jul. 2013.
-
-## 2 Audiovisual Core terms
-
-An Audiovisual Core record is a description of a multimedia resource using
-the [Audiovisual Core terms](./terms). Two kinds
-of terms are specified by AC: record-level terms and access-level terms.
-Record-level terms apply to the media resource being described. Almost
-all terms are record-level terms. One such term, _hasServiceAccessPoint_
-plays a special role in helping to retrieve the resource that the record
-describes. A multimedia resource may have more than one
-hasServiceAccessPoint, each of which provides values of one or more
-access-level terms. The access-level terms document such things as a web
-address at which a digital representation of the resource can be
-retrieved, the size of such a retrieved object, etc. An Audiovisual Core
-record is thus a description using a set of terms that conforms to the
-normative documents, and contains at least the four mandatory terms,
-which provide an identifier, a resource type, the language of the
-description, and copyright information. Every such record describes a
-single multimedia resource (possibly including a Collection). The
-identifier may have been assigned to the resource by an external
-authority or by the provider of the record. Strictly speaking, the
-identifier is required only for Collections, but is strongly recommended
-in general.
-
-Every Audiovisual Core term has a plain text Name, a term identifier and a
-plain text normative Definition. Term identifiers conform to the
-Universal Resource Identifier (URI)
-specification.
-Typically these identifiers have a form familiar to browser users as the
-addresses of web pages, beginning with "http://". Informally, one may
-understand this thusly: an http URI has the syntax of a web address, but
-there is no expectation that putting it in a web browser will result in
-any information being returned to the browser, and if it does, the
-return may have no relevance.
-
-Because http URIs are rather lengthy, AC documents follow a standard
-practice of introducing a short prefix comprising a "namespace
-qualifier" separated by a colon from a mnemonic name closely related to
-the term's Name. The namespace of the roughly 50% of the terms that are
-borrowed from other vocabularies is the namespace of the original. The
-namespace of de novo AC terms is http://rs.tdwg.org/ac/terms/. In the [Audiovisual Core Term List](../termlist/), each
-term entry has a row with the term name. Following the practice of the
-[Darwin Core terms](http://rs.tdwg.org/dwc/terms/), this term name
-is generally an "unqualified name" preceded by a widely accepted prefix
-designating an abbreviation for the namespace. The result is known as a
-qualified name. For example the normative wiki documentation for the
-borrowed term dcterms:identifier has URI
-http://purl.org/dc/terms/identifier. The first part,
-"http://purl.org/dc/terms/" corresponds to the namespace. Most of the
-URIs for terms borrowed from external vocabularies do in fact produce
-relevant documentation for that external standard when used as a web
-page URL. Sometimes it is not precise because the documentation is a PDF
-document and several (different!) URIs might apparently lead
-to the same place.
-
-## 3 Implementations
-
-The [AC Term List](../termlist/) and
-[Audiovisual Core Structure](../structure/)
-documents represent a _data model._ For actual use of Audiovisual Core, it
-is necessary to select an implementation, preferably one with some
-status designated by [TDWG](http://www.tdwg.org/). Known
-implementations will be listed in ancillary documents not included as part of the Audiovisual Core standard.
-
-## 4 References
-
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+Todas las secciones de este documento no son normativas.
+
+### 1.2 El alcance del Audiovisual Core
+
+El esquema de metadatos de recursos multimedia del Audiovisual Core ("esquema AC" o simplemente "AC") es un conjunto de vocabularios de metadatos para describir recursos y colecciones multimedia relacionados con la biodiversidad. La especificación es independiente de cómo se puedan representar estos vocabularios para su uso por máquinas.
+
+Los recursos multimedia son artefactos digitales o físicos que normalmente comprenden más que texto. Estos incluyen imágenes, obras de arte, dibujos, fotografías, sonido, videos, animaciones, materiales de presentación y medios interactivos en línea, incluidas, por ejemplo, herramientas de identificación. Una colección multimedia es un conjunto de dichos objetos, ya sean curados o no, y accesibles electrónicamente o no. A los efectos de este documento, consideramos que una colección de recursos multimedia en sí misma es un «recurso multimedia». Siempre que una discusión o especificación pueda aplicarse únicamente a una colección o a un único recurso multimedia, lo decimos explícitamente.
+
+Las descripciones multimedia son registros digitales que documentan recursos o colecciones multimedia subyacentes. AC se enfoca en recursos multimedia relacionados con la biodiversidad. Comparte terminología y asuntos con muchos estándares conocidos e importantes para describir el acceso a recursos, como Dublin Core (DC), Darwin Core (DwC), Adobe Extensible Metadata Platform (XMP), el Consejo Internacional de Prensa y Telecomunicaciones (IPTC), el esquema del Grupo de Trabajo de Metadatos (MWG), el Esquema de Colecciones Naturales (NCD) y otros. Cuando existe una coincidencia exacta con el uso de dichos estándares, AC adopta sus identificadores y definiciones. Muchas colecciones de multimedia sobre biodiversidad ya cuentan con descripciones de sus medios expresadas en DwC o DC. Al utilizar dichos vocabularios cuando sea adecuado, AC pretende facilitar que dichas colecciones reutilicen sus descripciones existentes, complementadas con otros términos cuando sea necesario.
+
+**Véase también:** [Descubrimiento y publicación de datos primarios sobre biodiversidad asociados con recursos multimedia: Estrategias y enfoques audiovisuales centrales.](https://journals.ku.edu/index.php/jbi/article/view/4117) R. Morris et al., _Biodiversity Informatics_, 8 de julio. 2013.
+
+## 2 Términos del Audiovisual Core
+
+Un registro del Núcleo Audiovisual es una descripción de un recurso multimedia que utiliza los [términos del Audiovisual Core](./terms). AC especifica dos tipos de términos: términos a nivel de registro y términos a nivel de acceso.
+Los términos a nivel de registro se aplican al recurso multimedia que se describe. Casi todos los términos son términos a nivel de registro. Uno de estos términos, _hasServiceAccessPoint_, desempeña un papel especial al ayudar a recuperar el recurso que el registro describe. Un recurso multimedia puede tener más de un hasServiceAccessPoint, cada uno de los cuales proporciona valores de uno o más términos de nivel de acceso. Los términos de nivel de acceso documentan aspectos como la dirección web en la que se puede recuperar una representación digital del recurso, el tamaño del objeto recuperado, etc. Un registro de Audiovisual Core es, por lo tanto, una descripción que utiliza un conjunto de términos que se ajusta a los documentos normativos y que contiene al menos los cuatro términos obligatorios, que proporcionan un identificador, un tipo de recurso, el idioma de la descripción e información sobre derechos de autor. Cada uno de estos registros describe un único recurso multimedia (que posiblemente incluya una colección). El identificador puede haber sido asignado al recurso por una autoridad externa o por el proveedor del registro. En sentido estricto, el identificador es obligatorio solo para colecciones, pero en general, es altamente recomendado.
+
+Cada término del Audiovisual Core tiene un nombre en texto plano, un identificador del término y una definición normativa en texto plano. Los identificadores de términos cumplen con la [especificación del Identificador Universal de Recursos (URI)](http://tools.ietf.org/html/rfc2616#section-3.2).
+Normalmente, estos identificadores tienen un formato familiar para los usuarios del navegador, como las direcciones de las páginas web, que comienzan con "http://". De manera informal, esto se puede entender así: una URI http tiene la sintaxis de una dirección web, pero no se espera que al introducirla en un navegador web se devuelva información al navegador, y si así fuera, la información devuelta podría no ser relevante.
+
+Debido a que las URL http son bastante largas, los documentos AC siguen la práctica estándar de introducir un prefijo corto que comprende un "calificador de espacio de nombres" separado por dos puntos de un nombre mnemónico estrechamente relacionado con el nombre del término. El espacio de nombres de aproximadamente el 50% de los términos que se toman prestados de otros vocabularios es el espacio de nombres del original. El espacio de nombres de los términos nuevos del AC es http://rs.tdwg.org/ac/terms/. En la [Lista de términos básicos audiovisuales](../termlist/), cada entrada de término tiene una fila con el nombre del término. Siguiendo la práctica de los [términos del Darwin Core](http://rs.tdwg.org/dwc/terms/), este nombre de término es generalmente un "nombre no calificado" precedido por un prefijo ampliamente aceptado que designa una abreviatura para el espacio de nombres. El resultado se conoce como un nombre calificado. Por ejemplo, la documentación wiki normativa para el término prestado dcterms:identifier tiene el URI http://purl.org/dc/terms/identifier. La primera parte, "http://purl.org/dc/terms/", corresponde al espacio de nombres. La mayoría de las URL de términos tomados de vocabularios externos, de hecho, generan documentación relevante para ese estándar externo cuando se utilizan como URL de una página web. A veces no es preciso porque la documentación es un documento PDF y varios URI (¡diferentes!) podrían aparentemente conducir al mismo lugar.
+
+## 3 Implementaciones
+
+Los documentos [Lista de términos de AC](../termlist/) y [Estructura del Audiovisual Core](../structure/) representan un _modelo de datos_. Para el uso real del Audiovisual Core, es necesario seleccionar una implementación, preferiblemente una con algún estatus designado por [TDWG](http://www.tdwg.org/). Las implementaciones conocidas se enumerarán en documentos complementarios que no se incluyen como parte del estándar Audiovisual Core.
+
+## 4 Referencias
+
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/es/structure/index.md b/docs/es/structure/index.md
new file mode 100644
index 00000000..a1ac2180
--- /dev/null
+++ b/docs/es/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Fecha de publicación de la versión
+: 2023-02-24
+
+Fecha de creación
+: 2013-10-23
+
+Parte del Estándar TDWG
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creador
+: Grupo de Trabajo de Recursos Multimedia y Grupo de Mantenimiento del Audiovisual Core de GBIF/TDWG
+
+Citación bibliográfica
+: Grupo de Trabajo de Recursos Multimedia y Grupo de Mantenimiento del Audiovisual Core de GBIF/TDWG. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introducción
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Estado del contenido de este documento
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 Palabras clave RFC 2119
+
+Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" y "OPTIONAL" en este documento deben interpretarse como se describe en la [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/fr/guide/index.md b/docs/fr/guide/index.md
new file mode 100644
index 00000000..18951934
--- /dev/null
+++ b/docs/fr/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Statut du contenu de ce document
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Label |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ La nature ou le genre de la ressource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Label |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/fr/introduction/index.md b/docs/fr/introduction/index.md
index b6cfa031..2c935ff3 100644
--- a/docs/fr/introduction/index.md
+++ b/docs/fr/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 Introduction
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/fr/structure/index.md b/docs/fr/structure/index.md
new file mode 100644
index 00000000..5a39e676
--- /dev/null
+++ b/docs/fr/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Statut du contenu de ce document
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 Mots clés RFC 2119
+
+Les mots clés "MUST/DOIT", "MUST NOT/NE DOIT PAS", "REQUIRED/OBLIGATOIRE", "SHALL/DEVRA", "SHALL NOT/NE DEVRA PAS", "SHOULD/DEVRAIT", "SHOULD NOT/NE DEVRAIT PAS", "RECOMMENDED/RECOMMANDÉ", "MAY/POURRAIT", et "OPTIONAL/OPTIONNEL" dans ce document doivent être interprétés comme défini dans [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/ja/guide/index.md b/docs/ja/guide/index.md
new file mode 100644
index 00000000..2c63c15b
--- /dev/null
+++ b/docs/ja/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 イントロダクション
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 この文書の内容のステータス
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | ラベル |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | ラベル |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/ja/introduction/index.md b/docs/ja/introduction/index.md
index 9af52d90..95cdf3e5 100644
--- a/docs/ja/introduction/index.md
+++ b/docs/ja/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 イントロダクション
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/ja/structure/index.md b/docs/ja/structure/index.md
new file mode 100644
index 00000000..80862b13
--- /dev/null
+++ b/docs/ja/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 イントロダクション
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 この文書の内容のステータス
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 キーワード
+
+この文書における “MUST”、”MUST NOT”、”REQUIRED”、”SHALL”、”SHALL NOT”、”SHOULD”、”SHOULD NOT”、”RECOMMENDED”、”MAY”、”OPTIONAL” というキーワードは、[RFC 2119](https://tools.ietf.org/html/rfc2119) に記述されているように解釈されます。
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/km/guide/index.md b/docs/km/guide/index.md
new file mode 100644
index 00000000..93b189ca
--- /dev/null
+++ b/docs/km/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Status of the content of this document
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Label |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Label |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/km/introduction/index.md b/docs/km/introduction/index.md
index fbace2b6..9175b943 100644
--- a/docs/km/introduction/index.md
+++ b/docs/km/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 Introduction
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/km/structure/index.md b/docs/km/structure/index.md
new file mode 100644
index 00000000..95eb7c14
--- /dev/null
+++ b/docs/km/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Status of the content of this document
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 key words
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/ko/guide/index.md b/docs/ko/guide/index.md
new file mode 100644
index 00000000..93b189ca
--- /dev/null
+++ b/docs/ko/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Status of the content of this document
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Label |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Label |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/ko/introduction/index.md b/docs/ko/introduction/index.md
index fbace2b6..9175b943 100644
--- a/docs/ko/introduction/index.md
+++ b/docs/ko/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 Introduction
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/ko/structure/index.md b/docs/ko/structure/index.md
new file mode 100644
index 00000000..95eb7c14
--- /dev/null
+++ b/docs/ko/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Status of the content of this document
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 key words
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/nl/guide/index.md b/docs/nl/guide/index.md
new file mode 100644
index 00000000..93b189ca
--- /dev/null
+++ b/docs/nl/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Status of the content of this document
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Label |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Label |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/nl/introduction/index.md b/docs/nl/introduction/index.md
index fbace2b6..9175b943 100644
--- a/docs/nl/introduction/index.md
+++ b/docs/nl/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 Introduction
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/nl/structure/index.md b/docs/nl/structure/index.md
new file mode 100644
index 00000000..95eb7c14
--- /dev/null
+++ b/docs/nl/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Status of the content of this document
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 key words
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/pt/guide/index.md b/docs/pt/guide/index.md
new file mode 100644
index 00000000..93b189ca
--- /dev/null
+++ b/docs/pt/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Status of the content of this document
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Label |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Label |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/pt/introduction/index.md b/docs/pt/introduction/index.md
index fbace2b6..9175b943 100644
--- a/docs/pt/introduction/index.md
+++ b/docs/pt/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 Introduction
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/pt/structure/index.md b/docs/pt/structure/index.md
new file mode 100644
index 00000000..95eb7c14
--- /dev/null
+++ b/docs/pt/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Status of the content of this document
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 key words
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/ru/guide/index.md b/docs/ru/guide/index.md
new file mode 100644
index 00000000..ca789495
--- /dev/null
+++ b/docs/ru/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1. Введение
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Статус содержания документа
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Метка |
+ Тип |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ Характер или жанр ресурса. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Метка |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/ru/introduction/index.md b/docs/ru/introduction/index.md
index 45a91974..e817f244 100644
--- a/docs/ru/introduction/index.md
+++ b/docs/ru/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1. Введение
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/ru/structure/index.md b/docs/ru/structure/index.md
new file mode 100644
index 00000000..fd0c897b
--- /dev/null
+++ b/docs/ru/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1. Введение
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Статус содержания документа
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 Ключевые слова RFC 2119
+
+Ключевые слова "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", и "OPTIONAL" в настоящем документе следует понимать так, как описано в [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Наилучшее качество |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Наилучшее качество |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Миниатюра |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/zh-Hans/guide/index.md b/docs/zh-Hans/guide/index.md
new file mode 100644
index 00000000..93b189ca
--- /dev/null
+++ b/docs/zh-Hans/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 Status of the content of this document
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | Label |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | Label |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/zh-Hans/introduction/index.md b/docs/zh-Hans/introduction/index.md
index fbace2b6..9175b943 100644
--- a/docs/zh-Hans/introduction/index.md
+++ b/docs/zh-Hans/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 Introduction
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/zh-Hans/structure/index.md b/docs/zh-Hans/structure/index.md
new file mode 100644
index 00000000..95eb7c14
--- /dev/null
+++ b/docs/zh-Hans/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 Introduction
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 Status of the content of this document
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 key words
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ Best Quality |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Best Quality |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ Thumbnail |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.
diff --git a/docs/zh-Hant/guide/index.md b/docs/zh-Hant/guide/index.md
new file mode 100644
index 00000000..245fb9e3
--- /dev/null
+++ b/docs/zh-Hant/guide/index.md
@@ -0,0 +1,925 @@
+# Audiovisual Core Guide
+
+Title
+: Audiovisual Core Guide
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-15
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core is a set of vocabularies designed to represent metadata for biodiversity multimedia resources and collections. This non-normative document provides some background to the aims and uses of the standard.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) ()
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Guide. Biodiversity Information Standards (TDWG).
+
+## 1 引言
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) is a data standard for exchanging data describing biodiversity multimedia
+resources and collections produced by the GBIF/TDWG joint Multimedia
+Resources Metadata Task Group (MRTG). The standard consists of four documents. This document is a guide to the aims and uses of the standard. The Audiovisual
+Core Introduction document provides a brief introduction to the Audiovisual Core Standard. For detailed information about the structure of Audiovisual Core, see the [Audiovisual Core Structure](structure) document. For term details, see the [Audiovisual Core Terms List](terms) document.
+
+Acronyms and named institutions and projects are listed in a Glossary in
+Appendix I.
+
+### 1.1 本文件內容的現況
+
+All sections of this document are non-normative.
+
+## 2 Summary
+
+The Audiovisual Core Multimedia Resources Metadata schema (“AC schema”, or
+simply “AC”) is a set of metadata vocabularies for describing
+biodiversity-related multimedia resources and collections. The
+specification is independent of how these vocabularies may be
+represented for machine use.
+
+Multimedia Resources are digital or physical artifacts which normally
+comprise more than text. These include pictures, artwork, drawings,
+photographs, sound, video, animations, presentation materials, and
+interactive online media including, e.g., identification tools. A
+multimedia collection is an assemblage of such objects, whether curated
+or not, and whether electronically accessible or not. For the purposes
+of this document we regard a collection of multimedia resources itself
+as a ‘multimedia resource’. Wherever discussion or specification can
+apply only to a collection or only to a single media resource, we say so
+explicitly.
+
+Multimedia descriptions are digital records that document underlying
+multimedia resources or collections. AC is focused on
+biodiversity-related multimedia resources. It shares terminology and
+concerns with many well-known and important standards for describing
+access to resources such as Dublin Core (DC), Darwin Core (DwC), the
+Adobe Extensible Metadata Platform (XMP), the International Press and
+Telecommunications Council (IPTC), the Metadata Working Group (MWG)
+schema, the Natural Collections Schema (NCD), and others. Where there is
+an exact match to the usage of such standards, AC adopts their
+identifiers and definitions. Many collections of biodiversity multimedia
+already have descriptions of their media expressed in DwC or DC. By
+using those vocabularies where suitable, AC particularly intends to make
+it easy for such collections to reuse their existing descriptions,
+augmented where necessary by other terms.
+
+This guide accompanies the normative parts of the AC standard,
+which are included in two documents: one that describes the structure of the document [\[1\]](#fn-1)
+and a Term List document [\[2\]](#fn-2). The Term List
+documents a series of terms, each of which is identified by a unique
+Uniform Resource Identifier (URI), together with normative definitions.
+In addition, the Audiovisual Core Maintenance Group may develop recommended representations for AC
+descriptions in several important forms including RDF [\[3\]](#fn-3), XML
+Schema [\[4\]](#fn-4), and Comma Separated Values (CSV) [\[5\]](#fn-5).
+
+Figure 1 below augments a portion of Figure 2 of the non-normative
+portion of the NCD document [\[6\]](#fn-6). It shows a number of kinds of
+biodiversity data-centric resources and illustrates typical user
+communities, data and metadata standards, and network services that
+support the discovery, analysis, and integration of data. We extracted
+from the NCD figure the resources and relationships between them, which
+we augment with three types not in the main purview of NCD. These are:
+Observations, Ecological Models, and the focus of this work, Multimedia
+Resources. Applications exploiting each kind of these resources find
+utility, or sometimes require the use of multimedia resources to
+document them. For example, the Biological Heritage Library is a project
+that provides scanned images of legacy literature at a far greater rate
+than it can provide digitized versions based on optical character
+recognition, and these images remain available as sources for any
+subsequent derived products. Thus digitized legacy literature is
+documented by the page images. Most scientific literature of course is
+also illustrated by photographs, graphs, or other artifacts in the
+purview of the Audiovisual Core. Even the providers of “Molecular DNA"
+resources sometimes will offer original data as digital images of
+microarray chips.
+
+
+
+Figure 1. Relationships of Multimedia Resources to primary types of
+biodiversity resources
+
+## 3 Audiovisual Core Terms
+
+An Audiovisual Core record is a description, using the Audiovisual Core terms,
+of a multimedia resource. Two kinds of terms are specified by AC:
+_record-level terms_ and _access-level terms._ Record-level terms apply
+to the media resource being described. Almost all terms are record-level
+terms. One such term, _serviceAccessPoint_ plays a special role in
+helping to retrieve the resource that the record describes. A multimedia
+resource may have more than one serviceAccessPoint, each of which is
+described by values of one or more access-level terms. The access-level
+terms provide such things as a web address at which a digital
+representation of the resource can be retrieved, the size of such a
+retrieved object, etc.
+
+An Audiovisual Core record is thus a set of terms that conforms to the
+normative documents, contains at least the four mandatory terms
+described below, and which provides metadata that describes a single
+multimedia resource (possibly including a Collection). It usually
+includes an identifier that may have been assigned to the resource by an
+external authority or by the provider of the metadata record.
+
+Every Audiovisual Core term has a plain text Name, a URI, and a plain text
+normative Definition. Terms may also have Usage instructions explaining how the term is used in the context of Audiovisual Core and Notes that provide additional information and examples. URIs for terms conform to the http URI scheme.
+Informally, one may understand this thusly: an http URI has the syntax
+of an http URL, but there is no expectation that putting it in a web
+browser will result in any information being returned to the browser,
+and if it does, the return may have no relevance.
+
+Because http URIs are rather lengthy, AC documents follow a standard
+practice of introducing a short prefix comprising a "namespace
+qualifier" separated by a colon from a mnemonic name closely related to
+the term's Name. The namespace of terms borrowed from other vocabularies
+is that of the original. The namespace of denovo AC terms is
+http://rs.tdwg.org/ac/terms/. In the table of terms, each term entry has
+a row with the term name. Following the practice of the Darwin Core term
+list [\[7\]](#fn-7), for borrowed terms, this term name is generally an
+"unqualified name" preceded by a widely accepted prefix designating an
+abbreviation for the namespace, whereas for denovo AC terms, no such
+prefix is prepended. It is recommended that implementers who need a
+namespace prefix for the AC namespace use "ac" wherever feasible. The
+result is known as a qualified name. For example the normative wiki
+documentation for the borrowed term dcterms:identifier has URI
+http://purl.org/dc/terms/identifier. In this document we will follow the established
+qualified name convention. In
+fact, most of the URIs for terms borrowed from external vocabularies
+(about half of them) do in fact resolve to something in relevant
+documentation for that external standard. Sometimes it is not precise
+because the documentation is a PDF document and several (different\!)
+URIs might apparently resolve to the same place.
+
+Examples from the Term List are shown
+below.
+
+
+
+
+ | Term Name: |
+ dcterms:type |
+
+
+ | Normative URI: |
+ http://purl.org/dc/terms/type |
+
+
+ | 標籤 |
+ Type |
+
+
+ |
+ Layer: 1 — Required: Yes — Repeatable: No |
+
+
+ | Definition: |
+ The nature or genre of the resource. |
+
+
+ | Usage: |
+ A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI. |
+
+
+ | Notes: |
+ Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audiovisual Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails. |
+
+
+
+
+
+
+
+ | Term Name: |
+ ac:reviewerLiteral |
+
+
+ | Normative URI: |
+ http://rs.tdwg.org/ac/terms/reviewerLiteral |
+
+
+ | 標籤 |
+ Reviewer |
+
+
+ |
+ Layer: 2 — Required: No — Repeatable: Yes |
+
+
+ | Definition: |
+ String providing the name of a reviewer. If present, then resource is peer-reviewed, even if Reviewer Comments is absent or empty. Its presence tells whether an expert in the subject featured in the media has reviewed the media item or collection and approved its metadata description; must display a name or the literal "anonymous" (= anonymously reviewed). |
+
+
+ | Notes: |
+ Provider is asserting they accept this review as competent. See also ac:reviewer and the section Namespaces, Prefixes and Term Names in the Audiovisual Core Term List document for discussion of the rationale for separate terms taking URI values from those taking Literal values where both are possible. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. |
+
+
+
+
+The principal namespace qualifiers for term URIs in this document are
+
+- **dcterms:** and **dc:** The DCMI vocabulary documented at
+ http://dublincore.org/documents/dcmi-terms
+
+- **dwc:** The Darwin Core vocabulary described at
+ http://rs.tdwg.org/dwc/index.htm
+
+- **Iptc4ampExt:** Geographic extensions to IPTC with namespace
+ http://iptc.org/std/Iptc4xmpExt/2008-02-29/ documented in
+ http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.pdf
+
+- **ac:** Terms in the namespace http://rs.tdwg.org/ac/terms not derived
+ from other controlled vocabularies. The normative definitions of these documents can be found in the [Audiovisual Core Term List document](termlist.md)
+
+- **xmp:** The Adobe XMP vocabularies with namespace
+ http://ns.adobe.com/xap/1.0/ documented in Section 8.4 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **xmpRights:** The Adobe XMP rights vocabulary with namespace
+ http://ns.adobe.com/xap/1.0/rights documented in Section 8.5 of
+ https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
+
+- **photoshop:** Adobe XMP additional properties with namespace http://ns.adobe.com/photoshop/1.0/ documented at http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf
+
+- **exif:** the Camera and Imaging Products Association Exchangeable Image File Format vocabulary with namespace http://ns.adobe.com/exif/1.0/ documented at http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
+
+## 4 Motivation and Rationale
+
+Many valuable multimedia resources exist that have no information stored
+in databases. Some may have a web presence and others not. Even those
+available online may not be adequately discoverable by search engines,
+or may be lost in the noise of images from unreliable sources. A brief
+descriptive record as defined by the Audiovisual Core standard can act as
+the “business card” for a multimedia resource, providing enough
+information to identify and locate media resources by researchers,
+aggregators, decision makers, educators, or the general public.
+
+The standard enables the aggregation of multimedia resource descriptions
+from many sources and facilitates resource discovery, including
+establishing relationships among multimedia resources in several
+locations. AC records can also be used as an aid for multimedia
+resources management processes, allowing an institution to take a step
+back and see which collections are most in need of conservation or would
+benefit from a higher priority for item-level cataloguing.
+
+Among important uses identified by the Task Group, which are facilitated
+by the metadata, are:
+
+1. Discovery;
+
+2. Evaluation of fitness-for-use prior to fetching a resource
+ (especially relevant for off-line resources);
+
+3. Use of metadata records as potential taxon occurrence evidence, or
+ other biological inferences such as evidence for species
+ interactions, habitats, and phenotypic variation;
+
+4. Identification aids;
+
+5. Easing the burden of multimedia resource providers and producers to
+ gather and serve resources contributed by a wide variety of
+ producers and custodians, particularly those with little or no IT
+ expertise or support.
+
+To ensure that the barriers to use are as low as possible, only four
+properties of an Audiovisual Core record are considered to be mandatory:
+
+1. Identifier (dcterms:identifier): An arbitrary code that is unique
+ for the resource, with the resource being either a provider,
+ collection, or media item. Whereas the identifier must be globally
+ unique for providers and collections (e. g. a URI), identifiers for
+ media items may be unique only within the context of a collection or
+ provider. In fact the standard strongly recommends but does not
+ require an Identifier for media items, though it does so for a
+ provider or collection.
+
+2. Type (dcterms:type): Any dcmi type term from
+ http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary may be used.
+ Recommended terms are Collection, StillImage, Sound, MovingImage,
+ InteractiveResource, and Text.
+
+3. Metadata Language (ac:MetadataLanguage): Language of description and
+ other metadata (but not necessarily of the image itself)
+
+4. Copyright Statement (dcterms:rights): Information about rights held
+ in and over the resource. A full-text, readable copyright statement,
+ as required by the national legislation of the copyright holder. On
+ collections, this applies to all contained objects, unless the
+ object itself has a different statement. When available, it is also
+ recommended to provide the Copyright Owner using xmpRights:Owner
+
+In addition it is strongly recommended to provide a concise title of the
+resource, using dcterms:title
+
+## 5 Existing Standards
+
+The Audiovisual Core intends to provide metadata that describe either media
+resources themselves or collections of them. There are several
+well-known or newly emerging standards that address these concerns, so
+one may ask: why not simply use them? In fact, AC does exactly that in
+about half of its 80 elements, almost all of which are optional. Indeed,
+as shown above, most of the mandatory terms come from external
+controlled vocabularies. However, all existing controlled vocabularies,
+most notably the widely used Dublin Core, present very few opportunities
+to provide media resource content metadata that is specifically
+biologically relevant. Use of the Dublin Core alone would make it
+difficult to do media resource discovery with high precision. Thus, one
+consequence of using Dublin Core alone would be that queries will not be
+selective enough. By contrast the Darwin Core TDWG standard [\[8\]](#fn-8) has
+more support for some such concerns, but little about important
+intellectual property rights issues, or ways to express relationships
+between alternate versions of media resources (e.g. different resolution
+versions). In turn, neither of these controlled vocabularies has
+mechanisms for capturing technical metadata, such as EXIF, which the
+imaging systems themselves, or metadata embedding tools, such as Adobe
+Photoshop(tm) and the GIMP open source image editor, can insert into
+media files and streams. To address this, and in furtherance of the
+above goals, the Audiovisual Core should be regarded as a synthesis of DC,
+DwC, and, where those are inadequate, some forward looking metadata
+standards that the camera manufacturers are presently planning to
+support within the cameras themselves, much as they now use EXIF [\[9\]](#fn-9).
+Where any of these standards suffice, AC metadata terms and definitions
+are those of such standards. In some instances, we find that none of
+these address concerns that our experience suggests are held by a wide
+variety of image contributors, especially those with limited access to
+sophisticated IT staff or to Digital Librarians. The AC schema might be
+regarded as an extension to the union of small subsets of several
+accepted standards (together with a framework to insure that use of
+metadata from these standards can be understood by people and machines
+as referring to the same resource). Put another way, much of AC may be
+viewed as a wrapper around DwC, DC, XMP, and IPTC [\[10\]](#fn-10).
+
+Since the overwhelming portion of the AC metadata fields are optional, a
+resource provider that can already serve Dublin Core metadata, could
+essentially serve little else but that, plus a suitable globally unique
+identifier to tie all the metadata to the same object. Similarly, a
+provider describing image content entirely with Darwin Core terms might
+have little more to do. However, both such providers would find that
+value-added services such as metadata-indexers and caching aggregators
+and would be less likely to keep references to their media resources and
+metadata than if they had richer metadata. This gives a clear strategy
+for providers to increase the utility of their multimedia resources with
+little or no impact on their IT cyberinfrastructure services. They may
+need only to update mappings between their internal field names and the
+metadata terms specified by AC, as personnel become available to do so.
+As more resources become available to record additional metadata, and as
+community annotation mechanisms arise to support this, they can add the
+additional metadata at a pace determined by their own resources. If
+harvesters of the metadata monitor the (optional) Metadata Date property
+(xmp:MetadataDate), the updated metadata can automatically be pulled by
+those value-added services, and more queries will return the provider's
+metadata and references to its media resources.
+
+## 6 Common Concerns with Other Biodiversity Information Standards
+
+The Audiovisual Core regards Collections of Multimedia Resources themselves
+as a kind of Resource. Many types of Collections are describable in the
+pending TDWG Natural History Collections (NCD) proposed standard. If a
+provider wishes only to provide for discovery of a multimedia Collection
+without regard to discovery of and access to its contents (other than
+sub Collections), it will often be immaterial whether NCD or AC
+metadata, or both, are served. This is all the more so if the NCD
+CollectionIdentifier and the Audiovisual Core Identifier have the same
+value. While Audiovisual Core Collection types are richer than NCD types, it
+is an open question whether Audiovisual Core's variety in this case is
+useful.
+
+There is substantial overlap with use of Darwin Core terms, notably with
+respect to taxonomic, geographic, and temporal coverage of the data
+being described by the metadata record. We use DwC terms for most of
+those metadata and the entirety of the Darwin Core geolocation vocabulary
+are included by reference. GPS point locations increasingly common in
+image data created by cameras is easily mapped to the 'verbatim'
+locality terms of Darwin Core.
+
+## 7 Concerns Not Emphasized in Other Biodiversity Information Standards
+
+Some of the concerns mentioned here are also those of bibliographic
+metadata such as the Dublin Core. These are, however, not explicitly of
+detailed concern in existing TDWG biodiversity standards, and some are
+not adequately addressed by DC. Some such concerns are below.
+
+**Size**: Individual multimedia resources such as images, and especially
+video and sound are very large compared to specimen records, observation
+data, or species descriptions. The main consequence of this is that
+multimedia metadata must support use cases for which humans or software
+agents can, without fetching the resource, attempt to assess the fitness
+of the underlying media resource for the desired use, typically by use
+of a search based on a fine-grained controlled vocabulary. However,
+without hit-and-miss natural language searches, it is not possible, even
+using both DC and DwC, for a metadata provider to answer a request of
+the form "Supply me with sizes and URL access points for still images of
+_Dictyophora indusiata_ and which have Spanish metatdata available.
+
+**Intellectual Property Rights**: DwC describes physical objects, whose
+ownership is generally governed by property laws not considered part of
+the Intellectual Property Rights corpus of law. Some impending standards
+about scientific literature address these, but rarely are publication
+reproduction permission issues as varied as for multimedia, which have a
+history of being treated as creative works of art, not necessarily as
+facts.
+
+**Provenance**: For any scientific data, it is clearly important to know
+how and when the data may have been changed from its original gathering.
+This is particularly important for media, which are commonly edited for
+one or another purpose. If carelessly done, this may destroy some if the
+modified object's utility. No TDWG standards or proposed standards seem
+very robust about provenance, including Audiovisual Core, which provides
+only the Derived From property in order to provide a reference to
+another resource. This is somewhat akin to the NCD DerivedCollection
+term, which identifies a Collection record as having been produced by a
+query to another Collection. However, that apparently does not identify
+the source collection or the query. A future version of Audiovisual Core
+will add more provenance terms.
+
+## 8 Multimedia Resource Descriptions
+
+The term Multimedia Resources encompasses a wide variety of objects of
+interest to biologists and the communities with whom they interact for
+research, education, and public service. Some instances of multimedia
+are familiar. These include:
+
+- Still images from cameras, scanners, or medical and industrial
+ imaging devices
+
+- Movies with or without sound
+
+- Audio recordings
+
+In some of the above cases, these resources may exist in electronic or
+non-electronic form or both. The electronic form may be analog or
+digital, the latter being more amenable to storage and exchange with
+computers. The digital form may have been born digital, i.e. originally
+captured as a digital object, or it may have been created from a
+non-digital object. As with biological specimen records, publications,
+field notes, experimental data and other artifacts of the practice of
+science, there is a large quantity of such material that has not yet
+been digitized, yet which may be available, albeit with greater expense
+and inconvenience than digital resources. These analog (including paper)
+resources still require descriptive metadata to promote discovery and to
+ascertain fitness-for-use. At least as important, some of the metadata
+is itself of scientific and educational use even if the object is not
+conveniently accessible. Evidence for georeferenced taxon occurrence is
+one such use.
+
+Audiovisual Core metadata also can describe resources less often thought of
+as multimedia objects. These include:
+
+- Interactive software applications, either on the web or available
+ for stand-alone use
+
+- Taxonomic identification keys
+
+- Collections of multimedia resources
+
+- Web sites not otherwise falling into one of the above categories
+
+## 9 Audiovisual Core Records
+
+The normative Audiovisual Core metadata record specification is independent
+of the way in which those records are rendered into electronic form.
+MRTG intends to publish specifications for such rendering represented
+in, represented in XML constrained by an XML-Schema, and represented in
+plain text as comma separated values (CSV). [Sections 4.4 to 4.5 of the TDWG Standards Documentation Specification](https://github.com/tdwg/vocab/blob/master/sds/documentation-specification.md#44-vocabularies-term-lists-and-terms) describe how basic term metadata should be expressed in machine-readable forms such as RDF serializations. A future task group might develop a more semantically rich machine-readable ontology following the procedures listed in [Section 4 of the TDWG Vocabulary Maintenance Specification](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#4-vocabulary-enhancements).
+
+The language of the normative Audiovisual Core specification is English, but
+this in no way constrains applications from using labels or content of
+the metadata in local languages. Because its language is English, each
+metadata item in the normative document has an English label (which
+might, for example be part of a user interface), but these, too, are not
+required to be used by applications, although their use is strongly
+encouraged, at least in documentation.
+
+As mentioned earlier, an Audiovisual Core metadata record is a set of terms
+describing the underlying multimedia resource that the record describes.
+Each term is identified by a Uniform Resource Identifier (URI). These
+are URIs of the attribute, not of the underlying resource, and they
+simply specify which term is being provided. There are many URI schemes,
+some of which have been registered with the Internet Assigned Names
+Authority (IANA). All Audiovisual Core term URIs, conform to the http URI
+Scheme. This is chosen because this widely used URI scheme uses the
+familiar internet URL syntax as its URI syntax. But this familiarity
+gives rise to a common misconception, namely that pasting the URI into a
+browser URL line, or providing it to some other application that
+respects the http protocol, should result in the application returning
+some information about the object identified by the URI. Such behavior
+is usually called resolution (or, more technically, resolution and
+dereferencing) of the URI and is in no way guaranteed for Audiovisual Core
+term URIs. Where possible, we in fact try to make http URIs be
+resolvable, with the information returned being documentation for how
+the metadata attribute identified by that URI is defined or use. To
+reiterate: for Audiovisual Core term URIs, any such resolution will never
+contain information about the underlying multimedia resource being
+described. For this reason, few human-centric Audiovisual Core applications
+should ever present the URIs to users, nor use them as linking
+mechanisms. (One possible exception is an application for assigning
+metadata to multimedia resources, where such a use may provide a
+thesaurus entry aiding the user in the semantics of the metadata
+property. However, the incidental nature of the resolution, and its lack
+of guaranteed long term persistence, makes even this approach one that
+should be considered with extreme caution.) Finally, note that some
+external controlled vocabularies are defined in PDF or other documents
+that do not have URL links directly to each defined term. In these
+cases, any resolution available from the normative document may only
+link to the beginning of the document, leaving it necessary to search in
+the document for the referenced definition.
+
+Associated to each Audiovisual Core property is its value. The datatype of
+this value is also specified in the normative document. Datatypes can
+include free text, specific literals taken from a controlled vocabulary
+specified in the normative document, or a number of other datatypes
+specified and described in the normative document. In the case of a
+controlled vocabulary, it is important to note that whatever an
+application may present in a user interface, any Audiovisual Core metadata
+interchange should use the literals from a specified controlled
+vocabulary when one is specified, even if the record is declared to be a
+record in a different language than that of the controlled term. An
+important example is the Type metadata field, which is recommended to
+come from the corresponding vocabulary from Dublin Core, augmented by
+some recommended in the normative document. (We also add to that an
+optional field Subtype.) Similarly, agents answering Audiovisual Core
+metadata queries MUST be able to consume and respond to queries framed
+with the controlled vocabulary. Nothing in the normative document
+prevents an Audiovisual Core data provider from asserting it has no records
+with a given controlled term, nor from internally mapping between a
+controlled vocabulary and its internal attributes, whose names may well
+be in a language other than English. Only a small number of Audiovisual Core
+properties take values in a specific, English-based controlled
+vocabulary. This will become relevant only for metadata interchange. Of
+the mandatory terms, only Type has any such requirements.
+
+An Audiovisual Core record consists minimally of the four mandatory fields
+(Identifier, Type, Metadata Language, and Copyright Statement).
+
+In some cases, some metadata terms are necessarily related to others
+(e.g. various versions of an image must be associated the "main"
+version). However, spreadsheets and other flat sources of contributor
+metadata are regarded as particularly important, and in many of these it
+is difficult to represent such structural relationships. Consequently an
+Audiovisual Core record is itself mainly flat, the exception being the
+object of a property named _hasServiceAccessPoint_. This object itself
+has further properties that describe how to fetch the actual media
+described by the AC record. One consequence of this is that, for some
+purposes, a metadata Provider might have to make several metadata
+records available about the same underlying resource, because the
+representation-neutral Audiovisual Core specification does not provide for
+“subproperties” on its properties, or for relations in most cases. An
+important case surrounds multilingual metadata. Because each metadata
+record is in a fixed language specified by the Metadata Language
+property (this is the language of the record, not the multimedia
+resource, in case it should have one), a Provider might have to offer
+several metadata records about the same multimedia resource. The values
+of the four required terms must be provided in every metadata record,
+even if repeated in other metadata records describing the same resource.
+At the date of this writing, the normative document does not provide a
+mechanism for identifying a metadata record that might be overarching,
+in the sense that its optional terms may be regarded as defaults for any
+not specified in other records about the same resource. This point is
+under discussion on the MRTG Wiki.
+
+Many items may be repeated in an Audiovisual Core record, but some may not,
+as indicated in the normative document. For example the Modified item
+corresponds to a date at which the media resource was modified and may
+be repeated to reflect the history of the resource. By contrast, Date
+Available is a single date or a single range of dates at which the
+underlying resource became, or will become, available.
+
+## 10 Implementation and Compliance
+
+Audiovisual Core is defined in a way that is as representation-neutral as
+possible. It provides natural language definitions of classes,
+properties and instances that are identified by URIs and it makes
+recommendations on the use and content of properties from other
+vocabularies.
+
+The URIs defined here may be used across a number of technologies, such
+as namespaces in XML Schema-valid table documents, RDF, and column
+headings in comma delimited text files.
+
+This approach facilitates:
+
+- Embedding of Audiovisual Core data within other standards such as
+ descriptions of specimens or literature.
+
+- The extension of Audiovisual Core records with other data types such as
+ the extensive geographic controlled vocabularies of the Open
+ Geospatial Consortium (OGC)
+
+- Cross walking between technologies such as a Comma Separated Value
+ file, an RDF graph, an XML document and a JSON object.
+
+The Audiovisual Core representation-neutral normative standard itself does
+not provide an off-the-shelf, self validating exchange format. Multiple
+such exchange formats meeting different requirements can be defined and
+this standard allows mapping between them.
+
+## 11 Further Information
+
+- Audiovisual Core Maintenance Group Charter
+ https://github.com/tdwg/ac/blob/master/Audiovisual-core_maintenance-group_charter.md
+
+- Discussion of the Audiovisual Core takes place at
+ https://github.com/tdwg/ac/issues
+
+- Register for the mailing list tdwg-content@lists.tdwg.org at http://lists.tdwg.org/mailman/listinfo/tdwg-content. This email list tracks all discussion about the content of TDWG standards.
+
+## 12 Appendix I: Glossary
+
+
+
+
+ | DC |
+ Dublin Core. Metadata element set that is a standard for cross-domain information resource discovery. |
+
+
+ | DCMI |
+ Dublin Core Metadata Initiative. The organization engaged in developing Dublin Core metadata standard. |
+
+
+ | DwC |
+ The Darwin Core is a TDWG standard for representation of specimen records. It has been in wide use for several years in a number of nonstandard, sometimes inconsistent, versions. A recently adopted standard version is at http://rs.tdwg.org/dwc/index.htm. |
+
+
+ | EOL |
+ Encyclopedia of Life. Information about many species. |
+
+
+ | EXIF |
+ A widely used tagging format for digital image metadata that is often embedded in the image files, particularly by modern digital cameras. Many image rendering applications can read and display EXIF data. See http://en.wikipedia.org/wiki/Exchangeable_image_file_format for a history and description. |
+
+
+ | GBIF |
+ Global Biodiversity Information Facility. Interoperable network of biodiversity databases and information technology tools. |
+
+
+ | IANA |
+ Internet Assigned Names Authority. Specifies the forms of, and registers instances of, names of various protocols in use on the internet. See especially information on the IANA http URI scheme. |
+
+
+ | IPTC |
+ IPTC is a mature standard from the International Press and Telecommunications Council. Its Intellectual Property Rights support finer-grained controlled vocabularies than DC, providing better machine processing for discovery and fitness-for-use. The current version is a vocabulary for XMP. |
+
+
+ | JSON |
+ JavaScript Object Notation. Lightweight data-interchange format. |
+
+
+ | Morphbank |
+ A specimen image repository. |
+
+
+ | MWG |
+ The Metadata Working Group is an industry consortium (Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to specify how to exploit the Adobe Extensible Metadata Platform, XMP, for embedding metadata into common image file formats in several widely used controlled vocabularies. Although MWG's thrust is mainly toward consumer applications, over two dozen open source and commercial software products and platforms support XMP and Adobe has placed a Developers' Toolkit under an open source license. |
+
+
+ | NBII |
+ The former U.S. National Biological Information Infrastructure. Its image library, the Library of Images From the Environment (LIFE), was at http://images.nbii.gov/ or http://life.nbii.gov/. If LIFE is reconstituted in any form, there might be a link there. |
+
+
+ | NCD |
+ Natural Collections Description is a draft data standard designed to describe collections of physical objects such as specimens. It can accommodate collections of media objects, but cannot relate them to descriptions of the objects themselves. |
+
+
+ | OGC |
+ Open Geospatial Consortium. Provides standards for geospatial data representation and exchange. |
+
+
+ | RDF |
+ Resource Description Framework. Lightweight ontology system to support knowledge exchange online. |
+
+
+ | TDWG |
+ Taxonomic Databases Working Group. Now known as the Biodiversity Information Standards (TDWG), it is an international working group that develops standards and protocols for sharing biodiversity data. |
+
+
+ | URI |
+ Unique Resource Identifier. Generic term for linking web resources including URLs. |
+
+
+ | XML |
+ Extensible Markup Language. A simple flexible text format playing an increasingly important role in the exchange of a wide variety of data on the Web. |
+
+
+ | XMP |
+ Adobe Extensible Metadata Platform (XMP) is a framework for embedding metadata into media files. Adobe provides a BSD-licensed open-source XMP developer’s toolkit which includes documentation about how to represent metadata in XMP. The XMP specification itself is licensed by Adobe under a "Public Patent License" by which Adobe grants everyone the right to make XMP-compliant components of their applications, but it reserves the right to withdraw the license in case such a compliant component infringes "Essential Claims" of any patent. See http://www.adobe.com/devnet/xmp/ for download information. See also MWG in this table. |
+
+
+
+
+## 13 Appendix II: Audiovisual Core Development History
+
+The Audiovisual Core Multimedia Resources Metadata Schema (Audiovisual Core) standard is the culmination of work on multimedia
+resource descriptions carried out by Key to Nature, the NBII Digital
+Image Library, Morphbank, and others, together with input from a number
+of other stakeholder communities including Encyclopedia of Life (EOL),
+the Biodiversity Heritage Library (BHL) and the University of
+Massachusetts-Boston. The Global Biodiversity Information Facility
+(GBIF) commissioned the ‘Multimedia Resources Task Group (MRTG)’ in
+March 2008 and the group was approved in December 2009 by Biodiversity
+Information Standards (TDWG) as the ‘Joint GBIF-TDWG Task Group on
+Multimedia Resources in Biodiversity’.
+
+Participants in drafting the schema (in alphabetical order)
+
+- Mr. Mihail-Constantin Carausu, Danish Biodiversity Information
+ Facility (DanBIF), Copenhagen, Denmark
+
+- Dr. Vishwas Chavan, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+- Mr. Chris Freeland, Missouri Botanical Garden, St. Louis, USA
+
+- Dr. Gregor Hagedorn, JKI, Federal Research Institute for Cultivated
+ Plants, Berlin, Germany
+
+- Prof. Robert A. Morris, University of Massachusetts at Boston, USA
+
+- Dr. Dimitry Mozzherin, Encyclopedia of Life, Woods Hole, USA
+
+- Dr Annette Olson, American Association for the Advancement of
+ Science
+
+- Prof. Greg Riccardi, Florida State University, Tallahassee, USA
+
+- Dr. Éamonn Ó Tuama, Global Biodiversity Information Facility,
+ Copenhagen, Denmark
+
+The standard was developed by the Joint Task Group to fit with the suite of standards-based data management resources being developed by GBIF.
+
+Funding was provided by the Global Biodiversity Information Facility.
+
+Grateful thanks go to Woods Hole Marine Biological Laboratory and the
+Encyclopedia of Life for hosting one of the meetings. This document,
+including some narrative is adapted from a corresponding document
+produced by the TDWG Natural Collections Descriptions (NCD) task group.
+
+### 13.1 Timeline
+
+2006, November TDWG Image Interest Group initiated
+
+2008, March GBIF commissions Multimedia Resources Task Group (MRTG)
+
+2008, June GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark
+
+2008, August GBIF Multimedia Resources Task Group meeting in Woods Hole,
+USA
+
+2008, October TDWG Image Interest Group met in Fremantle, Australia at
+the ‘TDWG Annual Conference 2008’
+
+2008, December Joint GBIF-TDWG Task Group on Multimedia Resources in
+Biodiversity commissioned
+
+2009, February GBIF Multimedia Resources Task Group met in Copenhagen,
+Denmark to refine the metadata schema
+
+2009, March GBIF – TDWG Multimedia Resources Metadata Schema (MRTG) ver.
+0.4414 drafted and opened for informal comment, evolving through v 0.9
+
+2010, February Schema v 0.9 submitted to TDWG for internal Review
+
+2010, July TDWG Internal Review 1 completed
+
+2010, November v1.0 submitted to TDWG Executive committee with response
+to Internal Review 1. Proposed Standard renamed Audiovisual Core Multimedia
+Resources Metadata Schema (AC).
+
+2011, June Response to Internal Review 2 under way.
+
+2011, September Responses to Internal Review 2 and 3 completed and
+submitted to TDWG Executive Committee
+
+2011, November Prepared responses to “Review g” and “Review h” and to
+some comments of the Review Manager, Steve Baskauf. Prepare submission
+for permission to have public comment.
+
+January-November 2012 Further preparation for submission for permission
+to have public comment
+
+### 13.2 Document revision history
+
+**0.7v1**
+
+- Harmonized document to the fact that Subtype is optional in normative v0.7
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**ACv1.0 docv1.0**
+
+- Harmonized to v1.0: replace “MRTG” with “Audiovisual Core” where used as name of schema. Correct minor typos. Add “dcterms” as prefix.
+
+**ACv1.0 docv1.0**
+
+- Further replacement of MRTG with “Audiovisual Core” or “AC”.
+
+**AC v1.0 docv 1.2**
+
+- Address Internal Review 2 comments
+
+- Fix mismatched parentheses, extra spaces, missing spaces, etc.
+
+**AC v1.0 docv1.3**
+
+- Remove requirement to have Copyright Owner provided.
+
+**AC v1.0 docv1.4**
+
+- Clean up citations of six mandatory elements instead of five.
+
+**AC v1.0 docv1.5**
+
+- Replace “keytonature.eu” with “species-id.net” to reflect move of normative wiki. Remove some unused Glossary terms. Update docv to 1.5
+
+**AC v1.0docv1.6**
+
+- Remove dcterms:title from mandatory list. Add description of it as strongly recommended. Add mention of xmpRights:Owner in Copyright Statement item in the mandatory list. Change to “four” the references of “five” mandatory elements or remove the count altogether where text becomes unambiguous. Mention acterms namespace. Correct Iptc4xmpExt namespace to http://iptc.org/std/Iptc4xmpExt/2008-02-29/. Update docv to 1.6.
+
+**AC v1docv1.7**
+
+- Clarify relation of this document to the normative docs. Set major major text to left-align, unjustified.
+
+**AC v1.0docv1.8**
+
+- Remove mention of crosswalks since no longer in normative termlist.
+
+- On p. 5 force URL of DwC terms into footnote.
+
+- Improved language about use of literals with dcterms.
+
+**C v1.0docv1.91**
+
+- Various minor grammar and punctuation corrections.
+
+- Reconciliation to current normative docs.
+
+**AC v1.0docv1.92**
+
+- More minor grammar fixes.
+
+**AC v1.0docv1.93**
+
+- Fixed inconsistent internal version references to current version. No substantive or grammatical changes. Note that v1.92 was submitted to TDWG executive committee with request for permission to hold public review.
+
+**AC v1.0docv1.94**
+
+- Change references from species-id wiki to gbif terms wiki. Adjust Fig 1
+
+**AC v1.0docv1.95**
+
+- Correct “hasAccentPoint” to “hasAcccessPoint”. Remove text suggesting this is a draft
+
+## 14 Endnotes
+
+[\[1\]](#cit-1) http://rs.tdwg.org/ac/doc/structure/
+
+[\[2\]](#cit-2) http://rs.tdwg.org/ac/doc/termlist/
+
+[\[3\]](#cit-3) [http://www.w3.org/RDF/](http://www.w3.org/RDF/)
+
+[\[4\]](#cit-4) [http://www.w3.org/standards/xml/schema](http://www.w3.org/standards/xml/schema)
+
+[\[5\]](#cit-5) [http://en.wikipedia.org/wiki/Comma-separated_values](http://en.wikipedia.org/wiki/Comma-separated_values)
+
+[\[6\]](#cit-6) https://github.com/tdwg/ncd/blob/master/NCD-v090_TDWG/NCD-v090_TDWG-NonNormative.pdf
+
+[\[7\]](#cit-7) [http://rs.tdwg.org/dwc/terms/](http://rs.tdwg.org/dwc/terms/)
+
+[\[8\]](#cit-8) [http://rs.tdwg.org/dwc/index.htm](http://rs.tdwg.org/dwc/index.htm)
+
+[\[9\]](#cit-9)
+The Metadata Working Group (MWG,
+[http://www.metadataworkinggroup.org/](http://www.metadataworkinggroup.org/)) is an industry consortium
+(Adobe, Apple, Canon, Microsoft, Nokia, and Sony) organized to
+specify how to exploit the Adobe Extensible Metadata Platform, XMP
+([http://en.wikipedia.org/wiki/Extensible_Metadata_Platform](http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)) for
+embedding into common image file formats metadata in several widely
+used controlled vocabularies. Although MWG's thrust is mainly toward
+consumer applications, over two dozen open source and commercial
+software products and platforms support XMP and Adobe has placed a
+Developers' Toolkit under an open source license. Along with
+proposals for standard serializations of the representation-neutral
+Audiovisual Core schema, MRTG intends to propose a TDWG Best Practice
+for embedding such serializations in multimedia files using XMP.
+
+[\[10\]](#cit-10)
+IPTC is a mature standard from the International Press and
+Telecommunications Council ([http://www.iptc.org](http://www.iptc.org)). Its Intellectual
+Property Rights supports finer grained controlled vocabularies than
+DC, providing better machine processing for discovery and
+fitness-for-use.
diff --git a/docs/zh-Hant/introduction/index.md b/docs/zh-Hant/introduction/index.md
index 52e8ab38..8048f91f 100644
--- a/docs/zh-Hant/introduction/index.md
+++ b/docs/zh-Hant/introduction/index.md
@@ -35,7 +35,7 @@ Bibliographic citation
## 1 引言
-There are four documents included in the Aububon Core Standard. This document
+There are four documents included in the Audiovisual Core Standard. This document
provides a general introduction to the Audiovisual Core Standard. For information
about the structure of Audiovisual Core, see the [Audiovisual Core Structure](../structure/)
document. For term details, see the [Audiovisual Core Terms List](../termlist/) document.
@@ -151,11 +151,11 @@ implementations will be listed in ancillary documents not included as part of th
## 4 References
-\| |
-\---|---|---
-[\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker
-[\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
-[\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
-[\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide
-[\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure
-[\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
+| | | |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- |
+| [\[ACISS\]](https://github.com/tdwg/ac/issues) | https://github.com/tdwg/ac/issues | AC issue tracker |
+| [\[CHANGE\]](https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md#3-change-process) | http://rs.tdwg.org/vms/doc/specification/#3-change-process | TDWG vocabulary change policy |
+| [\[DCMIU\]](http://wiki.dublincore.org/index.php/User_Guide) | http://wiki.dublincore.org/index.php/User_Guide | Dublin Core User Guide |
+| [\[GUIDE\]](../guide/) | http://rs.tdwg.org/ac/doc/guide/ | AC User Guide |
+| [\[STRCT\]](../structure/) | http://rs.tdwg.org/ac/doc/structure/ | Introduction to AC structure |
+| [\[TERMS\]](../termlist/) | http://rs.tdwg.org/ac/doc/termlist/ | AC Term List |
diff --git a/docs/zh-Hant/structure/index.md b/docs/zh-Hant/structure/index.md
new file mode 100644
index 00000000..c8a70a45
--- /dev/null
+++ b/docs/zh-Hant/structure/index.md
@@ -0,0 +1,335 @@
+# Audiovisual Core Structure
+
+Title
+: Audiovisual Core Structure
+
+Date version issued
+: 2023-02-24
+
+Date created
+: 2013-10-23
+
+Part of TDWG Standard
+:
+
+This version
+:
+
+Latest version
+:
+
+Previous version
+:
+
+Abstract
+: The Audiovisual Core Structure document provides guidance on how multimedia records can be serialized as XML and in tabular form. It also suggests how text list values can be separated.
+
+Contributors
+: [Robert A. Morris](https://orcid.org/0000-0002-6992-9446) ([University of Massachusetts at Boston, USA](http://www.wikidata.org/entity/Q15144)), [Vijay Barve](https://orcid.org/0000-0002-4852-2567) (), [Mihail Carausu](https://orcid.org/0000-0002-8234-0599) ([Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [Vishwas Chavan](https://orcid.org/0000-0002-3425-6499) ([Global Biodiversity Information Facility, Copenhagen, Denmark](http://www.wikidata.org/entity/Q1531570)), [José Cuadra](http://www.wikidata.org/entity/Q51883873) (), [Chris Freeland](https://orcid.org/0000-0002-2541-5822) ([Missouri Botanical Garden, St. Louis, USA](http://www.wikidata.org/entity/Q1852803)), [Gregor Hagedorn](https://orcid.org/0000-0001-7023-7386) ([JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany](http://www.wikidata.org/entity/Q832099)), [Patrick Leary](https://orcid.org/0000-0001-5172-8577) (), [Dimitry Mozzherin](https://orcid.org/0000-0003-1593-1417) ([Encyclopedia of Life, Woods Hole, USA](http://www.wikidata.org/entity/Q82486)), [Annette Olson](https://orcid.org/0000-0002-0772-0022) ([American Association for the Advancement of Science](http://www.wikidata.org/entity/Q40358)), [Greg Riccardi](https://orcid.org/0000-0002-3850-9983) ([Florida State University, Tallahassee, USA](http://www.wikidata.org/entity/Q861548)), [Ivan Teage](https://orcid.org/0000-0003-4176-2274) (), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052)), [Steve Baskauf](https://orcid.org/0000-0003-4365-3135) ([Vanderbilt University, Nashville, TN, USA](http://www.wikidata.org/entity/Q29052))
+
+Creator
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group
+
+Bibliographic citation
+: GBIF/TDWG Multimedia Resources Task Group and Audiovisual Core Maintenance Group. 2023. Audiovisual Core Structure. Biodiversity Information Standards (TDWG).
+
+## 1 引言
+
+This documentation describes the structure of the [TDWG](http://tdwg.org)
+Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, or
+simply AC).
+
+**If you are unfamiliar with the Audiovisual Core, _please_ read the
+[Audiovisual Core Introduction](../introduction) before
+reading this document.** The introduction lays out why there is perceived a need for a
+biodiversity media resource metadata schema, and how the standard
+attempts to use existing metadata standards where
+possible.
+
+For term details, see the [Audiovisual Core Terms List](../termlist) document and for a more detailed guide to the use of Audiovisual Core, see the [Audiovisual Core Guide](../guide) document.
+
+During development, Audiovisual core was colloquially known as MRTG, after
+its developers, the GBIF-TDWG Joint Multimedia Resources Metadata Task
+Group. Please see the [Audiovisual Core Guide](../guide) and
+also [MRTG Development History](http://www.keytonature.eu/wiki/MRTG_Development_History) for
+the development history in detail.
+
+### 1.1 本文件內容的現況
+
+Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.
+
+### 1.2 RFC 2119 關鍵字
+
+本文件中的關鍵字「必須」、「不得」、「要求」、「應」、「不應」、「應當」、「不應當」、「建議」、「可」、「可選」的定義,應按照 [RFC 2119](https://tools.ietf.org/html/rfc2119) 中的描述進行解釋。
+
+## 2 Terminology of this specification
+
+There are many ways to organize metadata specifications, particularly as
+to the nomenclature of the constituents of the metadata. Note the
+following as they apply to the Audiovisual Core:
+
+- A _Multimedia Resource_ is anything that a provider identifies as
+ belonging to one of the possible values of the AC _Type_ term and
+ optionally one or more of the _Subtype_ term values. A mechanism is
+ provided by which providers can supply a privately defined subtype
+ that will not collide with the AC defined Subtype values.
+- An AC _record_ is a set of terms with any values conforming to this
+ document, and which contain at least the four mandatory terms
+ described in the [Audiovisual Core Core Term List](../termlist), and
+ which describes a single multimedia resource (possibly including a
+ Collection). One of these, the value of _Identifier_ is a Globally
+ Unique IDentifier (GUID), which may have been assigned to the
+ resource by an external authority or by the provider of the metadata
+ record.
+
+In the [Audiovisual Core Term List](../termlist), every AC
+term has a _term name_ following a table entry _"Term:"_, a _URI_, a
+plain text normative _Definition_, a recommended English _Label_, an
+optional _Notes_ attribute. In addition, a term has an attribute telling
+whether it is mandatory and one telling whether it is repeatable.
+
+AC metadata can describe either individual multimedia resources or
+collections of resources. A few, but not many, of the AC properties have
+different values for collections than for individual media. If no such
+distinction is mentioned, AC does not assume one.
+
+Term Names for terms borrowed from other vocabularies are those in use
+for the corresponding term in those vocabularies. Term Names are
+intended principally for navigation in the AC documentation. Term Labels
+are suggestions for English labels in applications. They are
+recommendations only and are offered only in English, with the added
+expectation that they may clarify intended usage of the term.
+Communities may wish to promulgate recommendations for Labels in other
+languages, or even alternative English Labels for specialized audiences,
+e.g. school children. Labels MAY be used for navigation within the
+Term List, and are often used within the Term List itself when a term is
+mentioned within the documentation of another term. The Term List
+provides indices both by name and label.
+
+URI's for terms conform to the http URI scheme (see
+http://en.wikipedia.org/wiki/URI_scheme,
+http://www.w3.org/TR/uri-clarification, or
+http://www.ietf.org/rfc/rfc2396.txt). Informally, one may understand
+this as follows: an http URI has the syntax of an http URL, but there is
+no expectation that putting it in a web browser will result in any
+information being returned to the browser, and if there is, it may have
+no relevance. This conformance requirement applies only to the URIs that
+identify AC terms. A few AC terms permit **values** to be taken from
+another controlled vocabulary chosen by the user. In this case, those
+values may involve URIs conforming to a scheme given by that external
+vocabulary, and AC is silent on what that scheme is.
+
+The Notes field of a term's documentation points to further information,
+if any exists, about the term. In particular, for terms borrowed from
+other vocabularies, this field generally carries a link to the
+originating vocabulary's documentation for that
+term.
+
+## 3 Multiplicity and Cardinality
+
+A number of terms are repeatable. How to implement repeatability in a
+given serialization is not defined by Audiovisual Core. The following
+section gives advice on some best practices in the context of
+repeatability.
+
+The simplest case is a single repeatable term (e.g.,
+dcterms:identifier). In representations based on an XML Schema that
+permits elements to be repeated such a term may simply be repeated (e.g.
+"`...http://example.com/123http://example.com...`").
+In serializations that do not easily lend themselves to repeatable
+elements (e.g. "flat" schemata with all elements occurring only a single
+time in an otherwise unstructured record) it is possible to define
+separators to support a list of values within a single element (e.g.
+"`...http://example.com/123;
+http://example.com/456...`").
+
+In certain cases pairs or tuples of properties are repeated. In Audiovisual
+Core this situation occurs, for example, in the following cases:
+
+- The language-dependent metadata like title, description, etc. need
+ to be associated with `ac:metadataLanguage`. One approach here is to
+ use complete Audiovisual Core records together with the [Metadata Language](../termlist#ac_metadataLanguage)
+ property; see there for further detail.
+- The values of properties about a Service Access Point MUST remain
+ associated with that Service Access Point even if there are multiple
+ Service Access Points. See
+ [ac:hasServiceAccessPoint](../termlist#ac_hasServiceAccessPoint)
+ for further details.
+- The terms `dwc:scientificName` and `dwc:identificationQualifier` MAY
+ optionally be structured into pairs. (See the notes on
+ [dwc:identificationQualifier](../termlist#dwc_identificationQualifier).)
+- The terms
+ [Reviewer](../termlist#ac_reviewer),
+ being the name of an individual providing some expert review of a
+ resource, and the review text itself in [Reviewer Comments](../termlist#ac_reviewerComments)
+ are desirable to store as pairs.
+
+### 3.1 Structured serializations
+
+Many serialization languages provide sufficiently structured forms to
+deal with repeated terms unambiguously. In XML, we might define
+a container element and use a nesting structure as in Section 3.1.1 Alternatively, in XML we may reference access points by identifier as in Section 3.1.2 Where such structures are impossible or undesirable, an alternative
+solution is to permit only one access point per
+container element, but to repeat the container element for a single media resource, as shown in section 3.1.3 This is similar
+to one of the options discussed for multilingual metadata (see [Metadata Language](../termlist#ac_metadataLanguage)).
+
+Note: In the examples, for human-readability the literal valued terms `dc:format` and `ac:variantLiteral` were used. However, it is designated best practice to use the IRI valued terms `dcterms:format` and `ac:variant` with controlled IRI values from the [controlled vocabulary for format](http://rs.tdwg.org/ac/doc/format/) and [controlled vocabulary for variant](http://rs.tdwg.org/ac/doc/variant/). See the notes on [dc:format](http://rs.tdwg.org/ac/doc/termlist/#dc_format) and [ac:variantLiteral](http://rs.tdwg.org/ac/doc/termlist/#ac_variantLiteral) for more information.
+
+#### 3.1.1 Nested XML structure example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ ...
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ ...
+
+
+ ```
+
+#### 3.1.2 XML reference by identifier example (non-normative)
+
+ ```
+
+ http://example.com/pictures/thePicture.jpg
+ ...
+ http://example.com/pictures/thePicture.jpg#ac0001
+ http://example.com/pictures/thePicture.jpg#ac0002
+
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+ ...
+
+ ```
+
+#### 3.1.3 Repeated container element XML example (non-normative)
+
+ ```
+
+ http//:example.com/pictures/thePicture.jpg
+ A red beech leaf
+ image/jpeg
+ http://example.com/fullres/thePicture.jpg
+ ...
+
+
+ http://example.com/pictures/thePicture.jpg
+ image/png
+ http://example.com/fullres/thePicture-hires.png
+ ...
+
+ ```
+
+### 3.2 Tabular serializations
+
+The same data as in examples 3.1.1 through 3.1.3 can be serialized as a "flat" spreadsheet-like
+table.
+
+In the example of Section 3.2.1, only the required identifier is repeated, but not
+the title field. Whether to repeat all fields or whether to provide all
+fields only in the first record, limiting later records to the
+identifier and the service access point properties, is left to specific
+implementations. In the example of Section 3.2.1, the `ac:hasServiceAccessPoint` property is suppressed
+as unnecessary.
+
+#### 3.2.1 Example of a table with each service access point in a separate row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ ac:variantLiteral |
+ dc:format |
+ ac:accessURI |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ 最佳品質 |
+ image/jpeg |
+ http://example.com/fullres/thePicture.jpg |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ 最佳品質 |
+ image/png |
+ http://example.com/fullres/thePicture-hires.png |
+
+
+ | http://example.com/pictures/thePicture.jpg |
+ |
+ 縮圖 |
+ image/png |
+ http://example.com/thumbs/thePicture-thumb.png |
+
+
+
+
+Another approach (Section 3.2.2) also eliminates the need for the `ac:hasServiceAccessPoint` property when
+flattening the ac structure. It is based on introducing new terms
+exploiting values of the [ac:variantLiteral](../termlist#ac_variantLiteral):
+"Thumbnail", "Trailer", "Lower Quality", "Medium Quality", "Good
+Quality", "Best Quality", "Offline", as prefixes for additional
+properties in a new namespace.
+
+#### 3.2.2 Example of a table with metadata for all service access points in the same row (non-normative)
+
+
+
+
+ | dcterms:identifier |
+ dcterms:title |
+ acf:thumbnailAccessURI |
+ acf:thumbnailFormat |
+ acf:thumbnailImageWidth |
+ acf:thumbnailImageHeight |
+ acf:goodQualityAccessURI |
+ acf:goodQualityFormat |
+ acf:goodQualityImageWidth |
+ acf:goodQualityImageHeight |
+ acf:bestQualityAccessURI |
+ acf:bestQualityFormat |
+ acf:bestQualityImageWidth |
+ acf:bestQualityImageHeight |
+
+
+ | http://ex.com/pictures/thePicture.jpg |
+ A red beech leaf |
+ http://example.com/thumb/thePic.jpg |
+ image/jpeg |
+ 100 |
+ 100 |
+ http://ex.com/img/thePic.jpg |
+ image/jpeg |
+ 1000 |
+ 1000 |
+ http://ex.com/hr/thePic.png |
+ image/png |
+ 10000 |
+ 10000 |
+
+
+
+
+Note: `acf:` (for "Audiovisual Core Flat") is a made-up namespace. Communities of interest might mint such terms in order to use this kind of structure.
+
+## 4 Lists of plain text values
+
+Some AC terms permit values that are lists to be represented as plain
+text. The choice of how to separate list items is ultimately left to the
+implementers of AC. Typical usage is to choose a punctuation mark such
+as ",", ";", or "|". In these cases a special escape syntax needs to be
+defined for cases in which the separator is part of the metadata value.
+Unfortunately, even for standard list formats like CSV, different
+software packages choose different escape methods, hindering
+interchange. In the absence of an implementation-specific choice we
+RECOMMEND to use "|" as separator and "\\|" as an escaped vertical bar.