wiki:Centre Registry

Version 24 (modified by Thorsten Trippel, 8 years ago) (diff)

TT has write access t the centre registry, Thomas Zastrow probably not, so I exchanged him for me

Centre Registry 2.0

A current version is available on . A staging version on .


Responds to HTTP GET requests at the following paths:


Please see


restxml/: gives a list of centres including the centre ID in XML.

restxml/n, where n is a centre ID: Gives detailed information about a centre in XML that is validated with this schema:


Some services (WebLicht?) may depend on optional string-type properties of OAI-PMH endpoints that have been exported since the old API:

  • WebServiceType? is the semantic indication of the kind of webservices offered.
  • WebServicesSet? is just a name for the OAI-PMH set that contains the relevant web service metadata descriptions. It could be anything, so a harvester should be able to deal with arbitrary set names.


  • The Harvest Manager at MPI-PL
  • WebLicht? at various German CLARIN Centres especially UTU
  • Monitoring at FZJ
  • FCS Aggregator

Open Tickets

Ticket Summary Component Priority Owner Reporter
No tickets found

The Centre Registry before 2.0



  • 2012-04-11: created ticket queue for Center registry and added some HTML improvements
  • 2012-03-14: feedback to RZG developers about XML export improvements

Open Tickets

Ticket Summary Component Priority Owner Reporter
No tickets found

Technical Specification


The centers form the backbone of the distributed CLARIN infrastructure. So far the administration of the center details has been done manually, noting down the entry points and contact information on a web site. In order to streamline the information gathering and to ensure machine accessibility of this data a center registry needs to be built. In this page we specify the requirements for such a registry, in accordance with the CLARIN-D AP3 guidelines.


The center registry is a store for records with information about CLARIN centres. This document describes the data that it could contain (Data store), the web application for users to view and change the data (Web Interface) and the machine-accessible API (Web Service).

Example files

The CMDI files containing information about the CLARIN centers can be found in the SVN repository:

Data store

Each record has these fields:

Basic Information

  • name (string)
  • country (controlled vocabulary: subset of ISO 3166-2)
  • center type (controlled vocabulary: A, B, C or E)
  • center type status (0 or 1; string; to be used to describe the A/B/C/E center status)
  • core description (string; possible multiple lines containing general information on the center, e.g., the collection focus or policy)

Extended Information

  • Long term archiving policy (string)
  • CLARIN infrastructure services (0 or 1; string; meaning: non-standard offers like OAI harvesting)
  • strict versioning (boolean; meaning: 1 PID always points to 1 version)
  • repository system (string)
  • PID status (string)
  • assessment status (string)
  • website (URI)
  • references (0 or more description+URI):
    • description
    • URI, e.g., to link to an assessment reports
  • metadata (1 or more):
    • OAI access point (URI)
    • Metadata scheme (1 or more; controlled vocabulary: OLAC or CMDI)
    • Web Services Set (0 or 1; string; the OAI-PMH set that contains the webservice metadata records) - if a Web Services set is specified, 1 or more Web Service Types must be defined, otherwise there is no Web Service Type at all
    • Web Service Type (0 or more; controlled vocabulary: SOAP, REST or WebLicht?.)
  • AAI:
    • AAI status (string)
    • member of a national identity federation (0 or more; controlled vocabulary: subset of ISO 3166-2)
    • member of the CLARIN Service Provider Federation (boolean)
  • organisational information:
    • organisation details (see for an example)
    • contact information (name, email, phone) of a technical contact person
    • contact information (name, email, phone) of an administrative contact person
  • monitoring:
    • Service Provider test site (URI, link to the script)
    • (As the nagios probes will be configured at the monitoring computer center no further fields required)

Empty values shouldn’t be allowed, e.g., if the Web Services Set field is left empty it isn’t instantiated and this is the same as an instance count of zero. It is very probable that new fields will be needed in the future, so the data model should be flexible. Also it should be easy to add new values to controlled vocabularies, e.g., to add a new allowed Web Service Type.

Web interface

  • initial view: a table like with a link to the center view for each center
  • center view: display all fields of a single center
  • center editing screen: a webform to changed the values of a center
  • authorization: SAML-based, initally via the eduPersonPrincipleName attribute as received from the CLARIN IdP:
    • everyone should have read access
    • a few administrators (,, have write access

Web service

A REST-webservice returns information from the registry as:

  • JSON
  • CMDI (=XML, for the details of this format see below)

(Inspired by the web service for the Component Registry)

As the public REST-webservice is read-only no authorization should be required.

A CMDI profile has been created:

To start, the following functions should be available:

  • return a list of all centers (together with a unique center ID):
    • optional parameters: /xml (default, ad hoc xml encoding) or /json
    • output: center ID, Basic information fields, if there is at least 1 OAI access point, providing metadata about web services
  • return all information about 1 center:{centerid}
    • optional parameters: /cmdi (default) or /json
    • output: all fields in the center record

Documentation about the webservice: