DINI Check

The DINI validator is a helper tool to validate the conformity of OAIPMH endpoints with the DINI certificate. The results of a validation job will be sent to you via email. The results can be helpful in optimizing an OAI-PMH endpoint (in accordance to the DINI certificate).

With the following form you can specify the OAIPMH endpoint as well as additional validation parameters.

Choose a DINI rule set

Please specify a repository (Help)

Please choose a repository using the dropdown list or specify a valid
repository url using the input field below.

How many records should be checked?

check random recordscheck all records

E-Mail notification

Use the e-mail address displayed on the Identify page of the repository

Show rules

	Rule	Description
	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.