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

http://www.tdwg.org/standards/638

Tato verze

http://rs.tdwg.org/ac/doc/structure/2023-02-24

Poslední verze

http://rs.tdwg.org/ac/doc/structure/

Předchozí verze

http://rs.tdwg.org/ac/doc/structure/2021-10-05

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 (University of Massachusetts at Boston, USA), Vijay Barve (), Mihail Carausu (Danish Biodiversity Information Facility (DanBIF), Copenhagen, Denmark), Vishwas Chavan (Global Biodiversity Information Facility, Copenhagen, Denmark), José Cuadra (), Chris Freeland (Missouri Botanical Garden, St. Louis, USA), Gregor Hagedorn (JKI, Federal Research Institute for Cultivated Plants, Berlin, Germany), Patrick Leary (), Dimitry Mozzherin (Encyclopedia of Life, Woods Hole, USA), Annette Olson (American Association for the Advancement of Science), Greg Riccardi (Florida State University, Tallahassee, USA), Ivan Teage (), Steve Baskauf (Vanderbilt University, Nashville, TN, USA), Steve Baskauf (Vanderbilt University, Nashville, TN, USA)

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). http://rs.tdwg.org/ac/doc/structure/2023-02-24

1. Úvod

Tato dokumentace popisuje strukturu standardu TDWG Audiovisual Core Multimedia Resources Metadata Standard (Audiovisual Core, nebo jednoduše AC).

If you are unfamiliar with the Audiovisual Core, please read the Audiovisual Core 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 document and for a more detailed guide to the use of Audiovisual Core, see the Audiovisual Core 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 and also MRTG Development History for the development history in detail.

1.1 Status obsahu tohoto dokumentu

Sections 2 through 4 of this document are normative except for example sections, which are labeled as non-normative.

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.

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. 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, 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, 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.

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ř. “...<dcterms:identifier>http://example.com/123</dcterms:identifier><dcterms:identifier>http://example.com</dcterms:identifier>...”). 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; 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 pro další podrobnosti.
• Termíny dwc:scientificName a dwc:identificationQualifier MOHOU být volitelně strukturovány do párů. (See the notes on dwc:identificationQualifier.)
• The terms Reviewer, being the name of an individual providing some expert review of a resource, and the review text itself in Reviewer Comments are desirable to store as pairs.

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).

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 a kontrolovaného slovníku pro variantu. Další informace naleznete v poznámkách k dc:format a ac:variantLiteral.

3.1.1 Příklad vnořené struktury XML (nenormativní)

```
<MEDIA_METADATA_CONTAINER>
  <dcterms:identifier>http//:example.com/pictures/thePicture.jpg</dcterms:identifier>
  ...
  <ac:hasServiceAccessPoint>
    <dc:format>image/jpeg</dc:format>
    <ac:accessURI>http://example.com/fullres/thePicture.jpg</ac:accessURI>
    ...
  </ac:hasServiceAccessPoint>
  <ac:hasServiceAccessPoint>
    ...
  </ac:hasServiceAccessPoint>
<MEDIA_METADATA_CONTAINER>
```

3.1.2 Příklad odkazu XML podle identifikátoru (nenormativní)

```
<MEDIA_METADATA_CONTAINER>
  <dcterms:identifier>http://example.com/pictures/thePicture.jpg</dcterms:identifier>
  ...
  <ac:hasServiceAccessPoint>http://example.com/pictures/thePicture.jpg#ac0001</ac:hasServiceAccessPoint>
  <ac:hasServiceAccessPoint>http://example.com/pictures/thePicture.jpg#ac0002</ac:hasServiceAccessPoint>
  <ac:ServiceAccessPoint id="http://example.com/pictures/thePicture.jpg#ac0001">
    <dc:format>image/jpeg</dc:format>
    <ac:accessURI>http://example.com/fullres/thePicture.jpg</ac:accessURI>
    ...
  </ac:ServiceAccessPoint>
  ...
<MEDIA_METADATA_CONTAINER>
```

3.1.3 Příklad opakovaného prvku kontejneru XML (nenormativní)

```
<MEDIA_METADATA_CONTAINER>
  <dcterms:identifier>http//:example.com/pictures/thePicture.jpg</dcterms:identifier>
  <dcterms:title>List červeného buku</dcterms:title>
  <dct:format>image/jpeg</dc:format>
  <ac:accessURI>http://example.com/fullres/thePicture.jpg</ac:accessURI>
  ...
<MEDIA_METADATA_CONTAINER>
<MEDIA_METADATA_CONTAINER>
  <dcterms:identifier>http://example.com/pictures/thePicture.jpg</dcterms:identifier>
  <dc:format>image/png</dc:format>
  <ac:accessURI>http://example.com/fullres/thePicture-hires.png</ac:accessURI>
  ...
<MEDIA_METADATA_CONTAINER>
```

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í)

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: „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í)

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 “\|”.