About RIF-CS
Contents
About RIF-CS
What is RIF-CS? | RIF-CS Origins | Schema changes
Using the Schema
Repeatability of elements | Sequence of elements | Vocabularies | Syntax | Obligation
Better metadata quality and display
URL displays | XHTML text formatting | Support for manual data entry and data source account management
About RIF-CS
What is RIF-CS?
The RIF-CS schema is a data interchange format that supports the electronic exchange of collection and service descriptions. It organises information about collections and services into the format required by the ANDS Collections Registry.
XML (eXtensible Markup Language) is a mark-up language used to electronically encode and exchange information. XML comprises markup tags and content. An XML schema (like RIF-CS) describes the required structure, order and content of an XML document which is to be used for a particular purpose. The RIF-CS schema defines the structure for XML documents provided to ANDS. XML content can be provided in UTF-8 encoding.
Where did RIF-CS come from?
RIF-CS is based on the international standard, ISO 2146:2010 Information and Documentation-Registry Services for Libraries and Related Organisations. RIF-CS only includes those elements of ISO 2146 which are necessary for a collections registry, and is not a full binding to the standard. This means that some of the concepts and elements found in ISO 2146 are not found in RIF-CS. RIF-CS is an XML schema. More about the ANDS implementation of ISO 2146 and why that standard was chosen.
Schema changes
The RIF-CS Schema continues to evolve to meet the needs of the Australian research community, and is reviewed annually. The user community has input into this process through the RIF-CS Advisory Board. For current change information see RIF-CS Schema Change News.
Information about the 2010 changes |
Download printable RIF-CS v1.2.0 overview diagram PDF (31kb)
Information about the 2011 changes |
Download printable RIF-CS v1.3.0 overview diagram PDF (41kb)
Using the Schema
Repeatability of RIF-CS elements
All elements within RIF-CS are repeatable with the following exceptions: registryObject element; key element; originating source element. Attributes cannot be repeated within an element.
If necessary, attributes can be repeated by adding another instance of their element, with the exception of the following:
- activity, collection, party or service (only one per metadata record)
- date modified (only one per metadata record)
- date accessioned (only one per metadata record).
The RIF-CS schema supports multiple identifiers, multiple names, multiple locations, multiple relations, multiple subjects, multiple descriptions, and multiple links to related information if required. Use repeated elements to do this. For example:
- if there is a need to enter multiple identifiers, create additional identifier elements to hold the information.
- if there is a need to enter multiple names, create multiple name elements to hold the information.
Full details of repeatability are contained in the RIF-CS schema.
Sequence of RIF-CS elements
The elements within RIF-CS are sequenced. Elements must be ordered according to the schema sequence, or the RIF-CS document will not be ingested into the ANDS Collections Registry and error messages will be generated of the form " This element is not expected. Expected is...".
Vocabularies and local values
Vocabularies (lists of terms or permissible data values) are the main source for metadata values recorded in the ANDS Collections Registry.
ANDS has suggested vocabularies. Use of the ANDS vocabularies is recommended, as consistent terminology improves the precision of searching. However, user defined vocabularies can be used in most elements instead of the suggested vocabularies. As an example, subject terms used in a discipline- or theme-based repository would be valuable. Keywords used in publications or research proposals could also provide valuable search terms.
However, user defined vocabulary capability was also included to allow repositories to use controlled vocabularies that are appropriate to specific disciplines and communities. It was not designed to allow uncontrolled use of ad hoc vocabularies. Use of local vocabularies, especially on an ad hoc basis, has an adverse effect on discoverability. If different vocabularies are used to describe the same thing, the search results will not include all relevant metadata records.
The ANDS vocabularies are expected to be informed and developed further by the RIF-CS user community. Please contact services@ands.org.au if you have candidate vocabulary terms to be evaluated for possible inclusion in the ANDS vocabularies.
Syntax
Syntax is the layout and form of information within a metadata element.
For syntax issues with the RIF-CS elements see the RIF-CS schema
However, the schema do not describe syntax for element content derived from vocabularies. This is particularly important for information such as spatial coordinates. As an example, if incorrect syntax is used to describe spatial coordinates, the information cannot be used for automated mapping.
To resolve a syntax issue for element content derived from vocabularies, first check any references to standards or examples provided in this guide, or alternatively model your syntax on similar existing records. If this does not resolve the issue please contact your ANDS contact or services@ands.org.au.
Obligation
Obligation refers to whether a particular RIF-CS component is required or optional.
At the most basic level, the RIF-CS schema defines which elements and attributes are required. These rules are set out in the Schema Guidelines and enforced as part of validating RIF-CS XML documents at the point of ingestion into the ANDS Collections Registry.
All metadata records in the ANDS Collections Registry must have the following components:
- group attribute for one value selected from the classes 'activity', 'collection', 'party' and 'service'
- a type attribute for the class selected
In addition, the inclusion of a name and a URL pointing to the source metadata record are highly recommended.
Attributes may be required conditionally. For example, if spatial information is recorded within the element, it is mandatory to also specify the type of spatial information in the associated type attribute. Inclusion of spatial information is optional, but if it is there, its type must also be recorded.
The Schema Guidelines contain full technical obligation information. For the Publish My Data service, which captures a selected subset of information and can only be used to describe collections, a separate set of obligations applies. For content providers supplying metadata to ANDS under contract, additional obligations may apply. These will be specified as part of contractual arrangements and may reference the Metadata Content Requirements.
Better metadata quality and display
URL displays
Identifiers such as handles, Digital Object Identifiers and PURLs can be provided either as strings containing the identifier component only, or as resolvable URLs. URLs are preferable where available, both to facilitate navigation by users and to support linked data developments.
From December 2011,
Identifiers will be displayed within Research Data Australia as provided by the data provider and prefixed with the identifier type
- Examples: DOI :10.654654/ASDF/4554565 or DOI: http://dx.doi.org/10.654654/ASDF/4554565
Where a resolvable URL can be generated for a provided identifier the displayed identifier will become a clickable link to the generated URL.
- Example: displayed identifier ‘DOI :10.654654/ASDF/4554565' shall point to http://dx.doi.org/10.654654/ASDF/4554565
Business rules for display of identifier types:
|
Identifier Type (must be typed as) |
Business Rules |
|
abn |
Non resolvable identifier. |
|
arc |
Non resolvable identifier. |
|
ark |
Identifier made resolvable by prefixing the given identifier with ‘http://'. ARK identifier must be provided with the Name Mapping Authority (NMA) and ARK identifier e.g. ands.org/ark:/432423. If only the ark identifier is provided we can't tell who the NMA is and can't produce a link. In the above example it would be ands.org. Mouse over text for the link shall read ‘ Resolve this ARK identifier' |
|
AU-ANL:PEAU |
Identifier made resolvable by prefixing the given ‘nla.party' identifier with ‘http://nla.gov.au/'. Provided NLA identifier must contain the NLA party identifier prefix ‘nla.party' Prefix type for this identifier shall be shown as ‘NLA' not ‘au-anl:peau'. Mouse over text for the link shall read ‘View the record for this Party in Trove' Existing ‘View the record for this Party in Trove' link shall be removed. |
|
doi |
Identifier made resolvable by prefixing the given DOI with ‘http://dx.doi.org/'. Provided DOI must start with ‘10.' Mouse over text for the link shall read ‘ Resolve this DOI' |
|
ean13 |
Non resolvable identifier. |
|
eissn |
Non resolvable identifier. |
|
handle |
Identifier made resolvable by prefixing the given handle with ‘http://hdl.handle.net/'. Mouse over text for the link shall read ‘Resolve this Handle |
|
infouri |
Non resolvable identifier. |
|
isbn |
Non resolvable identifier. |
|
isil |
Non resolvable identifier. |
|
issn |
Non resolvable identifier. |
|
istc |
Non resolvable identifier. |
|
lissn |
Non resolvable identifier. |
|
local |
Non resolvable identifier. |
|
purl |
Identifier made resolvable by prefixing the given identifier with ‘http://purl.org/'. |
|
txt |
Non resolvable identifier. |
|
upc |
Non resolvable identifier. |
|
uri |
No transformation required. URIs should be provided in full by the data provider (e.g. https://example.org/myexample ). |
|
urn |
Non resolvable identifier. |
XHTML text formatting
This capability has been added in some elements to allow for better formatting of information for display in Research Data Australia. More information about XHTML text formatting
Support for manual data entry and data source account management
These functions undergo ongoing enhancements, including:
- stripping leading and training blanks in manual screens
- warning messages where records do not comply with schema or metadata content requirements
- harvest error messages
| Date | Change history |
| April 2010 | Consultation draft |
| 26 Oct 2010 | Added RIF-CS 1.2.0 change information and clarifications |
| 8 Aug 2011 | Added statement confirming that UTF-8 encoding can be accepted in XML feeds, added RIF-CS v1.2.0 diagram PDF |
| 28 Nov 2011 | Expanded information and additional links |
| 29 Nov 2011 | Added information about URL display and manual screen enhancements |
| 16 Apr 2012 | Removed reference to NISO A Framework of Guidance for Building Good Digital Collections 3rd edition December 2007. |
Please send any feedback on this page to guides@ands.org.au








