Archive by Author | fkratzen

Climate Symposium in Darmstadt

The CHARMe project has been presented at the Climate Symposium in Darmstadt on 13th – 17th of October 2014. climate_symposium

The CHARMe-Project stand at the Climate Symposium was neighbored by the EUMETSAT Climate Monitoring Satellite Application Facility (CM SAF) and the ESA . The location fitted very well to attract the members of the symposium during the coffee- and lunch breaks throughout the whole week. The CHARMe-projectteam has been represented by Rhona Phipps (UoR), Alan O’Neill (UoR), Phil Harwood (CGI) and Frank Kratzenstein (DWD). With the demo-version of the CHARMe-plugin at hand, a lot of detailed and interesting discussions on the use of  commentary metadata and data models used in climate physics applications were initiated. Among others, questions like “What requirements from a data-provider point of view do we have to meet in order to use the CHARMe Service?” or “How can I run my own CHARMe Node?” or “How will the development of CHARMe be maintained after the projects’ end?” came up during those vivid conversations.

To answer the last question first, the british SCIENCE AND TECHNOLOGY FACILITIES COUNCIL (STFC) has committed itself to administer and maintain the public CHARMe Node. In addition the CHARMe Node source codes are available under an open source license as do the sources of the javascript based CHARMe-plugin and the GoogleWebToolkit based CHARMe Maps tool. Beside the STFC one of the CHARMe consortium partners is going to run its own “private” CHARMe node and therefore the CHARMe-project will deliver an Installation and an Interface Control Document for the node. And to answer the first question, according to the project guidelines there will be a publicly available deliverable document with the title “Implementation in archives”. This document will address in detail the steps the dataproviders in the CHARMe consortium like  KNMI, DWD, AirBus have undertaken to “CHARMe-enable” their data archives. In addition to this “Best Practice”-document there is an installation guide for the CHARMe plugin. One of the major “soft” targets of the project has been, to make the adaption of CHARMe as easy as possible for dataproviders. Nevertheless, you have to run through the following major steps:

– registering at a CHARMe node and claiming for a CHARMe client id

– downloading, extracting and configuring the javascript CHARMe-plugin

– editing/adjusting the web page(s) to be CHARMe-enabled

– enjoying to annotate your datasets or to get your datasets annotated


One aspect was clear: scientists and dataprovider are looking forward to use CHARMe tools and are keen to see its launching.


CHARMe as bibliographic database, part 2: SKOS

In one of our last posts I introduced the idea of using CHARMe as a bibliographic database. In this post I want to dive deeper into this topic, focusing on how to capture various specific  types of documents.
At first let’s have a look, how our local bibliographic database is currently organized and what queries we want to run against it. It turns out that our bibliographic database is a simple excel-sheet with some informal defined constraints restricting  the allowed values of some columns. The most interesting constraints for this blog, are defined on the columns DocType  and Type. The column ‘Type’ specifies the kind of DocType.document in more detail.


A common query for the bibliographic database looks like :
‘Please give me all items related to project documentation of a specific project/dataset.’or ‘Please give me all Algorithm Theoratical Basis Documents of a specific project/dataset’.
In addition to these common queries a new user requirement is, to add a new level of categorization to the ‘Types‘, in order to enable queries like: ‘Please give me all technical  items related to project documentation of a specific project/dataset.’
That leads us to the questions what are technical items and what other kind of items are to be captured? As we think about it, we come to the conclusion that we need a hierarchal order of those items. Additionally  it would be a great deal to make  these classifications and definitions publicly available, at least to our department as a kind of department vocabulary  and not to hide them inside an application.


After we have captured these fundamental requirements let’s have a look how CHARMe may help us to get on the way.
In the CHARMe project we have defined to use the FRBR-aligned Bibliographic Ontology, fabio, a publicly available and widespread used ontology. Therefore we should watch out for some fabio-classes, which we can map to our DocType and Type entries. And indeed except for DocType.document we find the following mappings:

docType:article to :


docType:presentation to :


docType:poster to :


The nearest match to docType:document might be:


And as we see the fabio:Report already has some sub-classes, but when we take a closer look into fabio:TechnicalReport we have to notice that it is leaf node in the fabio-hierachy. So we need to find a way to exend the fabio-ontology In order to cover our technical items, like the ATBD.
While finding an existing, public widespread ontology which defines the term ATBD for us would be the preferred option, in this blog we start to create our own definition/vocabulary and trying to extend fabio to our needs, by using SKOS.

SKOS, which stands for Simple Knowledge Organization System, is a W3C standard, based on other Semantic Web standards (RDF and OWL), that provides a way to represent controlled vocabularies, taxonomies and thesauri.

“The fundamental element of the SKOS vocabulary is the concept. Concepts are the units of thought —ideas, meanings, or (categories of) objects and events—which underlie many knowledge organization systems. As such, concepts exist in the mind as abstract entities which are independent of the terms used to label them.SKOS Primer

So we start by expressing (using Turtle) our ATBD as a SKOs Concept and adding some labeling information and the definition to it:

cmsaf_vocab:ATBD     rdf:type     skos:Concept;
cmsaf_vocab:ATBD     skos:prefLabel    “ATBD”;
cmsaf_vocab:ATBD     skos:altLabel     “Algorithm Theoretical Basis Document”;
cmsaf_vocab:ATBD     skos:definition     “The Algorithm Theoretical Basis Documents (ATBD) are intended to describe the physical and mathematical description of the algorithms to be used in the generation of data products. The ATBD include a description of variance and uncertainty estimates and considerations of calibration and validation, exception control, and diagnostics. In some cases, internal and external data product flows are required.”;

And to build the bridge to the fabio-Ontology we just need to add a semantic relation information between our ATBD-concept and a fabio-Class:

cmsaf_vocab:ATBD     skos:narrower     fabio:TechnicalReport .

That means by using SKOS we can build up our own classification scheme in a common data model for knowledge organization systems, with the benefits, to easily incorporate or extend an existing KOS.


But by migrating from excel to CHARMe, we also switch from relational data to graph data and from SQL to SPARQL. That means, the question ‘Please give me all technical items related to project documention of a specific project.’ becomes in pseudo SPARQL :
Select *
where {
?technical_item oa:hasTarget <uri of our project> .
?technical_item rdf:typeOf ?technical_item_type .
?technical_item_type skos:narrower+ fabio:TechnicalReport .

So there are some more steps adhead of us before we can migrate our EXCEL bibliographic database to  CHARMe, but by using fabio and SKOS one of the big chunks can be tackled.

CHARMe as a bibliographic database

In the last post we read about CHARMe as an online collaboration tool, today I want to show you another application area of CHARMe. In the context of the CM SAF at DWD, the German weather service, we are thinking of transferring our dataset related internal bibliographic database to CHARMe. In doing so, we hope to achieve a tighter linking of the gathered primary and secondary literature of a referenced dataset to its primary entity and to place that information at a more prominent location than the local intranet. At the end of incorporating this bibliographic database into CHARMe the CM SAF  users should have access to this information directly next to the dataset itself. But what are the steps of migration we have to take in order to achieve this aim? I won’t discuss those steps in detail but want to focus only on one major task: the classification of information.

As you already know CHARMe is following the principles of the Linked Data approach. One building block of this approach is applying a vocabulary, or more precisely an ontology, to the things we want to talk about. By choosing a common vocabulary or a well-known and well defined ontology, we can express our available bibliographic data in a semantic web fashioned way and in the same step they become more or less CHARMe enabled. And surprise, one of the major ontologies that’s driving CHARMe is FaBiO, the FRBR (Functional Requirements for Bibliographic Records)-aligned Bibliographic Ontology. The FaBiO gives us well-explained, hierarchal ordered terms like technical report, conference paper, web content or even blog and blog post among many others. By exploiting FaBiO we can classify our already gathered bibliographic information and make them understandable for humans and machines like CHARMe. Of cause there are some more steps to take to CHARMe-enable our internal bibliographic database but those might be covered in another post.

The message-triples of this post are:

CHARMe might be used as an online collaboration tool.

CHARMe might be used as a bibliographic database.

CHARMe uses FaBiO.

With these three pieces of information, especially the last one, a non-CHARMe machine/application got some very useful hints about what and how to query and/or link to our CHARMe-enabled bibliographic database.

Welcome to the world of the semantic web and linked data.