Service

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.

The ARDC has developed a best practice guideline for metadata for services (and their related collections), with a particular focus on machine-to-machine services. This extends beyond RIF-CS for service description, to other metadata standards including ISO19115, ISO19119 and DCAT. Access the Beyond RIF-CS: Metadata for Services Good Practice Guide for more information.

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.

For example:

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.

A Service Discovery tool within the RDA Registry allows Data Source Administrators to auto-generate RIF-CS Service records for any Open Geospatial Consortium (OGC) service URLs referenced within their Collection records. For more information, see the Service Discovery help guide.

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
registry object	<registryObject>	Mandatory		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.
originating source	<originatingSource>	Mandatory	N	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.
group	@group	Mandatory	N	The organisation that is contributing the metadata record (registryObject), that is, the metadata publisher.
key	<key>	Mandatory	N	A unique string that persistently identifies a metadata record within the RDA Registry.
service	<service>	Mandatory	N	“Service” is one of four classes of things that may be described in a metadata record.
service type	<service type>	Mandatory	N	The type of service selected from a predefined list.
name/title	<name>	Mandatory	Y	The name or title given to a service.
description	<description>	Optional	Y	A plain text description of a service. A delivery method may be specified as a type of description.
location/address	<location>	Optional	Y	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.
related object (party) OR related info (party)	<relatedObject> OR <relatedInfo>	Optional	Y	A related party linked to the service using an object key or an identifier.
related object (collection) OR related info (collection)	<relatedObject> OR <relatedInfo>	Optional	Y	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.
rights	<rights>	Optional	Y	A wrapper element that contains descriptions of rights, licences and access rights for a service, in both text and URI formats.
existence dates	<existenceDates>	Optional	Y	The start and end dates of the existence of the service being described.
identifier	<identifier>	Optional	Y	A sequence of characters or words that uniquely identify a service within a particular context or the domain of a specified authority.
subject	<subject>	Optional	Y	A term, keyword, classification code or phrase representing the primary topic or topics covered by a service.
spatial coverage	<coverage>	Optional	Y	Spatial characteristics of a location which is the focus of a service described using coordinates or text.
temporal coverage	<coverage>	Optional	Y	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).
date modified	@dateModified	Optional	N	The date the service record metadata was last changed in the source system.

<element>; @ = attribute

Service attributes

Service Types

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.

Category	Service Type	Explanation
Creation	create	produces a new data object representing existing phenomena in the world, including physical reality and user input: an instrument creates data.
	generate	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.
	report	presents existing data in a summary form: a visualisation reports on data.
	transform	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).
	assemble	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.
Discovery	ESRI:ArcGIS:GPServer	ArcGIS GPS Server
	ESRI:ArcGIS:ImageServer	ArcGIS Image Server
	ESRI:ArcGIS:MapServer	ArcGIS Map Server
	harvest-oaipmh	Open Archives Initiative Protocol for Metadata Harvesting. OAI-PMH
	OGC:WCS	Open Geospatial Consortium Web Coverage Service. WCS
	OGC:WFS	Open Geospatial Consortium Web Feature Service. WFS
	OGC:WMS	Open Geospatial Consortium Web Map Service. WMS
	OGC:WMTS	Open Geospatial Consortium Web Map Tile Service. WMTS
	OGC:WPS	Open Geospatial Consortium Web Processing Service. WPS
	OPeNDAP	Open-source Project for a Network Data Access Protocol service. OPeNDAP
	search-http	Search service over HTTP. RFC2616
	search-opensearch	a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. OpenSearch.org
	search-sru	standard XML-focused search protocol for Internet search queries based on Z39.50 semantics. SRU
	search-srw	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
	search-z3950	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
	syndicate-atom	an XML-based Web content and metadata syndication format. atom
	syndicate-rss	a family of web feed formats that are specified using XML. RSS
	THREDDS	Thematic Real-time Environmental Distributed Data Services. THREDDS
Metadata	store	provides infrastructure for the storage of data objects.
Metadata	annotate	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.

Service relationships

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:

Related Services...

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.

Related Collections...

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.

Related Parties...

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.

Exemplars

Search-http example

XML

<registryObject group="AuScope">
    <key>b3fc37d6b3e0523eb42eed63ca546c8f25415434</key>
    <originatingSource>http://portal.auscope.org</originatingSource>
    <service type="search-http">
      <name type="primary">
        <namePart>NVCL</namePart>
      </name>
      <location>
        <address>
          <electronic type="url">
            <value>https://sarigdata.pir.sa.gov.au/nvcl/geoserver/wfs</value>
          </electronic>
          <electronic type="other">
            <value>WFS</value>
            <arg type="string" required="true" use="keyValue">service</arg>
          </electronic>
          <electronic type="other">
            <value>GetCapabilities</value>
            <arg type="string" required="true" use="keyValue">request</arg>
          </electronic>
          <electronic type="other">
            <value>gsmlp:BoreholeView</value>
            <arg type="string" required="true" use="keyValue">typeName</arg>
          </electronic>
        </address>
      </location>
      <relatedInfo type="reuseInformation">
        <identifier type="uri">http://www.opengeospatial.org/standards/wfs</identifier>
      </relatedInfo>
      <coverage>
        <spatial type="iso19139dcmiBox">northlimit=90; southlimit=-90; westlimit=-180; eastLimit=180; projection=WGS84</spatial>
      </coverage>
      <relatedObject>
        <key>ContactPerson</key>
        <relation type="isManagedBy"/>
      </relatedObject>
	  <relatedObject>
        <key>myuni.edu.au/THX-1138raw</key>
        <relation type="makesAvailable"/>
      </relatedObject>
      <subject type="anzsrc-for">02</subject>
      <description type="brief">This service provides borehole features and the results of analysis performed on them. The borehole feature describes drill holes (diamond or otherwise) for which the data provider stores core or chips in their core libraries for public access.</description>
      <rights>
        <accessRights type="open">There are no access restrictions associated with this service.</accessRights>
      </rights>
    </service>
</registryObject>

Create example

XML

<registryObject group="University of New South Wales">
    <key>hdl:1959.4/004_2119</key>
    <originatingSource>https://researchdata.ands.org.au/registry//orca/register_my_data</originatingSource>
    <service type="create">
      <name type="primary">
        <namePart>Bruker Avance III 94/20</namePart>
      </name>
      <name type="abbreviated">
        <namePart>UNSW_MRIB94T</namePart>
      </name>
      <name type="alternative">
        <namePart>Boltzmann</namePart>
      </name>
	  <description type="full">A magnetic resonance imaging (MRI) instrument from Bruker BioSpin, GmbH using an Avance III HD console for non-invasive pre-clinical or materials imaging and spectroscopy. MRI provides excellent in-vivo soft-tissue image contrast for qualitative analyses, 3D images for quantitative volumetric measurements, and access to parameter maps (e.g., MR relaxation, diffusion and flow) related to underlying tissue structure and function. Rapid imaging techniques are available to study dynamic processes (heart cycle). A wide range of MR protocols are available for in- and ex-vivo MR imaging (MRI) and MR spectroscopy (MRS). MRI and/or MRS studies on nuclei other than protons (1H) are also possible, including 19F, 23Na, 13C, 129Xe and 31P.</description>
      <description type="deliveryMethod">offline</description>
      <rights>
        <accessRights type="conditional">Access restrictions to machine and research data based on terms and conditions set by the facility.</accessRights>
      </rights>
      <identifier type="handle">1959.4/004_2119</identifier>
      <location dateFrom="2017-05">
        <address>
          <physical type="streetAddress">
            <addressPart type="text">Lowy Cancer Research Centre (C25), PC2 Laboratory basement level, University of New South Wales, Sydney NSW 2052</addressPart>
          </physical>
          <electronic type="url">
            <value>http://www.analytical.unsw.edu.au/facilities/bril/imaging/instruments/bruker-biospec-avance-iii-9420-preclinical-mri</value>
          </electronic>
          <electronic type="email">
            <value>bril@unsw.edu.au</value>
          </electronic>
        </address>
        <spatial type="kmlPolyCoords">151.235500,-33.916600</spatial>
      </location>
	  <relatedObject>
	    <key>hdl:1959.4/004_365</key>
	    <relation type="produces"/>
	  </relatedObject>
	  <relatedObject>
	    <key>http://nla.gov.au/nla.party-593921</key>
	    <relation type="isManagedBy"/>
	  </relatedObject>
      <subject type="anzsrc-for">1103</subject>
      <relatedInfo type="website">
        <title>Bruker BioSpec Avance III 94/20 Preclinical MRI</title>
        <identifier type="uri">http://www.analytical.unsw.edu.au/facilities/bril/imaging/instruments/bruker-biospec-avance-iii-9420-preclinical-mri</identifier>
      </relatedInfo>
      <relatedInfo type="website">
		<title>Technical details</title>
        <identifier type="uri">http://www.bruker.com/products/mr/preclinical-mri/biospec/technical-details.html</identifier>
      </relatedInfo>
    </service>
  </registryObject>

Change history

Click here to view...

Date	Change history
April 2010	Consultation draft
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. New table providing an overview of schema requirements for services added to replace the Metadata Content Requirements page on the ANDS website. Providing a title now mandatory in the RDA Registry.
4 Dec 2018	Added new Service types to reflect updates to the RIF-CS vocabs (v1.6.3). Removed AccessPolicy from the list of Metadata for Service Records following its deprecation.
11 Apr 2019	Added information about the new Service Discovery tool in the RDA Registry (Release 31). Added a link to the ARDC Best Practice Guide for Metadata for Services.