Services in the RDA Registry
Services in the research domain support the creation and use of collections by providing functions for the creation, access, processing and analysis of data.
ISO 2146 defines a service as 'a system (analogue or digital) that provides one or more functions of value to an end user'. Services can be web services, provided across the web and following a well-defined machine protocol, such as OAI-PMH Harvest or RSS Syndication; but they may also be offline services, provided via an instrument, for example.
As with parties and activities, the RDA Registry gathers service descriptions in order to provide context for the collections it registers, and to enable discovery of related collections, rather than to serve as an exhaustive registry of research services. For that reason, the services described in the RDA Registry should be related to the collections that they contributed to the creation or use of.
ANDS is currently investigating expanding the scope of the data services it registers, with a particular focus on machine-to-machine services. For more information on this project, see Enhancing data service discovery
Do I need to create a Service record?
Often data is tightly bound with a service, so there can be confusion about whether to model it as a collection or a service in the RDA Registry. To be described in the Registry, a service must be, or have been, instantiated and it should be possible to name the location of the service, and the parties managing the service. Treating services as instances means that there may be many service records in the RDA Registry that look quite similar—distinct sensors, for example, or distinct deployments of RSS. As long as each instance is associated with a collection registered with the Registry, it is still appropriate to distinguish between the service instances.
- A podcast is a collection of recordings, combined with a syndication service for accessing that collection. The recordings can be added to the RDA Registry as a collection, while the RSS feed to the podcast can be added to the Registry as an associated discovery service (syndication-rss).
- HTTP-Search (i.e. the single search box on the home page for most catalogues, repositories and registries) can be assumed to be generic search functionality for a collection; this does not need not be registered in the RDA Registry as a distinct service object if the Registry already has a description of such a collection.
- Portals provide access to an aggregation of collections. A portal can be modelled as as a service with its constituent contents also described as a collection in the RDA Registry.
Instruments can be modelled as online or offline services—although strictly speaking what services model is the capability of instruments to create data collections. Instruments are often housed in facilities, but facilities should be modelled in the RDA Registry as parties: they are the organisations which own the instruments. Instruments can be composed of individual sensors; both the large-scale and more fine-grained instrument may be of interest to users. Instruments can be related to each other in a partOf relationship. For example, a specific detector can be part of a Synchrotron beamline instrument, or of a radio telescope. Whether to model both the instrument and its component sensors in the RDA Registry depends on whether it will be useful to discover collections through sensors (and whether those service descriptions provide additional context for the associated collection), rather than just through the instrument. In either case, the details of sensors used to gather the data should be recorded in local metadata stores.
- Software modelled as a service describes an instantiation of the software. In some cases, it may be appropriate to create a service record to describe an instance of software as well as a collection record (of type "software") to describe downloadable software source code that underpins the corresponding software service. Separate records would be expected for different versions of the same software, or for different implementations.
Metadata for Service Records in the RDA Registry
The table below specifies the mandatory and optional elements for creating a service record for the RDA registry. Click on the label name to see how the element should be encoded.
Provide as many optional elements as you can, and follow the guidelines in the best practice sections to maximise discovery and reuse of your service.
|Label in the RDA Registry||Schema Element Name||Obligation||Repeatable||Definition|
A wrapper element for metadata records (registry objects). It has no relationship to objects being described, but exists solely as part of the interchange infrastructure.
The entity holding the managed version of the registry object metadata, as represented by a URI. The primary source of truth for the metadata record.
The organisation that is contributing the metadata record (registryObject), that is, the metadata publisher.
A unique string that persistently identifies a metadata record within the RDA Registry.
“Service” is one of four classes of things that may be described in a metadata record.
The type of service selected from a predefined list.
The name or title given to a service.
A plain text description of a service. A delivery method may be specified as a type of description.
For a service, relevant locations may include a physical address (required for an offline service) or an electronic address (contact email or access URI). For web services, this should be a URI that can be processed by a client following the service protocol (service endpoint) and can be distinguished from the service arguments using the arg element and its attributes.
A related party linked to the service using an object key or an identifier.
A related collection linked to the service using an object key or an identifier.
|related info||<relatedInfo>||Optional||Y||Additional information related to the service, or providing context to the service, including reuse and provenance information.|
The start and end dates of the existence of the service being described.
A sequence of characters or words that uniquely identify a service within a particular context or the domain of a specified authority.
A term, keyword, classification code or phrase representing the primary topic or topics covered by a service.
Spatial characteristics of a location which is the focus of a service described using coordinates or text.
Temporal characteristics of the intellectual content of a service described using dates or text. (Not start and end dates for the service, use existence dates instead).
A link to a web page or other resource that describes or invokes the policies for accessing a service. Deprecation proposed: Preferably use the access rights element to describe access policies for Services.
The date the service record metadata was last changed in the source system.
<element>; @ = attribute
In relation to collections, services can be classified as creation services, metadata services, discovery services, or reuse services:
- Creation services add data to collections; e.g. simulators, instruments, visualisation software.
- Metadata services add metadata to items and collections; e.g. annotation software, classification software.
- Discovery services enable read-only access to collections; e.g. search, harvest, syndicate.
- Reuse services enable the reuse of research data; e.g. rights management, data storage, publishing, ethics and governance.
A Service Type must be specified, preferably from the Service Type vocabulary below.
For discovery services, the Service Type is a two-part string, with the first part specifying the service genre and the second part specifying the protocol (for example, syndicate-rss, harvest-oaipmh, search-sru). If there are local extensions to the service protocol that service users need to know they should be provided in the RelatedInformation element. For creation and metadata services, which do not have generic protocols, only the service genre has been specified in the Service Type. However, if there is a well-defined protocol it should be provided in the RelatedInformation element as type "reuseInformation". The Service Types for creation and metadata services are deliberately generic and are taken from the set of service genres registered with the JISC e-Framework (now archived). No reuse services have been specified in the current Service Type vocabulary.
produces a new data object representing existing phenomena in the world, including physical reality and user input: an instrument creates data.
produces a new data object out of mathematical formulae and parameters, rather than capturing and representing existing data in the world: a simulator generates data.
presents existing data in a summary form: a visualisation reports on data.
changes a data object into a new data object, with a distinct format: an analysis tool creates a new data object out of data (either raw data, or other analyses).
builds a new data object instance composed of multiple existing data objects: a survey generation tool creates a survey form out of user input and templates.
Open Archives Initiative Protocol for Metadata Harvesting. OAI-PMH
Search service over HTTP. RFC2616
a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. OpenSearch.org
standard XML-focused search protocol for Internet search queries based on Z39.50 semantics. SRU
A variation of SRU. Messages are conveyed from client to server, not by a URL, but instead using XML over HTTP via the W3C recommendation SOAP, which specifies how to wrap an XML message within an XML envelope. SRW
The standard, ISO 23950 (also ANSI/NISO Z39.50), specifies a client/server-based protocol for searching and retrieving information from remote databases. Z39.50
an XML-based Web content and metadata syndication format. atom
a family of web feed formats that are specified using XML. RSS
provides infrastructure for the storage of data objects.
provides a commentary on a data object, or part thereof.
Software tools can have multiple types applicable from the Service Type vocabulary, however the RDA Registry requires a single type, reflecting the primary use of the tool in the research community.
Delivery methods (Description Type)
To be used, a service must be implemented and the delivery method which makes it available to a client can be specified. Currently in RIF-CS, the delivery method may be recorded as a string without spaces in a Description element type of "deliveryMethod". This is under review, but remains the current guidance.
Delivery methods include:
- Web service: according to the W3C, "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format". (Unlike the W3C, we do not restrict this delivery method to WSDL.)
- Software: all services provided by software other than as web services; users interact with these through a user interface or on a local system. This includes Unix applications, PC/Mac applications, and software accessed through a browser.
- Offline service: a service not provided through computers or the internet. Instruments such as beamlines, telescopes and microscopes are sometimes modelled as offline services.
- Workflow: a service that orchestrates other services. Kepler workflows, which script how various instruments and computational tools interact to deliver an output, are an example of a workflow.
Discovery services are typically web services; creation services typically have other delivery methods. Web services are the most straightforward type of service to model: the definition of their function and scope is specified through statements of behaviour and data representation, and they have a well-defined protocol for interaction with service clients. These protocols can usually be indicated through the service type. The Arg (argument) element within ElectronicAddress can be used to differentiate between a base URL and the service arguments in a service call URL. The provision of base URL and service arguments for non-standard web APIs is also recommended to assist the eventual user.
Software interfaces should be described in accompanying documentation and linked to as RelatedInformation, particularly if the interface is non-standard.
Date Modified (metadata) attribute
A date that indicates the currency of a metadata record may be provided as a service attribute in a RIF-CS record, but is not displayed or searchable in Research Data Australia. The DateModified attribute indicates the date when metadata describing a service was last changed in the source system (not the RDA Registry). DateModified has no relation to the date of the last harvest of metadata from a data source. This date will usually be system-generated by the source system and should be UTC and of one of the forms described in section 3.2.7 of the W3C Schema Data Types document.
The RDA Registry infers and displays bi-directional links between related objects in Research Data Australia. If a service links to a collection within the same data source, the collection record does not need to link back to the service; the RDA Registry will display the inferred reverse link in Research Data Australia. If the service and collection are from different data sources, the inferred reverse link will only be displayed if the receiving partner has opted in to allow bi-directional links. See relationships between registry objects for information on how the RDA Registry can automatically create relationships between objects, and bi-directional links between related objects.
Expand the links below to view an explanation of the relationships:
Relations between services may be described using the "hasPart"/"isPartof" relationship. Creation services can often be described as part of another creation service, as with sensors and instruments, or individual services and service workflows. Metadata and Discovery services, however, are not usually described as forming part of other services.
Services must be linked to at least one collection using the generic relationship "isSupportedBy", or the more specific support relations: "makesAvailable" (for harvest, search and syndicate), "presents" (for report), "produces" (for create, generate, assemble), "operatesOn" (for transform), or "addsValueTo" (for annotate).
If a transform or assemble service is used to change collection A into collection B, the service operates on input collection A, and produces output collection B. (For collection discovery, the produces relation is more important than the operates on relation.) Collection A and collection B are related through the relation isDerivedFrom/hasDerived collection. This relation is distinct from "partOf": if a collection is derived from another collection, the output is a new collection, and is not considered part of the old.
If service A is part of service B, and service A is related to a collection, then service B should not also be modelled has having the same relation to the collection. Users should navigate down from service B to discover associated individual collections.
Services may be linked to parties through the following relations: "isManagedBy" or "isOwnedBy". Note that the owner/manager of a service may be distinct from the owner/manager of the associated collection.
(In the case of instruments housed in facilities, the facility is treated as a party and the instrument "isOwnedBy" the facility).
What makes a good Service record?
Ideally, service records will include accurate, concise and authoritative descriptive content that facilitates discovery, appraisal and reuse of collections associated with the service.
Service descriptions in the RDA Registry are meant to convey only high-level, indicative information. More complete detail about data collection provenance (including events - creation, assemble, annotate, and transform etc, when and where an event happened, which instruments or software were used and who was involved) should be provided in local metadata stores, and linked to as RelatedInformation type "provenance" from the collection description.
In practice, the actual content of individual service records will depend on the source of the metadata for the description (system-generated or human-created), the goals and resources of the institution providing the service records, and the information needs of researchers accessing the records. While there is no 'one size fits all' for service descriptions, a ‘good’ service record might:
include name variations where appropriate
- include contact details for a person or organisation - electronic addresses are preferred, e.g. an email address
- include access information including an electronic address such as a URL or a physical address
- include rights information including who may access and under what conditions
include a description of the service for potential users including version, configuration or implementation information; include a delivery method if applicable
- include a persistent identifier such as a handle
- include additional protocol information as related information if applicable
include subject terms that describe the research focus of the service
- be connected to collections that can be accessed through, or acted upon, by the service
- include links to related information which provides research context around the service, e.g. a web page URL for the service
See the individual elements and attributes for best practice information, and find out how to create RIF-CS metadata for impact.
26 October 2010
First web publication
25 January 2011
Complete revision to add creation and metadata services
14 April 2011
Added link to Access Policy (services only) page
28 March 2014
Add information to the best practice section, about the display of multiple service records in Release 12
26 Nov 2015
Updated information to reflect changes with Release 18 including addition of new types for collections and services
17 May 2017
New Service page created replacing the "Best practice for creating service records" and "RIF-CS in Practice: Describing a Service" pages. Content completely revised and updated.