RDA Registry

The RDA Registry is used to store, create and manage metadata records. The registry is modelled on an international standard, ISO 2146:2010 Information and documentation -- Registry services for libraries and related organisations. This standard was carefully chosen in preference to other models as it has strong support for a federated registry service that contains descriptive and administrative metadata for collections and related services, parties and activities. The standard also supports the expression of relationships between these entities.

Registry Object

The registry object is a PHP class that determines how metadata represents that the RDA Registry Software uses. A registry object can be constructed by loading the model registry_object/registry_objects and initiate with new _registry_object(id) where the id of the registry object needs to be unique.

A registry object can be extended by several different subclasses like slug, quality and connections. A sample extension can be created by copying

PHP

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
class Example_extension extends ExtensionBase
{
	// Define your properties and methods here
	// You can reference other extensions from $this->ro->
	// i.e. $this->ro->updateTitles()	

	// You can make database calls using $this->db->  (see: ActiveRecord)
	// You can access the rest of CodeIgniter through
	// $this->_CI->  

	// From outside the registry object, this can simply by called by
	// $ro->exampleMethod();

	function exampleMethod() {
		$this->ro->exampleMethodCalled = TRUE;
		$this->ro->save();
	}

	/**
	 * @ignore
	 * This MUST be defined in order to get the in-scope extensions variables
	 */
	function __construct($ro_pointer) {
		parent::__construct($ro_pointer);
	}
}

Registry objects are unique by id, keys are not programmatically unique so that different registry objects can exist within multiple states and have separate changes.

ARDC Registry database is model in such a way that any new attributes are stored without having to declare new fields. For eg.

PHP

$ro = $this->ro->getByID(id);
$ro->field = 'New field value';
echo $ro->field;
//New field value

The storage structure for a registry object is separated into different tables.

The registry_objects table holds all registry objects and their core attributes
The registry_objects_attributes table holds all the non-core attributes
The registry_objects_metadata table holds all the normalised metadata for a particular registry object
The record_data table holds all the XML record data for a registry objects with all revisions
The registry_objects_relationships table holds all the relationships that a registry object have with another, included are inferred links and other automatically generated links

Registry Object API

The Registry Object API is provided as one of the Registry services and it allows the Discovery Portal to request information about registry objects which match a query or specific registry object ID. The portal utilises this API for the detailed display of records and to retrieve any additional metadata that the display logic requires.

This API is designed in much of a REST-ful interface where GET statement refers to a collection.

The Registry Object API is available via registry/services/registry_objects

The API has been developed in a way which allows the Portal to request specific metadata items to prevent the need to retrieve the whole metadata record each request. As of release 15, the Registry Object API offers the following handlers:

<blank>: returns everything
Core: returns the basic metadata of the registry object, eg (id, key, title, group,...)
Descriptions: returns the list of descriptions and descriptions type
Relationships: A list of all the related objects group by class (limit of 5 by default, overwrite with related_object_limit), and a total count of each relationship class.
Subjects: A list of subjects, in resolved form, unresolved form and type
Spatial: A list of spatial objects that the registry object contain.
Temporal: A list of temporal range that the registry object contain. Limited by year.
Citations: Citation information of the registry object
Dates: A list of available date and date type
Connection Tree: Data for the display of connection tree graph use for SOLR
RelatedInfo: Metadata that is located in the relatedInfo RIFCS section
Identifiers: A list of identifiers, type and their resolved form.
Rights: A list of rights element that the registry object contain
Contact: Contact information for the registry object.
Direct Access: whether the registry object has any downloadable for direct access portal.
Suggest: A suggestion list of registry objects that closely related to this registry object.
Logo: A determined logo for the registry object, normally this is found in description[type=logo]
Tags: A list of registry object internal/social tags for the registry object
Existence Dates: A list of specialised dates field for the registry object
Identifier Match: A list of records that shares the same identifier as the registry object.

For eg

CODE

GET registry/services/registry_objects?q=fish&limit=10&offset=0
returns 10 registry objects that matches the search term of fish

GET registry/services/registry_objects/16572
returns the JSON form of the API response for registry object 16572

GET registry/services/registry_objects.xml/16572
returns the XML from of the same request

GET registry/services/registry_objects/16572/relationships
returns just the relationships of the given registry object. By default, if there’s no handler passed in to the URL, the registry object API will return all available handler.

XML and RifCS

The registry object uses RIF-CS in order to represents data and the Registry Software is reliant on XML to store these data. Any primary metadata a registry object are derived mainly from the RIFCS XML.

Sync

To normalise and obtain additional metadata from groups of registry object, a process dubbed sync by the developers enable richer contents to be stored in the metadata. These processes are currently

Process Identifiers: this process extracts the relevant identifiers out of RIFCS and put them into a look up table called registry_object_identifiers. This enables us to do identifier related operation like matching by identifiers and resolving identifiers
Add relationships: RIFCS can define relationships in the XML it provides. The RDA Registry also offers additional type of relationships, such as reverse relationships, related by identifiers,... This process will add all relevant relationships for a registry object and put them into a lookup table called registry_object_relationships
Update Quality Metadata: The quality of the registry object is determine by how rich the XML is, this process helps determine that and sort registry objects into Quality Levels
Index: The registry uses SOLR to index data and enable fast searching of registry objects. This process collects all indexable data into an indexable data structure and send them over to SOLR for indexing. Searching of records via SOLR is only available prior to an Index.

More information

RIF-CS Schema- introduction to RIF-CS
Manage Records - creating and publishing metadata manually
Data Source Harvest Configuration - configuring your data source accounts to enable automatic harvesting