OpenAIRE Guidelines¶

Aim¶

The OpenAIRE Guidelines for Literature Repository Managers 3.0 provide orientation for repository managers to define and implement their local data management policies according to the requirements of the OpenAIRE - Open Access Infrastructure for Research in Europe.

Initially, the requirements of the OpenAIRE infrastructure, and the previous versions of the OpenAIRE Guidelines, were established to support and monitor the implementation of the FP7 OA pilot. However, this version of the Guidelines, according to the expansion of the aims of the OpenAIRE project and infrastructure, has a broader scope. In fact, these guidelines are intended to guide repository manager to expose to the OpenAIRE infrastructure not only EC funded publications, but also other Open Access publications, regardless of their funding.

So, by implementing these Guidelines, repository managers will not only be enabling authors who deposit publications in their repository to fulfill the EC Open Access requirements, and eventually also the requirements of other (national or international) funders with whom OpenAIRE cooperates, but also incorporating their publications into the OpenAIRE infrastructure for discoverability and utilizing value-added services provided by the OpenAIRE portal.

According to the ongoing expansion and anticipating the merger of the DRIVER Guidelines into the context of OpenAIRE Guidelines, detailed content from the DRIVER Guidelines 2.0 was adapted and added into this version of the Guidelines. The OpenAIRE Guidelines for Literature Repository Managers 3.0 are now only a part of a set of OpenAIRE Guidelines that also includes the OpenAIRE Guidelines for Data Archive Managers and the OpenAIRE CERIF-XML profile.

What’s new¶

In comparison with previous versions of the Guidelines, this 3.0 version introduces three main changes:

• The OpenAIRE OAI set has been renamed from ec_fundedresources to openaire.
• New elements for indicating alternative identifiers, relations to other publications (references), and relations to research datasets have been defined.
• The recommendations on how to use the Dublin Core elements have been inherited from the DRIVER Guidelines.

Acknowledgements & Contributors¶

Editors

• Mathias Loesch (Bielefeld University, Germany)
• Eloy Rodrigues (University of Minho, Portugal)
• Pedro Principe (University of Minho, Portugal)
• Jochen Schirrwagen (Bielefeld University, Germany)

Experts & Reviewers

• Jordan Biserkov (Pensoft, Bulgaria)
• Natasa Bulatovic (Max Planck Digital Library, Germany)
• Paolo Manghi (CNR, Italy)
• Natalia Manola (University of Athens, Greece)
• Najla Rettberg (University of Goettingen, Germany)
• Birgit Schmidt (University of Goettingen,Germany)
• Peter Stanchev (Kettering University, USA)

Versions¶

• 3.0, April 2013
• 3.0, beta December 2012
  • The OpenAIRE OAI set has been renamed from ec_fundedresources to openaire.
  • New relation elements for indicating external identifiers, references and connections to datasets.
• 2.0, October 2012 doi:10.5281/zenodo.59208
  • Compatibility for aggregators; extended Namespace for Project Identification
• 1.1, November 2010 doi:10.5281/zenodo.59206
  • Correction of names and references; addition of license and version statement
• 1.0, July 2010 doi:10.5281/zenodo.59204
  • Initial document

Metadata Format¶

OpenAIRE expects metadata to be encoded in the Dublin Core metadata format (metadataPrefix oai_dc). For information on how to use the individual DC fields, please refer to the section “Use of OAI-DC” below.

Compatibility of aggregators¶

Besides individual repositories and journals, also aggregators (e.g., on the national level) can become OpenAIRE compatible. In this case, additional provenance information on the original content providers harvested by the aggregator has to be encoded for OpenAIRE. In accordance with the OAI-PMH guidelines, the provenance information has to be provided in the about element of an OAI record, as displayed in the following example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

 <about>
   <provenance xmlns="http://www.openarchives.org/OAI/2.0/provenance"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/provenance
   http://www.openarchives.org/OAI/2.0/provenance.xsd">
     <originDescription altered="true" harvestDate="2012-09-17T14:58:36Z">
       <baseURL>http://dspace.library.uu.nl:8080/dspace-oai/request</baseURL>
       <identifier>oai:dspace.library.uu.nl:1874/218065</identifier>
       <datestamp>2012-01-19T12:38:56Z</datestamp>
       <metadataNamespace>
         http://www.openarchives.org/OAI/2.0/oai_dc/
       </metadataNamespace>
     </originDescription>
   </provenance>
 </about>

OpenAIRE-specific Syntax for OAI-DC¶

OpenAIRE relies on a specific syntax used in the values of standard Dublin Core metadata fields to identify projects, funders, referenced publications, and datasets. This syntax takes the form of URIs and is defined as the info:eu-repo namespace.

This section explains which DC fields to use together with this syntax to correctly mark up the information relevant for OpenAIRE.

Within OpenAIRE the use of the fields is either:

Within OpenAIRE the use of fields are either:

• Mandatory (M) = the field must always be present in the metadata record. An empty element is not allowed.
• Mandatory when applicable (MA) = when the value of the field can be obtained it must be present in the metadata record.
• Recommended (R) = the use of the field is recommended.
• Optional (O) = the property may be used to provide complementary information about the resource

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

<record>
    <header>
        <identifier>oai:repository.example.com:2003292</identifier>
        <datestamp>2012-11-30T13:40:28Z</datestamp>
        <setSpec>openaire</setSpec>
    </header>
    <metadata>
        <oai_dc:dc
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/
                             http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
            <dc:title>Studies of Unicorn Behaviour</dc:title>
            <dc:identifier>http://repository.example.org/2003292</dc:identifier>
            <dc:creator>Jane, Doe</dc:creator>
            <dc:creator>John, Doe</dc:creator>
            <dc:description>
                Lorem ipsum dolor...
            </dc:description>
            <dc:subject>info:eu-repo/classification/ddc/590</dc:subject>
            <dc:subject>Unicorns</dc:subject>
            <dc:relation>info:eu-repo/grantAgreement/EC/FP7/1234556789/EU//UNICORN</dc:relation>
            <dc:relation>info:eu-repo/semantics/altIdentifier/eissn/1234-5678</dc:relation>
            <dc:relation>info:eu-repo/semantics/altIdentifier/pmid/123456789</dc:relation>
            <dc:relation>info:eu-repo/semantics/altIdentifier/doi/10.1000/182</dc:relation>
            <dc:relation>info:eu-repo/semantics/reference/doi/10.1234/789.1</dc:relation>
            <dc:relation>info:eu-repo/semantics/dataset/doi/10.1234/789.1</dc:relation>
            <dc:rights>info:eu-repo/semantics/openAccess</dc:rights>
            <dc:rights>http://creativecommons.org/licenses/by-sa/2.0/uk/</dc:rights>
            <dc:source>Journal Of Unicorn Research</dc:source>
            <dc:publisher>Unicorn Press</dc:publisher>
            <dc:date>2013</dc:date>
            <dc:type>info:eu-repo/semantics/article</dc:type>
        </oai_dc:dc>
    </metadata>
</record>

DC Field¶

dc:title

Usage¶

Mandatory (M)

Usage Instruction¶

Preserve the original wording, order and spelling of the resource title. Only capitalize proper nouns. Punctuation need not reflect the usage of the original. Subtitles should be separated from the title by a colon. This instruction would result in Title:Subtitle (i.e. no space). If necessary, repeat this element for multiple titles.

Example¶

1

<dc:title>Main title:Subtitle</dc:title>

DC Field¶

dc:creator

Usage¶

Mandatory

Usage Instruction¶

Examples of a Creator include a person, an organization, or a service. If necessary, repeat this element for multiple authors.

Use inverted name, so the syntax will be the following: “surname”, “initials” (“first name”) “prefix”. For example Jan Hubert de Smit becomes

<dc:creator>Smit, J.H. (John) de</dc:creator>

Within the scope of unqualified DC it is recommended to use a standardised writing style for names, use the writing style used by the publisher when this is available. When that is not available use the encoding of the APA bibliographic writing style as in a reference list when applicable. (outside the scope of Unqualified DC more precise and granular formatting methods are available.)

When initials and first name are both available use this formatting:

<dc:creator>Janssen, J. (John)</dc:creator>

Generational suffixes (Jr., Sr., etc.) should follow the surname. When in doubt, give the name as it appears, and do not invert. Omit titles (like “Dr”). For example: “Dr. John H. de Smit Jr.” becomes

<dc:creator>Smit Jr., J.H. (John) de</dc:creator>

In the case of an organization name which clearly includes an organizational hierarchy, list the parts of the hierarchy from largest to smallest, separated by full stops.

For example:

<dc:creator>Utrecht University. Department of Computer Sciences</dc:creator>

If it is not clear whether there is a hierarchy present, or unclear which is the larger or smaller portion of the body, give the name as it appears in the resource. Only encode organisations in this element to indicate corporate authorship, not to indicate the affiliation of an individual.

The inclusion of personal and corporate name headings from authority lists constructed according to local or national thesaurus files is optional.

It is recommended to encode thesauri with an URI, for service providers to recognise the thesaurus schema. For example:

<dc:creator>urn:NationalOrgThesaurus:nl/234</dc:creator>

In cases of lesser responsibility, other than authorship, use dc:contributor. If the nature of the responsibility is ambiguous, recommended best practice is to use dc:publisher for organizations, and dc:creator for individuals.

Do Not Confuse With¶

• Contributor (R)
• Publisher (MA)

Since¶

DRIVER Guidelines v2

Example¶

1
2
3
4
5
6
7
8

<dc:creator>Evans, R.J.</dc:creator>
<dc:creator>Walker Jnr., John</dc:creator>
<dc:creator>
  International Human Genome Sequencing Consortium
</dc:creator>
<dc:creator>
  Loughborough University. Department of Computer Science
</dc:creator>

DC Field¶

dc:relation

Usage¶

Mandatory when applicable

Usage Instruction¶

An authoritative list of projects is exposed by OpenAIRE through OAI-PMH, and available for all repository managers. Values include the project name and project ID. The projectID equals the Grant Agreement identifier, and is defined by the info:eu-repo namespace term grantAgreement.

The syntax is:

info:eu-repo/grantAgreement/Funder/FundingProgram/ProjectID/
[Jurisdiction]/[ProjectName]/[ProjectAcronym]

where:

• Funder refers to the funding organization (e.g., EC for European Commission, WT for Wellcome Trust)
• FundingProgramme refers to a specific programme (e.g., FP7 for Framework Programme Seven, H2020 for Horizon 2020)
• ProjectID refers to a unique identifier in the scope of the funder (and maybe the programme), e.g. a grant agreement number.
• Jurisdiction refers to the authority granted to a formally constituted legal body (e.g. EU for European Union)
• ProjectName contains the full name of the project
• ProjectAcronym contains the project’s acronym.

For OpenAIRE compatibility, the elements in square brackets are optional. The three-part namespace is mandatory when applicable (info:eu-repo/grantAgreement/Funder/FundingProgram/ProjectID), while the six-parts namespace is recommended.

When omitting fields in the extended version, the number of fields must be preserved by using /. A correct example for omitting the the ProjectName field would therefore look like this: EC/FP7/12345/EU//OpenAIREplus

If any of the field values contains a forward slash (/), it needs to be escaped using URL encoding (%2F). For instance, My/Project would be represented as My%2FProject.

Since¶

OpenAIRE Guidelines v1

Example¶

An example utilizing all six fields:

1
2
3

<dc:relation>
  info:eu-repo/grantAgreement/EC/FP7/244909/EU/Making Capabilities Work/WorkAble
</dc:relation>

An example for omitting the the ProjectName field (note that the number of slashes is correctly preserved):

1
2
3

<dc:relation>
  info:eu-repo/grantAgreement/EC/FP7/283595/EU//OpenAIREplus
</dc:relation>

A correct example using the old three-part form (discouraged):

1
2
3

<dc:relation>
  info:eu-repo/grantAgreement/EC/FP7/244909
</dc:relation>

DC Field¶

dc:rights

Usage¶

Mandatory

Usage Instruction¶

Use terms from the info:eu-repo-Access-Terms vocabulary . The values are:

• info:eu-repo/semantics/closedAccess
• info:eu-repo/semantics/embargoedAccess
• info:eu-repo/semantics/restrictedAccess
• info:eu-repo/semantics/openAccess

Example¶

1

<dc:rights>info:eu-repo/semantics/openAccess</dc:rights>

DC Field¶

dc:rights

Usage¶

Recommended

DCMI Definition¶

Information about rights held in and over the resource.

Usage Instruction¶

Typically, a rights element will contain a rights management statement for the access or use of the object, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. It is preferred to refer to a rights service where the reuse rights are made clear to the end-user by using a URL. For example the Creative Commons organisation has created URIs for their different licences in the different jurisdictions. This can be applied to create machine readable usage licenses.

Since¶

OpenAIRE Guidelines v3

Example¶

Generic usage examples:

1
2

<dc:rights>(c) University of Bath, 2003</dc:rights>
<dc:rights>(c) Andrew Smith, 2003</dc:rights>

Using Creative Commons right services, makes the usage rights much more clear to the end user. More information see “Use of Intellectual Property Rights”. In this case Andrew Smith referring to http://creativecommons.org/licenses/by-sa/2.0/uk/

1
2
3
4

<!-- example 1 -->
<dc:rights>
  http://creativecommons.org/licenses/by-sa/2.0/uk/
</dc:rights>

The URL provides the location where the license can be read. With creative common licenses the type of license can be recognized in the URL name itself. A pro for having the license point to an URL in this way, is that this is machine readable.

1
2

<!-- example 2 -->
<dc:rights>cc-by-sa, Andrew Smith</dc:rights>

The string cc-by-sa provides the licence type in a rough sense. The name is the person or party where the rights apply to.

1
2

<!-- example 3 -->
<dc:rights>cc-by-sa, info:eu-repo/dai/nl/344568</dc:rights>

or:

1

<dc:rights>cc-by-nc-sa, urn:isni:234562-2</dc:rights>

Also a Digital Author Identifier (DAI) or International Standard Name Identifier (ISNI) can be used to globally uniquely identify persons and organisations and relate these names with the appropriate rights.

DC Field¶

dc:date

Usage¶

Mandatory when applicable

Usage Instruction¶

When Access Level (M) is set to

• info:eu-repo/semantics/embargoedAccess

the end date of the embargo period must be provided. The corresponding term is defined by

• info:eu-repo/date/embargoEnd/<YYYY-MM-DD>

Encoding of this date should be in the form YYYY-MM-DD conforming to ISO 8601.

Since¶

OpenAIRE Guidelines v1

Example¶

1

<dc:date>info:eu-repo/date/embargoEnd/2015-12-31</dc:date>

DC Field¶

dc:relation

Usage¶

Recommended

Usage Instruction¶

List alternative identifiers for this publication that are not the primary identifier (repository splash page), e.g., the DOI of publisher’s version, the PubMed/arXiv ID. The term is defined by info:eu-repo/semantics/altIdentifier/<scheme>/<identifier> where <scheme> must be one of the following:

• ark – Archival Resource Key
• arxiv – arXiv.org identifier
• doi – Digital Object Identifier
• hdl – Handle
• isbn – International Standard Book Number
• pissn – International Standard Serial Number (print version)
• eissn – International Standard Serial Number (electronic Version)
• pmid – PubMed ID
• purl – Persistent Uniform Resource Locator
• urn – Uniform Resource Name
• wos – Web of Science accession number

Since¶

OpenAIRE Guidelines v3

Example¶

1
2
3

<dc:relation>
  info:eu-repo/semantics/altIdentifier/doi/10.1234/789.1
</dc:relation>

DC Field¶

dc:relation

Usage¶

Recommended

Usage Instruction¶

Encode links to publications referenced by this publication. The syntax is: info:eu-repo/semantics/reference/<scheme>/<identifier> where <scheme> must be one of the following:

• ark – Archival Resource Key
• arxiv – arXiv.org identifier
• doi – Digital Object Identifier
• hdl – Handle
• isbn – International Standard Book Number
• issn – International Standard Serial Number
• pmid – PubMed ID
• purl – Persistent Uniform Resource Locator
• url – Uniform Resource Locator
• urn – Uniform Resource Name
• wos – Web of Science accession number

Since¶

OpenAIRE Guidelines v3

Example¶

1
2
3

<dc:relation>
  info:eu-repo/semantics/reference/doi/10.1234/789.1
</dc:relation>

DC Field¶

dc:relation

Usage¶

Recommended

Usage Instruction¶

Encodes links to research datasets connected with this publication. The syntax is: info:eu-repo/semantics/dataset/<scheme>/<identifier> where <scheme> must be one of the following:

• ark – Archival Resource Key
• doi – Digital Object Identifier
• hdl – Handle
• purl – Persistent Uniform Resource Locator
• url – Uniform Resource Locator
• urn – Uniform Resource Name

Since¶

OpenAIRE Guidelines v3

Example¶

1
2
3

<dc:relation>
  info:eu-repo/semantics/dataset/doi/10.1234/789.1
</dc:relation>

DC Field¶

dc:subject

Usage¶

Mandatory when applicable (MA)

Usage Instruction¶

In the DC subject element two kinds of values are possible: encode either a keyword or a classification. When both are available use separate occurrences of this element.

Use the first occurrence of the DC element subject for a human readable keyword.

In general, choose the most significant and unique words for keywords, avoiding those too general to describe a particular resource. If the subject of the resource is a person or an organization, use the same form of the name as you would if the person or organization were an author, but do not repeat the name in the dc:creator element.

For keywords/keyphrases that are not controlled by a vocabulary or thesaurus either encode multiple terms with a semi-colon separating each keyword/keyphrase; or repeat the element for each term. There are no requirements regarding the capitalization of keywords though internal (within archive) consistency is recommended.

Where terms are taken from a standard classification schema: encode each term in a separate element. Encode the complete subject descriptor according to the relevant scheme. Use the capitalisation and punctuation used in the original scheme.

It is recommended to use an URI when using classification schemes or controlled vocabularies especially when codified schemes are used DDC or UDC. Service providers can recognise encoding schemas more easy when the schema is “URI-fied” by an authority namespace. When the classification scheme is codified, use a human readable text of the code, preferably in English, directly below the codified element. For example:

1
2

<dc:subject>info:eu-repo/classification/ddc/641</dc:subject>
<dc:subject>Anatomy</dc:subject>

If no specific classification scheme is use we recommend the Dewey Decimal Classification Decimal Classification (DDC). The first 1000 terms is called the Dewey Decimal Classification Summary and can be downloaded at http://www.oclc.org/dewey/resources/summaries/ if one agrees with the following terms and conditions: http://www.oclc.org/research/researchworks/ddc/terms.htm

Do Not Confuse With¶

• Publication Type (M)

Since¶

DRIVER Guidelines v2

Example¶

1
2
3
4
5
6
7

<dc:subject>
  polar oceanography; boundary current; masstransport; water masses;
  halocline; mesoscaleeddies
</dc:subject>
<dc:subject>Germany--History--1933-1945</dc:subject>
<dc:subject>info:eu-repo/classification/ddc/641</dc:subject>
<dc:subject>Anatomy</dc:subject>

DC Field¶

dc:description

Usage¶

Mandatory when applicable

Usage Instruction¶

This element is used for a textual description of the content. When a resource consists of several separate physical object files, do not use dc:description to list the URLs of these files.

Since¶

DRIVER Guidelines v2

Example¶

1
2
3
4
5
6
7
8
9

<dc:description>
  Foreword [by] Hazel Anderson; Introduction; The scientific heresy:
  transformation of a society; Consciousness as causal reality [etc]
</dc:description>

<dc:description>
  A number of problems in quantum state and system identification are
  addressed.
</dc:description>

DC Field¶

dc:publisher

Usage¶

Mandatory when applicable

DCMI Definition¶

An entity responsible for making the resource available. Examples of a Publisher include a person, an organization, or a service. Typically, the name of a Publisher should be used to indicate the entity.

Usage Instruction¶

The (commercial or non-commercial) publisher of the resource; not the (sub)institution the author is affiliated with. Publisher is used only in the bibliographic / functional sense, not an organisational one. Use only the full name of the given (commercial) publisher, not the name of an organization or institute that is otherwise [in a broader sense] associated with the creator.

With university publications place the name of the faculty and/or research group or research school after the name of the university. In the case of organizations where there is clearly a hierarchy present, list the parts of the hierarchy from largest to smallest, separated by full stops. If it is not clear whether there is a hierarchy present, or unclear which is the larger or smaller portion of the body, give the name as it appears in the eprint.

The use of publisher names from authority lists constructed according to local or national thesaurus files is optional.

Do Not Confuse With¶

• Contributor (R)
• Creator (M)

In most cases the publisher and the creator are not the same.

Since¶

DRIVER Guidelines v2

Example¶

1
2
3
4

<dc:publisher>
  Loughborough University. Department of Computer Science
</dc:publisher>
<dc:publisher>John Wiley &amp; Sons, Inc. (US)</dc:publisher>

DC Field¶

dc:contributor

Usage¶

Recommended

DCMI Definition¶

An entity responsible for making contributions to the content of the resource. Examples of a Contributor include a person, an organization, or a service. Typically, the name of a Contributor should be used to indicate the entity.

Usage Instruction¶

Examples of contributors are: a supervisor, editor, technician or data collector.

Personal names should be listed as: see instructions under Creator. A “promotor”, i.e. a professor supervising a student’s work for a doctor’s degree - is considered a contributor of a dissertation in his or her role as promotor/examiner. In less-rich Unqualified DC it is difficult to express all roles in different contexts. In the PhD thesis as a document, the key figures are the author and the supervisor. In the overall PhD process other roles are involved, such as committee members and the Master of Ceremonies, but in Unqualified these roles have to be sacrificed.

In the case of organizations : see instructions under Creator The inclusion of personal and corporate name headings from authority lists constructed according to local or national thesaurus files is optional.

Do Not Confuse With¶

• Publisher (MA)
• Creator (M)

The DC element contributor describes the scientist(s) that has/have made contributions to the given scientific output, not as a primary creator or (commercial) publisher.

Since¶

DRIVER Guidelines v2

Example¶

1
2
3
4

<dc:contributor>Evans, R. J.</dc:contributor>
<dc:contributor>
  International Human Genome Sequencing Consortium
</dc:contributor>

DC Field¶

dc:date

Usage¶

Mandatory

DCMI Definition¶

A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format.

Usage Instruction¶

The date should be formatted according to the W3C encoding rules for dates and times:

Complete date:

YYYY-MM-DD (e.g. 1997-07-16)

where:

• YYYY [four-digit year] is ‘’mandatory’‘
• MM [two-digit month (01=January, etc.)] is ‘’optional’‘
• DD [two-digit day of month (01 through 31)] is ‘’optional’‘

One date field – Date of Publication:

Often repository systems have more then one date fields that serve different purposes. Date of creation, publication, modified, promotion, etc. Unqualified DC is unable to express all these dates, and for the end-user perspective it is confusing to receive more dates from the service provider. The service provider should make a choice what date- field to pick. Preferably in the end-users perspective the most logical and meaningful date will be the date of publication. To reduce the ambiguity of having a number of date fields without qualifiers, we recommend to reduce the number of fields and present the most meaningful date to the service provider. In most cases this is the date of the publication. In other cases this is the date of promotion of a PhD degree.

No date of publication available:

If no date of publication is available, use any other date available. It is better to use one date than no date at all.

Datestamp additions:

Additions like “Zulu time” should NOT be part of the metadata.

Fuzzy dates:

For fuzzy dates use a logical year that most represents that period, e.g. 1650 instead of 17th century.

To express more about that temporal period, one can use the dc:coverage field. A temporal period can be expressed in a standard way when precisely defined (see Coverage (R)) or when “fuzzy” or uncertain by free text expressions. A service provider is able to sort dates based on date standards like W3CDTF. Since there is no standard for fuzzy dates for terms like “Renaissance” or “17th Century”, they will simply not appear on date-based query results.

Since¶

DRIVER Guidelines v2

Example¶

1
2
3

<dc:date>2000-12-25</dc:date>
<dc:date>1978-02</dc:date>
<dc:date>1650</dc:date>

DC Field¶

dc:type

Usage¶

Publication type is used for the following purposes:

• Mandatory (M): Publication type (controlled): to indicate the type of publication based on the info:eu-repo-publication-type-terms vocabulary.
• Optional (O): Publication type (free): to indicate the type of publication based on a local repository vocabulary.

DCMI Definition¶

The type of scientific output the resource is a manifestation of. In the DC element type the kind of dissemination, or the intellectual and/or content type of the resource is described. It is used to explain to the user what kind of resource he is looking at. Is it a book or an article. Was it written for internal or external use, etc.

Usage Instruction¶

Publication types (controlled):

The first occurrence of the DC Element type is mandatory and should be used for the type indication of the scientific output based on the info:eu-repo publication type vocabulary:

• info:eu-repo/semantics/article
• info:eu-repo/semantics/bachelorThesis
• info:eu-repo/semantics/masterThesis
• info:eu-repo/semantics/doctoralThesis
• info:eu-repo/semantics/book
• info:eu-repo/semantics/bookPart
• info:eu-repo/semantics/review
• info:eu-repo/semantics/conferenceObject
• info:eu-repo/semantics/lecture
• info:eu-repo/semantics/workingPaper
• info:eu-repo/semantics/preprint
• info:eu-repo/semantics/report
• info:eu-repo/semantics/annotation
• info:eu-repo/semantics/contributionToPeriodical
• info:eu-repo/semantics/patent
• info:eu-repo/semantics/other

Publication types (free text):

The second occurrence of the DC Element type is optional and should be used for the subtype indication of the scientific output.

Do Not Confuse With¶

• Format (R)

DC element type describes the kind of academic output the resource is a representation of. DC element ‘format’ describes the media type of this resource.

Since¶

DRIVER Guidelines v2

Example¶

1

<dc:type>info:eu-repo/semantics/article</dc:type>

DC Field¶

dc:type

Usage¶

Recommended: Version (controlled): to indicate the status in the publication process.

DCMI Definition¶

Usage Instruction¶

Version (controlled):

be used for the version of the scientific output based on the DRIVER-version info:eu-repo version terms. vocabulary. Use exact text as shown in the list below. For more information about the version model see http://www.lse.ac.uk/library/versions/.

• info:eu-repo/semantics/draft
• info:eu-repo/semantics/submittedVersion
• info:eu-repo/semantics/acceptedVersion
• info:eu-repo/semantics/publishedVersion
• info:eu-repo/semantics/updatedVersion

Since¶

DRIVER Guidelines v2

Example¶

1

<dc:type>info:eu-repo/semantics/publishedVersion</dc:type>

DC Field¶

dc:format

Usage¶

Recommended

DCMI Definition¶

The physical or digital manifestation of the resource. Typically, Format may include the media-type or dimensions of the resource. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource. Examples of dimensions include size and duration. Recommended best practice is to select a value from a controlled vocabulary (for example, the list of Internet Media Types [MIME] defining computer media formats).

Usage Instruction¶

Based on best practice, the IANA registered list of Internet Media Types (MIME types) is used to select a term from. For the full list see http://www.iana.org/assignments/media-types

If one specific resource (an instance of scientific output) has more than one physical formats (e.g. postscript and pdf) stored as different object files, all formats are mentioned in the DC element format, for example:

• <dc:format>application/pdf</dc:format>
• <dc:format>application/postscript</dc:format>
• <dc:format>application/vnd.oasis.opendocument.text</dc:format>

Do Not Confuse With¶

• Publication Type (M)
• Resource Identifier (M)

DC element format describes the media type of this resource. DC element type describes the kind of academic output the resource is a representation of. dc:identifier is used to represent manifestations of digital resources.

Since¶

DRIVER Guidelines v2

Example¶

1
2
3
4
5
6

<dc:format>video/quicktime</dc:format>
<dc:format>application/pdf</dc:format>
<dc:format>application/xml</dc:format>
<dc:format>application/xhtml+xml</dc:format>
<dc:format>application/html</dc:format>
<dc:format>application/vnd.oasis.opendocument.text</dc:format>

DC Field¶

dc:identifier

Usage¶

Mandatory

DCMI Definition¶

An unambiguous reference to the resource within a given context.

Usage Instruction¶

Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Example formal identification systems include the Uniform Resource Identifier (URI), the Uniform Resource Locator (URL), the Digital Object Identifier (DOI), and the URN:NBN.

The ideal use of this element is to use a direct link or a link to a jump-off page (persistent URL) from dc:identifier in the metadata record to the digital resource or a jump-off page.

Smart practice:

• use stable URL’s
• provide every identifier one can find about the publication.
  • (URL,DOI,URN:NBN,ISBN,ISSN,etc.)
• place the “most appropriate” identifier in the form of a URL at the top of the list of Identifiers. In almost all cases this is the one that will be used by a service provider to let an end-user refer to. This can be a link to a jump-off page or a direct link to the file. Also this can be a direct URL, or a redirection URL, like PURL, HANDLE or other international resolution mechanisms.

Do Not Confuse With¶

• Relation (O) (Use dc:relation to refer from one version of the resource to another.)
• Source (R) (Use dc:source for bibliographic citation of the originating resource.)

Since¶

DRIVER Guidelines v2

Example¶

In this example the identifiers are sorted so that URLs are given first. The first URL will be considered as “most appropriate” and will be used in e.g. OpenAIRE to let an end-user redirect to. In this case the handle redirects to the jump-off page. A jump-off page is a good way to refer to. The end-user has the opportunity to see more information about the object(s) he has found, see the context and enjoy the other services a local repository has to offer:

1
2
3
4
5
6

<dc:identifier>http://hdl.handle.net/1234/5628 </dc:identifier>
<dc:identifier>http://arno.unimaas.nl/show.cgi?fid=5628 </dc:identifier>
<dc:identifier>http://n2t.info/urn:nbn:nl:ui:14123456789</dc:identifier>
<dc:identifier>urn:nbn:nl:ui:13-123456789</dc:identifier>
<dc:identifier>urn:isbn:123456789</dc:identifier>
<dc:identifier>info:doi:10-123456789</dc:identifier>

DC Field¶

dc:source

Usage¶

Recommended

DCMI Definition¶

A reference to a resource from which the present resource is derived.

Usage Instruction¶

The present resource may be derived from the Source resource in whole or in part. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.

Best practice: Use only when the described resource is the result of digitization of non-digital originals. Otherwise, use Relation. Optionally metadata about the current location and call number of the digitized publication can be added.

Use: Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata (http://dublincore.org/documents/dc-citation-guidelines/).

Do Not Confuse With¶

• Relation (O)
• Resource Identifier (M)

Since¶

DRIVER Guidelines v2

Example¶

1
2

<dc:source>Ecology  Letters (1461023X)  vol.4 (2001)</dc:source>
<dc:source>ISSN: 0928-0987</dc:source>

DC Field¶

dc:language

Usage¶

Recommended

DCMI Definition¶

A language of the intellectual content of the resource.

Usage Instruction¶

A specific resource (an instance of scientific output) is either written in one human language or more. In these cases all used languages are used in the DC element language. If a specific resource (an instance of scientific output) is written in one human language and is translated into other human languages, each translation does have its own record..

Recommended: ISO 639-x, where x can be 1,2 or 3. Best Practice: we use ISO 639-3 and by doing so we follow: http://www.sil.org/iso639-3/

If necessary, repeat this element to indicate multiple languages.

If ISO 639-2 and 639-1 are sufficient for the contents of a repository they can be used alternatively. Since there is a unique mapping this can be done during an aggregation process.

Do Not Confuse With¶

• Country codes (ISO 3166-1)

Since¶

DRIVER Guidelines v2

Example¶

1
2
3
4
5
6

<dc:language>eng</dc:language>
<dc:language>deu</dc:language>
<dc:language>nld</dc:language>
<dc:language>nld/dut</dc:language>
<dc:language>dut</dc:language>
<dc:language>nl</dc:language>

DC Field¶

dc:relation

Usage¶

Optional

DCMI Definition¶

The reference to a related resource.

Usage Instruction¶

For OpenAIRE-specific use, see sections on Project Identifier (MA), Alternative Identifier (R), Publication Reference (R), and Dataset Reference (R).

Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system. The DC element relation can be used to indicate different kinds of relations between several metadata records. If relations between metadata records are made visible by using metadata the following holds for the distinction between versions (author version and publisher version, preprint, postprint, etc.):

• A metadata record is self-contained
• Different manifestations of one and the same resource (an instance of scientific output that can be described with exactly the same bibliographic metadata, except for the DC element format) are linked to one single metadata record using dc:relation.

Changes in the metadata other than the DC element format leads to creating a new metadata record of this new instance of scientific output which meets all requirements formulated in this document and has a value in the DC element relation.

Do Not Confuse With¶

• Resource Identifier (M)
• Source (R)

Since¶

DRIVER Guidelines v2

Example¶

Generic use:

1

<dc:relation>http://hdl.handle.net/10</dc:relation>

The value of dc:relation is the identifier of the other document.

Linking two documents:

1
2
3
4

<!-- Document A -->
<dc:type>info:eu-repo/semantics/submittedVersion</dc:type>
<dc:identifier> http://hdl.handle.net/10</dc:identifier>
<dc:relation>http://hdl.handle.net/20</dc:relation>

1
2
3
4

<!-- Document B -->
<dc:type>info:eu-repo/semantics/acceptedVersion</dc:type>
<dc:identifier> http://hdl.handle.net/20</dc:identifier>
<dc:relation>http://hdl.handle.net/10</dc:relation>

DC Field¶

dc:coverage

Usage¶

Recommended

DCMI Definition¶

The extent or scope of the content of the resource. Coverage will typically include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity).

Usage Instruction¶

Recommended best practice is to select the value from a controlled vocabulary (for example, the Getty Thesaurus of Geographic Names or TGN) and that, where appropriate, named places or time periods be used in preference to numeric identifiers as, for example, sets of coordinates or date ranges. If necessary, repeat this element to encode multiple locations or periods.

Since¶

DRIVER Guidelines v2

Example¶

Example Spatial: ISO 3166:

1

<dc:coverage>NL</dc:coverage>

Example Spatial: BOX:

1
2
3
4

<dc:coverage>
  name=Western Australia; northlimit=-13.5; southlimit=-35.5;
  westlimit=112.5; eastlimit=129
</dc:coverage>

DC Field¶

dc:audience

Usage¶

Recommended

DCMI Definition¶

A class of entity for whom the resource is intended or useful.

Usage Instruction¶

A class of entity may be determined by the creator or the publisher or by a third party. On the U.S. Department of Education, Metadata Reference site, an example is given of audiences: http://www.ed.gov/admin/reference/index.jsp :

• Administrators
• Community Groups
• Counsellors
• Federal Funds Recipients and Applicants
• Librarians
• News Media
• Other
• Parents and Families
• Policymakers
• Researchers
• School Support Staff
• Student Financial Aid Providers
• Students
• Teachers

Since¶

DRIVER Guidelines v2

Example¶

1
2

<dc:audience>Researchers</dc:audience>
<dc:audience>Students</dc:audience>

Aim¶

OpenAIRE gathers together research output related to European funding streams, with the aim of supporting open science and tracking research impact. This content consists of open access publications and related contextual information such as datasets, supplementary material, and research/project information.

Two other sets of OpenAIRE guidelines exist for repository managers:

• OpenAIRE Guidelines for Literature Repositories
• OpenAIRE Guidelines for CRIS Managers based on CERIF-XML

The OpenAIRE Guidelines for Data Archive Managers 2.0 will provide instruction for data archive managers to expose their metadata in a way that is compatible with the OpenAIRE infrastructure. The metadata from data archives should be included in the OpenAIRE information space, and exposed when data are related to an open access publication e.g. a dataset cited by an article. To access a pdf version the guidelines see here: http://dx.doi.org/10.5281/zenodo.6918

By implementing the OpenAIRE Guidelines, data archive managers are facilitating the creation of enhanced publications and building the stepping-stones for a linked data infrastructure for research.

Exposure and visibility of content from a range of European repositories will be significantly increased when a common and interoperable approach is taken as well as adhering to existing guidelines. OpenAIRE is happy to assist in adherence to these guidelines. This compatibility will lead to future interoperability between research infrastructures, and structured metadata is of benefit to individual data repositories and the scholarly community at large.

Acknowledgements & Contributors¶

Editors

• Mikael K. Elbæk (Technical University of Denmark)
• Lars Holm Nielsen (CERN, Switzerland)

Experts & Reviewers

• Samuele Kaplun (CERN, Switzerland)
• Paolo Manghi (CNR, Italy)
• Natalia Manola (University of Athens, Greece)
• Jochen Schirrwagen (University of Bielefeld, Germany)
• Birgit Schmidt (University of Goettingen,Germany)
• Mathias Lösch (University of Bielefeld, Germany)
• Frauke Ziedorn (DataCite, Germany)
• Pedro Principe (University of Minho, Portugal)
• Eloy Rodrigues (University of Minho, Portugal)
• Najla Rettberg (University of Goettingen, Germany)

Versions¶

• 2.0 April 2014
  • Updated to DataCite Metadata Schema v3.0
• 1.0 December 2012
  • Initial document

Metadata Format¶

OpenAIRE expects metadata to be encoded in the DataCite metadata format (metadataPrefix oai_datacite) . For information on how to use the individual DataCite properties, please refer to Application Profile Overview.

OpenAIRE OAI Set¶

A specific OAI-Set at the local repository should be configured to select records relevant to OpenAIRE for harvesting. The following characteristics of the set are recommended:

Set content¶

The specific content of the openaire_data set is to be determined at the local repository. OpenAIRE will harvest all datasets from the openaire_data set, but will only expose datasets fulfilling at least one of the following criteria in the OpenAIRE portal:

• The dataset is outcome of a funded research project identified by a project identifier (see section “Funding information” above).
• The dataset is linked with a publication in the OpenAIRE information space (see section “Related publications and datasets information” above).

Both criteria above may be automatically inferred by the OpenAIRE infrastructure.

Specifically a data repository may insert a dataset without funding information or link to a related publication in the openaire_data set. If later a publication harvested from a literature repository links to the dataset, the dataset will be exposed in the OpenAIRE portal. If either the literature repository or the data repository explicitly links the publication and dataset (see section ”Related publications and datasets information”), the dataset will normally be exposed in the OpenAIRE portal within 1-2 days after harvesting (repositories are harvested on average once a week). If the OpenAIRE infrastructure automatically has to infer the link between the publication and the dataset, it may take up to a month after harvesting before the dataset is exposed in the OpenAIRE portal.

What’s different¶

In this document you will find the needed properties to make your data archive compatible with the OpenAIRE infrastructure. OpenAIRE has adopted the DataCite Metadata Schema v3.1 with some minor adjustments.

• OpenAIRE accepts other persistent identifier schemes and not only a DOI in 1.1 identifierType (M).
• OpenAIRE recommends exporting links to related publications and datasets (i.e. 12. RelatedIdentifier (MA) property and attributes are mandatory when applicable).
• OpenAIRE recommends using the 7. Contributor (MA/O) property to relate a dataset to funding information.
• DataCite optional properties 8. Date (M) and 17. Description (MA) are mandatory in OpenAIRE.
• OpenAIRE enforces an encoding scheme on DataCite property 16. Rights (MA).

Access rights and license information¶

OpenAIRE uses the access rights to enable a better user experience by declaring the access rights clear and explicit in the portal. Access rights are specified using the 16. Rights (MA) property. Please see example of encoding scheme in the section above.

An example:

1
2
3

<rightsList>
  <rights rightsURI=”info:eu-repo/semantics/openAccess” />
</rightsList>

OpenAIRE further recommends including license information if available:

1
2
3
4
5
6

<rightsList>
  <rights rightsURI=”info:eu-repo/semantics/openAccess” />
  <rights rightsURI=”http://creativecommons.org/licenses/by/4.0/”>
    Creative Commons Attribution 4.0 International
  </rights>
</rightsList>

Funding information¶

OpenAIRE have a specific use of the 7. Contributor (MA/O) property to identify links to funding steams.

One of OpenAIRE’s main goals is to link research output to (EC) research funding. The following application of the contributor property allows unique and persistent identification of the funder who has funded wholly or partly the dataset described.

The following properties are mandatory when applicable to provide funding information: 7. Contributor (MA/O), 7.1 contributorType (MA/O), 7.2 contributorName (MA/O), 7.3 nameIdentifier (MA/O) and 7.3.1 nameIdentifierScheme (MA/O).

An example for linking a research output to the OpenAIREplus FP7 project:

1
2
3
4
5
6

 <contributor contributorType="Funder">
   <contributorName>European Commission</contributorName>
     <nameIdentifier nameIdentifierScheme="info">
       info:eu-repo/grantAgreement/EC/FP7/282896
   </nameIdentifier>
 </contributor>

Related publications and datasets information¶

OpenAIRE harvests all datasets from a data repository, but exposes only certain datasets in the OpenAIRE portal. See the Set content for specific details of which datasets are exposed.

For example, datasets related to publication will be exposed in the OpenAIRE portal. The link between the dataset and publication may be explicit defined, as described in this section, or automatically inferred by the OpenAIRE infrastructure.

If the link is explicit defined, the dataset will be exposed in the OpenAIRE portal within 1-2 days after harvesting (a repository is harvested once a week on average). If the link is automatically inferred by the OpenAIRE infrastructure it may take up to a month after harvesting before the dataset is exposed in the OpenAIRE portal. It is thus mandatory when applicable to provide links to related publications and datasets when these links are available in the repository, and thereby ensure faster exposure of the dataset in the OpenAIRE portal.

1
2
3
4
5

<relatedIdentifier
  relatedIdentifierType="DOI"
  relationType="IsCitedBy">
 10.1234/bar
</relatedIdentifier>

Embargo date information¶

For OpenAIRE two main types of dates are relevant. When the data were made available, published or uploaded to a formal database, this is the date the data were ‘’Issued’‘.

Sometimes data may be embargoed for a period; this information should be managed by the data provider and expressed by exporting an ‘’Available’’ date to indicate the end of an embargo period and an ‘’Accepted’’ date to indicate the start of an embargo period.

An example:

1
2
3

<dates>
 <date dateType="Issued">2005-04-05</date>
</dates>

An embargo example:

1
2
3
4

<dates>
 <date dateType="Accepted">2011-12-01</date>
 <date dateType="Available">2012-12-01</date>
</dates>

1.1 identifierType (M)¶

The type of the Identifier (occurrences: 1).

Allowed values, examples, other constraints

Controlled list values (DataCite)

• DOI

Controlled list values (OpenAIRE)

• ARK
• DOI
• Handle
• PURL
• URN
• URL

Example¶

1
2
3

<identifier identifierType="DOI">
 10.1594/WDCC/CCSRNIES_SRES_B2
</identifier>

2.1 creatorName (M)¶

The name of the creator (occurrences: 1).

Allowed values, examples, other constraints

Examples: Smith, John; Miller, Elizabeth

The personal name format should be: family, given. Non-roman names may be transliterated according to the ALA-LC schemes.

2.2 nameIdentifier (R)¶

Uniquely identifies an individual or legal entity, according to various schemes (occurrences: 0-1).

Allowed values, examples, other constraints

The format is dependent upon scheme.

2.3 affiliation (R)¶

The organizational or institutional affiliation of the creator (occurrences: 0-n).

Allowed values, examples, other constraints

Free text.

Example¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<creators>
 <creator>
  <creatorName>Miller, John</creatorName>
 </creator>
 <creator>
  <creatorName>Smith, Jane</creatorName>
  <affiliation>OpenAIRE</affiliation>
  <nameIdentifier nameIdentifierScheme="ISNI"
                  schemeURI="http://www.isni.org">
   1422 4586 3573 0476
  </nameIdentifier>
 </creator>
</creators>

3. titleType (O)¶

The type of Title (occurrences: 0-1).

Allowed values, examples, other constraints

Controlled List Values:

• Alternative Title
• Subtitle
• TranslatedTitle

1
2
3
4
5
6
7

<titles>
 <title>
  National Institute for Environmental Studies and Center
  for Climate System Research Japan
 </title>
 <title titleType="Subtitle">A survey</title>
</titles>

Example¶

1

<publisher>World Data Center for Climate (WDCC)</publisher>

Additional guidance¶

The year when the data was or will be made publicly available. In the case of datasets, “publish” is understood to mean making the data available on a specific date to the community of researchers.

• If that date cannot be determined, use the date of registration.
• If an embargo period has been in effect, use the date when the embargo period ends.
• If there is no standard publication year value, use the date that would be preferred from a citation perspective.

In the case of a digitized version of a physical object

If the DOI is being used to identify a digitised version of an original item, the recommended approach is to supply the 5. PublicationYear (M) for the digital version and not the original object.

The 3. Title (M) field may be used to convey the approximate or known date of the original object. Other metadata properties available for additional date information about the object include: 6. Subject (R) and 17. Description (MA). However, only 3. Title (M) will be part of the citation.

If the DOI is being used to identify the original object and the publication date of this is unknown or not standard then we recommend the following:

• Use the date that would be preferred from a citation perspective.

Example¶

1

<publicationYear>2004</publicationYear>

6.1 subjectScheme (O)¶

The name of the subject scheme or classification code or authority if one is used (occurrences: 01).

Allowed values, examples, other constraints

Free text.

6.2 schemeURI (O)¶

The URI of the subject identifier scheme (occurrences: 0-1).

Allowed values, examples, other constraints

Examples:

• http://id.loc.gov/authorities/subjects
• http://dewey.info/

Example¶

1
2
3
4
5
6

<subjects>
 <subject>Earth sciences and geology</subject>
 <subject subjectScheme="DDC" schemeURI="http://dewey.info/">
 551 Geology, hydrology, meteorology
 </subject>
</subjects>

7.1 contributorType (MA/O)¶

The type of contributor of the resource (occurrences: 1).

Allowed values, examples, other constraints

If 7. Contributor (MA/O) is used, then 7.1 contributorType (MA/O) is mandatory.

Controlled List Values:

• ContactPerson
• DataCollector
• DataCurator
• DataManager
• Distributor
• Editor
• Funder
• HostingInstitution
• Producer
• ProjectLeader
• ProjectManager
• ProjectMember
• RegistrationAgency
• RegistrationAuthority
• RelatedPerson
• Researcher
• ResearchGroup
• RightsHolder
• Sponsor
• Supervisor
• WorkPackageLeader
• Other

7.2 contributorName (MA/O)¶

The name of the contributor (occurrences: 1).

Allowed values, examples, other constraints

If 7. Contributor (MA/O) is used, then 7.2 contributorName (MA/O) is mandatory.

Examples: Patel, Emily; Doe, John

The personal name format may be: family, given. Non-roman names should be transliterated according to the ALA-LC schemes.

7.3 nameIdentifier (MA/O)¶

Uniquely identifies an individual or legal entity, according to various schemes (occurrences: 0-1).

Allowed values, examples, other constraints

The format is dependent upon scheme.

info:eu-repo/grantAgreement/Funder/FundingProgram/ProjectID/
[Jurisdiction]/[ProjectName]/[ProjectAcronym]

7.3.1 nameIdentifierScheme (MA/O)¶

The name of the name identifier scheme (occurrences: 1).

Allowed values, examples, other constraints

If 7.3 nameIdentifier (MA/O) is used, 7.3.1 nameIdentifierScheme (MA/O) is mandatory.

Examples:ORCID, ISNI, FundRef.

7.3.2 schemeURI (O)¶

The URI of the name identifier scheme (occurrences: 0-1).

Allowed values, examples, other constraints

Examples:

• http://www.isni.org
• http://orcid.org
• http://www.crossref.org/fundref/

7.4 affiliation (O)¶

The organizational or institutional affiliation of the contributor (occurrences: 0-n).

Allowed values, examples, other constraints

Free text.

Example¶

1
2
3
4
5
6

 <contributor contributorType="Funder">
   <contributorName>European Commission</contributorName>
     <nameIdentifier nameIdentifierScheme="info">
       info:eu-repo/grantAgreement/EC/FP7/282896
   </nameIdentifier>
 </contributor>

8.1 dateType (M)¶

The type of date (occurrences: 1).

Allowed values, examples, other constraints

If Date is used, dateType is mandatory.

Controlled List Values:

• Accepted
• Available
• Copyrighted
• Collected
• Created
• Issued
• Submitted
• Updated
• Valid

Example¶

An example:

1
2
3

<dates>
 <date dateType="Issued">2005-04-05</date>
</dates>

An embargo example:

1
2
3
4

<dates>
 <date dateType="Accepted">2011-12-01</date>
 <date dateType="Available">2012-12-01</date>
</dates>

Example¶

1

<language>eng</language>

10.1 resourceTypeGeneral (R)¶

The general type of a resource (occurrences: 1).

Allowed values, examples, other constraints

If ResourceType is used, resourceTypeGeneral is mandatory.

Controlled List Values:

• Audiovisual
• Collection
• Dataset
• Event
• Image
• InteractiveResource
• Model
• PhysicalObject
• Service
• Software
• Sound
• Text
• Workflow
• Other

Combine “Text” with free-text or terms from the CASRAI Publications resource type list found here.

Example¶

1

<resourceType resourceTypeGeneral="Image">Animation</resourceType>

11.1 alternateIdentifierType (O)¶

The type of the AlternateIdentifier (occurrences: 1).

Allowed values, examples, other constraints

Free text.

If AlternateIdentifier is used, alternateIdentifierType is mandatory. For the above example, the alternateIdentifierType would be A local accession number.

Example¶

1
2
3
4
5

<alternateIdentifiers>
 <alternateIdentifier alternateIdentifierType="ISBN">
     937-0-1234-56789-X
 </alternateIdentifier>
</alternateIdentifiers>

12.1 relatedIdentifierType (M)¶

The type of the RelatedIdentifier (occurrences: 1).

Allowed values, examples, other constraints

If 12. RelatedIdentifier (MA) is used, 12.1 relatedIdentifierType (M) is mandatory.

Controlled List Values:

• ARK
• arXiv
• bibcode
• DOI
• EAN13
• EISSN
• Handle
• ISBN
• ISSN
• ISTC
• LISSN
• LSID
• PMID
• PURL
• UPC
• URL
• URN

12.2 relationType (M)¶

Description of the relationship of the resource being registered (A) and the related resource (B) (occurrences: 1).

Allowed values, examples, other constraints

If 12. RelatedIdentifier (MA) is used, 12.2 relationType (M) is mandatory.

Controlled List Values:

• IsCitedBy (indicates that B includes A in a citation)
• Cites (indicates that A includes B in a citation)
• IsSupplementTo (indicates that A is a supplement to B)
• IsSupplementedBy (indicates that B is a supplement to A)
• IsContinuedBy (indicates A is continued by the work B)
• Continues (indicates A is a continuation of the work B)
• HasMetadata (indicates resource A has additional metadata B)
• IsMetadataFor (indicates additional metadata A for a resource B)
• IsNewVersionOf (indicates A is a new edition of B, where the new edition has been modified or updated)
• IsPreviousVersionOf (indicates A is a previous edition of B)
• IsPartOf (indicates A is a portion of B;may be used for elements of a series)
• HasPart (indicates A includes the part B)
• IsReferencedBy (indicates A is used as a source of information by B)
• References (indicates B is used as a source of information for A)
• IsDocumentedBy (indicates B is documentation about/explaining A)
• Documents (indicates A is documentation about/explaining B)
• isCompiledBy (indicates B is used to compile or create A)
• Compiles (indicates B is the result of a compile or creation event using A)
• IsVariantFormOf (indicates A is a variant or different form of B, e.g. calculated or calibrated form or different packaging)
• IsOriginalFormOf (indicates A is the original form of B)
• IsIdenticalTo (indicates that A is identical to B, for use when there is a need to register two separate instances of the same resource)
• IsReviewedBy (indicates that A is reviewed by B)
• Reviews (indicates that A is a review of B)
• IsDerivedFrom (indicates B is a source upon which A is based)
• IsSourceOf (indicates A is a source upon which B is based)

12.3 relatedMetadataScheme (O)¶

The name of the scheme (occurrences: 0-1).

Allowed values, examples, other constraints

Use only with this relation pair: (HasMetadata/IsMetadataFor).

12.1 schemeURI (O)¶

The URI of the relatedMetadataScheme (occurrences: 0-1).

Allowed values, examples, other constraints

Use only with this relation pair: (HasMetadata/IsMetadataFor).

12.1 schemeType (O)¶

The type of the relatedMetadataScheme, linked with the schemeURI (occurrences: 0-1).

Allowed values, examples, other constraints

Use only with this relation pair: (HasMetadata/IsMetadataFor).

Examples: XSD, DDT, Turtle

Example¶

An example:

1
2
3
4
5

<relatedIdentifier
  relatedIdentifierType="DOI"
  relationType="IsCitedBy">
 10.1234/bar
</relatedIdentifier>

Example¶

1
2
3
4

<sizes>
  <size>15 pages</size>
  <size>6 MB</size>
</sizes>

Example¶

1
2
3
4

<formats>
  <format>PDF</format>
  <format>application/pdf</format>
</formats>

Example¶

1

<version>1.0</version>

16.1 rightsURI (MA)¶

The URI of the license (occurrences: 0-1).

Allowed values, examples, other constraints

Example:

http://creativecommons.org/licenses/by/3.0/de/deed.en

Example¶

An example:

1
2
3

<rightsList>
  <rights rightsURI=”info:eu-repo/semantics/openAccess” />
</rightsList>

OpenAIRE further recommends including license information if available:

1
2
3
4
5
6

<rightsList>
  <rights rightsURI=”info:eu-repo/semantics/openAccess” />
  <rights rightsURI=”http://creativecommons.org/licenses/by/4.0/”>
    Creative Commons Attribution 4.0 International
  </rights>
</rightsList>

17.1 descriptionType (MA)¶

The type of the Description. (occurrences: 1).

Allowed values, examples, other constraints

If Description is used, descriptionType is mandatory.

Controlled List Values:

• Abstract
• Methods
• SeriesInformation
• TableOfContents
• Other

Example¶

1
2
3
4
5
6
7
8

<descriptions>
   <description descriptionType="Abstract">
     This is an abstract
   </description>
   <description descriptionType="Other">
     This is e.g. a note.
   </description>
</descriptions>

18.1 geoLocationPoint (O)¶

A point location in space (occurrences: 0-1).

Allowed values, examples, other constraints

A point contains a single latitude-longitude pair, separated by whitespace.

See Detailed usage instructions.

18.2 geoLocationBox (O)¶

The spatial limits of a place (occurrences: 0-1).

Allowed values, examples, other constraints

A box contains two white space separated latitude-longitude pairs, with each pair separated by whitespace. The first pair is the lower corner (normally south west), the second is the upper corner (normally north east).

See Detailed usage instructions.

18.3 geoLocationPlace (O)¶

Description of a geographic location (occurrences: 0-1).

Allowed values, examples, other constraints

Free text. Use to describe a geographic location.

Detailed usage instructions¶

Use WGS 84 (World Geodetic System) coordinates. Use only decimal numbers for coordinates. Longitudes are -180 to 180 (0 is Greenwich, negative numbers are west, positive numbers are east), Latitudes are -90 to 90 (0 is the equator; negative numbers are south, positive numbers north).

Example¶

1
2
3
4
5
6
7

<geoLocations>
  <geoLocation>
    <geoLocationPoint>31.233 -67.302</geoLocationPoint>
    <geoLocationBox>41.090 -71.032 42.893 -68.211</geoLocationBox>
    <geoLocationPlace>Atlantic Ocean</geoLocationPlace>
  </geoLocation>
</geoLocations>