Frequently Asked Questions - Basics

What it means to switch to 1.2 and whether you should depends on your role within CLARIN. The following pages provide answers to this and other questions for various groups:

1.2 is the successor to the CMDI 1.1 metadata framework and is one of the two currently supported versions of CMDI. More information about this specific version can be found at the CMDI 1.2 page. How the introduction of CMDI 1.2 affects you depends on your role within CLARIN. Click one of the following links to find detailed information about the transition to CMDI 1.2 that is relevant to you:

There currently are two supported versions of the CLARIN's component metadata framework: 1.1 and CMDI 1.2. The former has been in active use for many years and is widely supported within the CLARIN infrastructure. CMDI 1.2 was introduced in 2016 and provides a number of new features and improvements compared to its predecessor. However, its support throughout the infrastructure is still limited (at the time of writing this FAQ, July 2016).

Therefore in order to make a decision about which version of CMDI to use, it's advised to first determine which tools you need your metadata to be processed with. More details about CMDI 1.2, including current information with respect to its support throughout the infrastructure, can be found at the CMDI 1.2 page.

The fields of a profile are fixed, so you will need to use a different profile. Don't worry, you can create your own. Since you found a profile that seems to almost match your needs, the most logical thing to do is to create a new profile based on that one.

You can do this yourself, as long as you have a way to login to the Component Registry. Click the 'login' link and select your home institute or another provider you have an account with. If none is in the list, create an account with CLARIN (more info).

When logged in, select the base profile and click the 'Edit as new' button. Save it in your private workspace (under a different name and/or group). The profile consists of links to a number of components (some of which in turn consist partially of links to components), so you will have to identify the components that you need to change. Edit these 'as new', as well and make the required changes. You may have to do this recursively for deeper hierarchies. Then, in your profile, replace the references to the original components with references to your new versions of these components. Save the profile, and test it in an editor  (e.g. oXygen or Arbil) before publishing (you can get the XSD link by selecting the profile in the component browser and choosing 'Show Info' from the drop down menu on the far right. You can open this link in an XML editor or validator; in Arbil you can add it via the 'Profiles and templates' settings.

If you want to add a link to the original context of the metadata file, e.g. to the repository where it is hosted (example), add a ResourceProxy of the type LandingPage, e.g.:

 <ResourceProxy id="lp">

This can be done with a ResourceProxy where:

  • ResourceType = SearchPage


 <ResourceProxy id="d55">

For a complete example file see:

This can be done with a ResourceProxy where:

  • ResourceType = SearchService
  • mimetype = application/sru+xml


 <ResourceProxy id="d55">
   <ResourceType mimetype="application/sru+xml">SearchService</ResourceType>

For a complete example file see:

As a starting point, see the list below. We are working to extend it.

Components with controlled vocabularies

Other components


Yes. If you tick the checkmark next to Multilingual for an element in the Component Registry, it will result in a multilingual field. With the xml:lang attribute you can then indicate the language in which an element has been described, see eg. the following fragment in this example CMDI file:

<!-- Note the support for multilingual fields, using the xml:lang attribute -->
<title xml:lang="eng">mister</title>
<title xml:lang="fra">monsieur</title>
<title xml:lang="nld">mijnheer</title>

For indicating the language we strongly advice to use the ISO-639-3 language code.

Please note that enabling Multilingual will make the element repeatable, even if the Maximum number of occurences is set to 1.

Technically there is no real difference. A profile is a component that can be converted into an XSD file. A normal component can only be used within other components or profiles and can never be transformed into an XSD.

The isProfile="true" attribute indicates that a CMD_ComponentSpec defines a profile and not just a component.

The MdProfile element (in the Header section) contains a unique profile code (e.g.: Alternatively you can also find the profile identifier as part of the schema location, for example ( 1.1):

<CMD ... xsi:schemaLocation="">

or (CMDI  1.2):

<cmd:CMD ... xsi:schemaLocation="">

You can find the profile in the component registry with the following URL:


The information that a ResourceProxy can contain (a URL and mimetype) is kept very minimal, on purpose. However you can use any component to add more details about such a ResourceProxy, using the id attribute.

E.g. in the example CMDI file we can add a textual description of the photo. First the relevant ResourceProxy gets the id "a_photo":

<ResourceProxy id="a_photo">
    <ResourceType mimetype="image/jpeg">Resource</ResourceType>
    <!-- note that both a normal URL and a handle Persistent Identifier can be used for the ResourceRef -->

Then, later on in the same CMDI file, we have an explanantory component example-component-photo with a description element:

<example-component-photo ref="a_photo">
     <description>a suitable textual description of this photo</description>

Thanks to the reference from this component to the ResourceProxy with the ref attribute we know that the description relates to the photo.

Note that the id attribute should be unique for each ResourceProxy.

Ok, so how can you refer to an external file from a metadata description? That is where the Resources section is for.

In the example CMDI file, the resources section looks like:

      <!-- List of external resource files and (CMDI) metadata files -->
         <ResourceProxy id="a_photo">
            <ResourceType mimetype="image/jpeg">Resource</ResourceType>
            <!-- note that both a normal URL and a handle Persistent Identifier can be used for the ResourceRef -->
         <ResourceProxy id="a_text">
            <ResourceType mimetype="text/plain">Resource</ResourceType>


As you can see, for each link to an external resource a ResourceProxy (= file) is added to the ResourceProxyList (= file list). For each ResourceProxy you need to specify the ResourceType:

With an optional (but very useful) mimetype attribute you can (surprise!) indicate the file's mime type. The ResourceRef contains either a normal URL or a handle PID.

Each files exists of 3 parts:

  • a (fixed) Header, containing administrative information:
  • a (fixed) Resources section, containing links to:
    • external files (e.g. an annotation file or a sound recording)
    • and/or other CMDI metadata files (to build hierarchies)
  • a (flexible) Components section, where the actual components that this profile contains will appear

This example CMDI file illustrates the use of the 3 parts.

There are multiple suitable profiles, as described in the CMDI core model for web services (and extended documentation).

See also the following paper:

Windhouwer, M., Broeder, D., & Van Uytvanck, D. (2012). A CMD core model for CLARIN web services. In Proceedings of the workshop on Describing Language Resources with Metadata: Towards Flexibility and Interoperability in the Documentation of Language Resources at LREC 2012 (pp. 41-48).

Link from the parent .cmdi file to the child .cmdi file with a ResourceProxy that has the ResourceType Metadata.

The recommended profile to use for collection description is ("Collection").

All files of this example collection can be accessed and explored via

Notice that this example is based on 1.1. The same principles apply to CMDI 1.2 in which hierarchies can be constructed in the same matter.

Below is a graphical representation (as shown by Arbil) of the CMDI file hierarchy used above as an example.

The next step is getting your metadata published in the Virtual Language Observatory. See How can I publish my metadata to the Virtual Language Observatory for detailed information.

Check out this specification document on metadata.

PLEASE NOTE: The information in this document might be partially outdated. The information on (including these FAQs) is certainly more up to date and should be considered authorative.

CLARIN proposes a component-based approach: you can combine several metadata components (sets of metadata elements) into a self-defined scheme that suits your particular needs. Of course you can share your profile with others (in fact we strongly advise that). If sharing the full profile is not an option, you still can use common components, e.g. a component to describe a sound recording. In case that still does not address your needs, it is even possible to create components yourself.

Good question. In fact, there is no such thing as a single CLARIN metadata scheme. Practice showed that using a single scheme for a large community (e.g. the Humanities) often results in a mismatch between the chosen elements and the needs of the user.

Quite a few. Examples are: Dublin Core, (which is an enriched version of Dublin Core), , the header.

A fixed set of elements for the description of resources. Think of the traditional filing cards in the library, specifying the writer and title of each book.

Metadata is data about data: information describing properties of linguistic resources, for instance the size of a corpus, the recording date of a speech file, the purpose for which annotations were created.