| support of OAI-PMH specification in version 2.0 | The OAI interface conforms to the protocol specification version 2.0. (M.A.1-1)
- All other requirements follow from this.
|
| xml schema conformity | All replies by the OAI interface are well formed in the XML sense and valid with regard to the XML schema defined in the OAI spe- cification and other XML schemata used for metadata formats. (M.A.1-3)
- Difficulties arise regularly with the character encoding and special characters within the metadata elements as well as with error messages in the XML stream sent by the database or the application.
|
| incremental record delivery | The OAI interface supports incremental harvesting correctly. (M.A.1-4)
- Pre-condition for this is that in every record the date of creation or alteration of the metadata is entered in the datestamp element and not e. g. the date of publication of the described document.
|
| valid e-mail address of administrator (Identify-Verb) | The response for the verb 'Identify' did not specify a valid email address for the repository administrator. (R.A.1-3)
|
| repository description | The reply to the request Identify offers extensive information on the Document and Publication Service. (R.A.1-3)
- This includes especially an administrators valid email address in the element adminEmail and a short description of the service in the element description.
|
| english language used | The reply to the request Identify offers extensive information on the Document and Publication Service. (R.A.1-3)
- This includes especially an administrators valid email address in the element adminEmail and a short description of the service in the element description.
|
| provenance element used | The element provenance is used in the about container for the individual metadata records that are delivered upon the ListRecords or the GetRecord requests. (R.A.1-4)
- Additional information on the metadatas sources can be provided in this container. For more information see http://www. openarchives.org/OAI/2.0/guidelines-provenance.htm.
|
| "open_access" set | A setSpec set exists that states ‘open_access’ and contains all metadata records of Open Access documents. (M.A.2-1)
- Services that offer only Open Access publications must also meet this requirement. In this case the set contains all metadata records.
|
| set structure specifying ddc categories | A structure exists in accordance to table 1, and all metadata records – like the documents – are assigned a setSpec according to the table used. (e.g. 'ddc:004') (M.A.2-2)
- It is possible to assign each record to more than one DDC class.
|
| set structure specifying document type | A structure exists in accordance to table 2, and all metadata records are assigned a setSpec according to the document and publication types. (M.A.2-3)
- As stated in the DINI Recommendation 'Gemeinsames Vokabular für Publikations- und Dokumenttypen' assigning a document to more than one document or publication type is recommended.
|
| set structure specifying the document status | A set structure exists in accordance with Table 3, and all metadata records are assigned a setSpec according to the documents’ statuses in the publication process. (see R.A.2-1)
|
| deletion strategy | One of the values ‘persistent’ or ‘transient’ is selected as Deleting Strategy for the data provider. (M.A.2-4)
- The OAI PMH permits the options ‘no’, ‘persistent’ and ‘transient’. If ‘no’ is selected, no information on deleted documents is transmitted, which can lead to inconsistent data on the service provider’s side.
- If the option ‘transient’ is used for deleted documents the corresponding metadata records have to be available for at least one month after deletion indicating that the document has been deleted.
|
| batch size | The harvest batch size (i. e. the maximum number of data sets in reply to a ListRecords OAI request) is no less than 100 and no more than 500. (R.A.2-2)
- Smaller data packages lead to more requests and increase communication duration and the risk of errors. Larger packages carry the risk of transmission errors.
|
| resumption token life span | The resumption token’s life span is at least 24 hours. (R.A.2-3)
- The attribute lifeSpan describes the time in which the data provider guarantees the continuation of incomplete replies. If this time span is too short it can cause the cancellation of the entire harvesting process as it expires before the previous reply has been delivered completely.
- As problems with the handling of resumption tokens may occur (unanswered follow-up requests) proper functioning should be tested explicitly.
|
| support of metadata format oai_dc | The metadata format oai_dc needs to be supported.
|
| dc:creator element | The Dublin Core formatted metadata sets (oai_dc) contain at least the element 'creator'. (M.A.3-1)
- The element is necessary for a minimal description of elec- tronic academic documents.
|
| dc:title element | The Dublin Core formatted metadata sets (oai_dc) contain at least the element 'title'. (M.A.3-1)
- The element is necessary for a minimal description of elec- tronic academic documents.
|
| dc:date element | The Dublin Core formatted metadata sets (oai_dc) contain at least the element 'date'. (M.A.3-1)
- The element is necessary for a minimal description of electronic academic documents.
|
| dc:type element | The Dublin Core formatted metadata sets (oai_dc) contain at least the element 'type'. (M.A.3-1)
- The element is necessary for a minimal description of electronic academic documents.
|
| dc:identifier element | The Dublin Core formatted metadata sets (oai_dc) contain at least the element 'identifier'. (M.A.3-1)
- The element is necessary for a minimal description of elec- tronic academic documents.
|
| each dc element contains exactly one value | In every used DC element exactly one value is referenced. (M.A.3-2)
- Every DC element can be used multiple times within one metadata set.
- Every author’s name should be listed in a single creator element, every keyword in one single subject element, every URL in a single identifier element, etc.
- This allows a clear separation of the individual elements and the correct indexing.
|
| at least one document type per record | Document or publication types according to the DINI Recommendations Common Vocabulary for Publication and Document Types (Gemeinsames Vokabular für Publikations- und Dokumenttypen) are assigned to all documents. (e.g. 'doc-type:masterThesis') (M.A.3-5)
- The DINI Recommendation supports the listing of a value from the Dublin Core Type Vocabulary in a type element of its own.
|
| at least one ddc category per record | Every record contains at least one DNB subject group in a subject element, and the document is listed in that group. (e.g. 'ddc:004') (M.A.3-6)
|
| dc:language format ISO 639-3 or ISO 639-2 | The language element’s content is listed according to ISO 639-3. (M.A.3-7)
- For German the code is “ger” (ISO 639-2) or “deu” (ISO 639-3), for English it is “eng” in both cases.
|
| date format YYYY-MM-DD | The format for the date field should conform to YYYY-MM-DD, e.g. 2010-12-31 (see M.A.3-8)
|
| dc:date format YYYY-MM-DD | The date element’s content is listed according to ISO 8601. The corresponding format is YYYY-MM-DD. (M.A.3-8)
|
| dc:contributor element | The contributor element is used and contains the name of one person or institution that was involved in the creation of the docu- ment described. (R.A.3-2)
- This may be the referee of a dissertation or the editor of a collection.
|
| dc:source element | The source element follows the Guidelines for Encoding Bibliographic Citation Information in Dublin Core metadata. (R.A.3-3)
- The element is used to name a source of the electronic version.
|
| dc:relation element | The relation element is used to name objects that are related to the document described. (R.A.3-4)
- Relations may be hierarchical structures (isPartOf) or updates (isVersionOf).
|
| dc:subject element | The subject element is used for descriptions of a document’s content. (R.A.3-5)
- In general, the content is described using keywords, or notations from classification schemas.
|
| single occurrence of dc:date | The date element is used only once in a metadata record. (R.A.3-6)
- The publication date is to be preferred over other dates (e. g. upload date or date of creation), as it has the greatest priority for the reader.
|
| dc:format contains common MIME type | The dc:format field should only contain standard MIME types.
|
| dc:rights element | It is recommended to include a statement about various property rights associated with the resource, including intellectual property rights.
|