the RIOXX metadata application profile and guidelines

RCUK RIOXX Application Profile Version 0.91

Note that there is a newer version of the application profile - please check here for the latest version

This version, 0.91, is a minor update from version 0.9
A stable version, 1.0, will be published once testing has been completed - this is ongoing and scheduled to be completed at the end of April.

Changes from version 0.9

  • dc:creator is now rioxxterms:creator
  • dc:contributor is now rioxxterms:contributor
  • dc:audience is now dcterms:audience

This section details the application profile for RIOXX. 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.

Element Cardinality  Description Roadmap
rioxxterms:creator One or more. Mandatory
The creator of a resource may be a person, organisation or service. Where there is more than one creator, a separate rioxxterms:creator element MUST be used for each one. As many creators may be entered as required. If the creator is a person and it is desired to record that person’s affiliation, the affiliation SHOULD be recorded as a rioxxterms:creator element (see rioxxterms:creator). This element SHOULD take an optional attribute called id, designed to hold a machine-readable and unique identifier, if available, for the creator. Any ID entered here MUST be in a form which allows it to be parsed and recognised automatically. The ideal use of this element is to include both a machine-readable ID in the id attribute, and a text string in the body of the element, thus:
<rioxxterms:creator id=”identifier-for-this-creator-entity”>
    name-of-this-creator-entity
</rioxxterms:creator>
Where the creator is a person, the RECOMMENDED format is to add text in the form Last Name, First Name(s), and to include an ORCID ID, if known, in its HTTP URI form, e.g.
<rioxxterms:creator id=”http://orcid.org/0000-0002-1395-3092”>
    Lawson, Gerald
</rioxxterms:creator>
 
dc:identifier Exactly one. Mandatory
This field MUST contain a globally unique and persistent identifier for the resource being described. The identifier SHOULD be an HTTP URI that can be de-referenced (and is, thus, actionable). The purpose of this field is to allow access to the resource, therefore it is RECOMMENDED that this identifier should point to the actual resource being described by the RIOXX record (typically a PDF file), rather than to an intermediary resource such as a repository web page. This resource SHOULD be a version of the resource held in the local repository.
 
dc:language One or more. Mandatory
This refers to the primary language in which the content of the resource is presented. The element MAY be repeated if the resource contains multiple languages. Values used for this element MUST conform to ISO 639–3. This offers two and three letter tags e.g. “en” or “eng” for English and “en-GB” for English used in the UK.
 
dc:source Exactly one. Mandatory
The source label describes a resource from which the current resource is derived (in whole or in part). It is RECOMMENDED that the source is referenced using a unique identifier from a recognised system e.g. the unique 8-digit International Standard Serial Numbers (ISSN) assigned to print and electronic periodicals.
 
dc:title Exactly one. Mandatory
This refers to the resource’s title and any sub-titles. The title is the form of words by which a resource will be formally known and should be represented using the original spelling and wording. The RECOMMENDED format for expressing subtitles is Title:Subtitle
 
dcterms:issued Exactly one. Mandatory
The publication date of the resource. The date SHOULD be encoded using ISO 8601 (post–2004 versions) which follows the following format: YYYY-MM-DD. Year (YYYY) or year and month (YYYY-MM) MAY be used if the full date is not known.
 
rioxxterms:funder One or more. Mandatory
The canonical name of the entity responsible for funding the resource being described by this RIOXX record MUST be recorded here as text. Where more than one funder exists, each MUST be entered as a separate instance of this field. A controlled list of funder names SHOULD be used. A list has been provided for this purpose and is available through the RIOXX web site at http://docs.rioxx.net/funders/
 
rioxxterms:projectid One or more. Mandatory
This is designed to collect the project IDs issued by funders that relate to the current resource. It is REQUIRED to use the alphanumeric identifier provided by the funder in its original format e.g. ST/K001234/1. Sometimes publications have more than one project ID associated with them; these MUST be recorded using separate instances of rioxxterms.projectid. In cases where projects have been funded internally, use whichever internal code is appropriate.
 
dc:description Zero or more. Recommended
This field may be indexed and its contents presented to people conducting searches. The goal is to describe the content of the resource using free text. It is RECOMMENDED that an English language abstract be used where available. HTML or other markup tags SHOULD NOT be included in this field.
 
dc:format Zero or one. Recommended
This refers to the form of the resource being described in the RIOXX record. The resource can be physical or digital and therefore this element can refer to the media-type or dimensions of that resource. Where the resource being described is digital, the MIME type of the object pointed to by this RIOXX record’s dc:identifier element MUST be entered here.
 
dc:publisher Zero or more. Recommended
A free text string giving the name of the entity responsible for making the version of record of a resource available. This could be a person, organisation or service.
 
dc:rights Zero or one Recommended
It is RECOMMENDED that a URL to an appropriate Creative Commons license is used here, for example: http://creativecommons.org/licenses/by-sa/3.0/deed.en_GB
Work is under way to develop consensus on a controlled vocabulary that describes rights to open access items as well as the associated issues of Creative Commons licenses and embargo periods. Once this work concludes an expression of rights and licensing is expected to become mandatory.
dc:subject Zero or more. Recommended
Normally keywords, phrases or classification codes are used to describe the topic of the resource. If using free text, the use of general keywords SHOULD be avoided. It is RECOMMENDED to use a formal classification scheme or controlled vocabulary e.g Library of Congress Classification Headings or Medical Subject Headings (MeSH). When including terms from multiple vocabularies, separate element iterations MUST be used. If multiple vocabulary terms or keywords are used, terms SHOULD be separated with one of the following approaches:
  • the use of semi-colons to separate individual terms
or
  • the use of separate iterations of this element for each term.
 
dcterms:audience Zero or more. Optional
This field is designed to contain information about the group for which the resource is intended or is considered to be useful. There is no controlled vocabulary for this but sometimes creators or publishers indicate the intended audience. Note that the Research Outcomes System (ROS) used by most of the UK’s Research Councils tracks whether a resource is for a "non-academic audience" (with a drop-down list of possible selections) and whether a resource is for an "international audience". In the absence of alternative formal vocabularies, following the ROS lead is a reasonable course of action.
The introduction of a controlled vocabulary for audience will be proposed for phase 2 of the RIOXX project, subject to funding.
rioxxterms:contributor Zero or more. Optional
This field is designed to describe an entity – for example the name of a person, organisation or service – responsible for making contributions to the content of the resource. As many rioxxterms:contributor elements may be entered as required. If the contributor is a person and it is desired to record that person's affiliation, the affiliation MUST be recorded as a separate rioxxterms:contributor element. This element SHOULD take an optional attribute called id, designed to hold a machine-readable and unique identifier, if available, for the contributor. Any ID entered here MUST be in a form which allows it to be parsed and recognised automatically. The ideal use of this element is to include both a machine-readable ID in the id attribute, and a text string in the body of the element, thus:
<rioxxterms:contributor id=”identifier-for-this-contributor-entity”>
    name-of-this-contributor-entity
</rioxxterms:contributor>
Where the contributor is a person, the RECOMMENDED format is to add text in the form Last Name, First Name(s), and to include an ORCID ID, if known, in its HTTP URI form, e.g.
<rioxxterms:contributor id=”http://orcid.org/0000-0002-1395-3092”>
    Lawson, Gerald
</rioxxterms:contributor>
 
dc:coverage Zero or more. Optional
This refers to the scope or extent of the content of the resource. It may include jurisdictional, temporal or spatial information. It is RECOMMENDED that, where possible, a recognised globally unique identifier is used, such as the Thesaurus of Geographic Names. For example, the place of publication may be recorded.
 
dc:type Zero or more. Optional
Type refers to the nature or genre of the content of the resource and can be entered as free text. Take care not to confuse this with dc:format.
The introduction of a controlled vocabulary for 'type' will be proposed for phase 2 of the RIOXX project, subject to funding.
dc.relation Zero or more. Optional
This format of this element SHOULD be an HTTP URI which points to a related resource. It is RECOMMENDED that, where available, the publisher’s DOI for the main resource being described in the RIOXX record also be entered here, in it’s HTTP form – e.g. http://dx.doi.org/10.1006/jmbi.1995.0238 Each related resource MUST appear as a separate instance of the field.
 
dcterms:references Zero or more. Optional
The format of this element SHOULD be an HTTP URI which points to a resource referenced by the resource described in the RIOXX record. Common examples might include a data-set which underpins a paper being described in the record. Each reference MUST appear as a separate instance of this element.