Final Report Summary - CHARME (Characterisation of metadata to enable high-quality climate applications and services)
Executive Summary:
The CHARMe project, which started in January 2013, was an EC funded collaborative project between nine partners: the University of Reading, Airbus Defence & Space (formerly Infoterra), STFC, DWD, ECMWF, KNMI, CGI (formerly Logica), TerraSpatium (formerly SIH) and the UK Met Office.
The CHARMe project provides a platform for data providers and users to share and annotate commentary metadata improving the amount and quality of information that can be discovered about climate data, and helping users to decide whether a dataset will meet their needs.
It harnesses Semantic Web and Linked Data technologies, to generate machine readable commentary which can be interpreted by humans and automated software. A generic Open Annotation (OA) web data model enables data to be universally shared using a unique Digital Object Identifier (DOI) or URL.
The CHARMe system comprises of a central node, at STFC, UK and java script based client software (CHARMe plugin) which is installed locally on a data providers site.
The CHARMe system can be accessed via the CHARMe plugin at ECMWF, DWD and KNMI.
Airbus have installed their own CHARMe node for Copernicus Quality Control purposes. This node is separate from the node installed at STFC.
The option of federated CHARMe nodes has been raised but was deemed to be out of scope for this project, but could potentially be achieved with further funding.
Addditional tools were developed alongside the core CHARMe system to provide exemplars of how the CHARMe commentary metadata could be exploited.
SEVT – a tool developed at ECMWF and using ECMWF's events database. CHARMe commentary can be appended to significant events.
CHARMe maps – commentary can be applied to a particular part of a dataset. Note this CHARMe maps is a prototype only.
CHARMe has been installed on the test ESGF (Earth System Grid Federation) platform. The ESGF frontend software is in a state of transition as of the time of writing. Over the next few months this will be replaced by a new portal application called CoG (https://earthsystemcog.org/projects/cog/(s’ouvre dans une nouvelle fenêtre)). However, working in collaboration with the CoG development team it is expected that the CHARMe plugin will be integrated with this new front end system.
The ESA CCI portal tender raises CHARMe, as one of the projects in particular to cooperate with, in order to capitalise results and contribute to a system of best practice within the climate community.
NASA JPL have also been interested in CHARMe for incorporation into Obs4MIPS.
The consortium has achieved the project's core aims and objectives. (As agreed with the project officer, some deliverables were ammended due to an adaptation in the processes to allow us to reach our final technical solution).
Our Data Provider partners have put CHARMe into operation at their own sites and there is a great deal of interest both at European and International level.
There is potential further work that could be undertaken to expand the CHARMe system and add additional features. This would, however, need additional external funding.
Project Context and Objectives:
Introduction:
A major difficulty faced by users of climate data is how to judge whether the data are fit for purpose. This is a serious barrier to widening the use of climate data by non-expert users. Different users require different information, such as reports on validation campaigns, the robustness of the algorithms used, and the data policy. We term this information ‘Commentary' metadata. Much work has been done on producing aspects of Commentary metadata, but there is as yet no robust and consistent mechanism to link it to the datasets themselves.
This project entitled “CHARMe” - Characterization of metadata to allow high-quality climate applications and services - will provide these essential links.
The aim of the CHARMe project was to create a repository of Commentary metadata (hosted by CHARMe or elsewhere) plus a set of interfaces through which users can interrogate the information over the Internet. The project also aimed to build some example applications that show the value of exploiting this information in real scientific problems.
Scope of commentary metadata:
For this project, we define the scope of Commentary metadata to include:
• Post-fact annotations, e.g. citations, adhoc comments and notes;
• Results of assessments, e.g. validation campaigns, intercomparisons with models or other observations, reanalysis, quantitative error assessments;
• Provenance, e.g. dependencies on other datasets, processing algorithms and chain, data source.
• Properties of data distribution, e.g. data policy and licensing, timeliness (is the data delivered in real time?), reliability;
• External events that may affect the data, e.g. volcanic eruptions, El Nino index, satellite or instrument failure, operational changes to the orbit calculations.
This definition encompasses both quantitative and non-quantitative metadata.
For instance, a user who wishes to develop commercial applications based on satellite data might be interested in the whether the data can be obtained in real time, whether there are license restrictions on its use, and whether there is a commitment to keep supplying the data in the future. A scientist might be interested in which algorithm was used in processing the data, what other datasets were used in getting to this product, and whether papers have been published on the data.
Where scientists have carried out assessments of the data, e.g. through validation campaigns, intercomparisons or statistical analysis, assertions can be made about the quality of the dataset, with reference to the methods used to derive the statements, following the principles of QA4EO. These assertions on quality, together with descriptions of the work carried out (both are examples of Commentary metadata) may be written up as journal articles or technical reports, and should be unambiguously linked to the data they refer to.
Although many types and sources of Commentary metadata currently exist, the mechanism to do the unambiguous linking to the data is not in place. Although readers of a journal article may (if the data are properly referenced) be able to find the data under consideration, finding all reports and comments on a particular dataset is much more difficult, and in many cases impossible.
Real experience of these different user needs is found in the Satellite Applications Facility on Climate Monitoring (CM SAF). The EUMETSAT Satellite Application Facility on Climate Monitoring (CM SAF) provides long time series of Essential Climate Variables (ECVs) derived from meteorological satellites. The focus of this activity is on components of the atmospheric water and energy cycles (therefore including: cloud properties, atmospheric water vapour, surface and radiation). However, different types of users are interested in different products. For example, the CM SAF product on surface incoming solar radiation is frequently used by users from the renewable energy sector (as for example in the Photovoltaic Geographical Information System (PVGIS) of the Joint Research Centre of the European Commission: http://re.jrc.ec.europa.eu/pvgis/(s’ouvre dans une nouvelle fenêtre)) whereas a typical application of the atmospheric water vapour product is the validation of climate models.
These different types of users have different requirements for data formats and accompanying metadata. Scientists in climate research are typically able to extract the required information from the detailed documentation and can handle complex data formats, whereas users from other disciplines typically prefer to access the data with easy-to use tools, either by direct web-access or in their Geographical Information Systems. For these users, the development of a standardized simple approach, which allows the delivery of all the meta-information relevant for their application will significantly contribute to the appropriate usage of the data. The development of a standardized ‘climate service’ (that should include standardized ways of delivering relevant metadata) is therefore most relevant for such ‘downstream’ users. The priority of developing such services might therefore be higher for products that are used by ‘non-scientific’ users, who are typically most interested in near-surface parameters.
The CHARMe project is not attempting to alter the entire approach, formats and standards used by the climate and EO community, but we will engender a different way of working so that the vital Commentary metadata and archival practices can be understood from a common perspective; allowing users (from whatever origin) to be able to understand and choose data appropriate to their needs. We need to enable both data providers and data consumers to share Commentary information about resources, whether local or remote, and facilitate the recording of this information alongside the data, however it is accessed. The CHARMe concept would provide the user community with a means of finding datasets that are fit for purpose, as well as serving the scientific community with tools for the inter-comparison of metadata records and best practice for their maintenance and generation.
The main objectives of the project were to build:
• robust and reusable frameworks for linking datasets with Commentary metadata, wherever it is held;
• reusable software tools that allow climate scientists and users to exploit this information in their own applications;
• development of best-practice procedures for owners of data archives to exploit these innovations to maximum effect;
• improved search, intercomparison and time-series analysis tools for large and diverse datasets.
The project consortium encompassed data providers, scientists, and developers of future climate services, who participate in major European investments such as Copernicus, ERA-Clim, ESA's Climate Change Initiative, the Climate Satellite Applications Facility and EURO4M.
This partnership is uniquely qualified to ensure that the CHARMe system is suited to the needs of diverse user groups, and that existing investments are levered to maximum effect.
The CHARMe project is specifically concerning itself with climate data, however the data model is flexible to accommodate further adaptation by other research areas.
Project Results:
Prior to any scientific developments, a user requirements exercise was performed as well as a review of existing technology and a gap analysis.
User Requirements:
All partners contributed to this exercise by distributing user questionnaires, participating in the user workshop, adding to the user requirements and actively participating in WP300 discussions on the wiki and via teleconference. The outcome of this task is recorded in D300.1 User Requirements Document.
To accomplish this task, we firstly gathered user inputs from a wide range of communities from different scenarios and countries via user questionnaires and a user workshop held in Reading in March 2013.
We combined these inputs with previous experience of the CHARMe partners and advice from our advisory panel, thus elaborating a comprehensive set of use cases. These were later derived into individual user requirements and recorded in D300.1. This document was open to new user requirements that might be found in later stages of the project.
The user workshop was very helpful to accomplish this task, giving the partners the chance to meet face to face with potential CHARMe users through several brainstorming sessions. During these sessions, users expressed their relationship with the data (data providers, climate modellers, commercial users, IT management for climate data, etc.). We discussed with them about how they judge fitness-for-purpose and what specific supporting information is needed in order to make this judgement.
The workshop was very worthwhile and produced important output, including the addition of two new use cases we didn't think of initially, and a large number of suggestions that are out of scope but have been recorded in case we can include more functionality to the project.
There was a great deal of consensus between the outcomes of the user workshop and the comments we got from the user questionnaires. These questionnaires were distributed to several European potential users identified by the CHARMe consortium and to several African communities.
We got back a total of 42 replies containing 101 comments from European users, and 18 questionnaires from African communities covering different scenarios. Most of the feedback covered different themes: weather, climate, agriculture, water sources and ocean where the most numerous. We also received questionnaires related to disaster events, health & public safety, resources (oil, gas & mineral), renewable energy, urban design, aeronautics and IT.
The background of the authors of the questionnaires ranged from scientists and researchers to humanitarian institutions and policy makers, working in different scenarios such us seasonal forecasting, mapping of geological features, impact studies, uncertainties assessments, etc.
Report on existing technical best practice:
The research and analysis of existing technologies was performed by surveying across five areas:
1. Existing data models that capture different aspects of Commentary metadata, including ISO standards, community-specific models, the Metafor Common Information Model and GeoViQua’s information model.
2. Current and planned mechanisms for data citation, for associating Commentary metadata unambiguously with their parent dataset.
3. Best practices for linking together diverse and geographically distributed sources of information, particularly focusing on the Linked Data community.
4. A survey of existing projects that are addressing similar problems and collation of their outputs and conclusions.
5. A survey of current practice in data archives regarding the handling of Commentary metadata and related concepts such as data quality information.
The details and conclusions of this study have been documented in D300.2 Analysis of Existing Technologies. One of the highlights and recommendations from this document if the use of Linked Data, as reviewing work related has confirmed its close alignment to the objectives of CHARMe. The Open Annotation specification builds on these principles to provide a framework around which users will be able to add and link relevant information to datasets of interest.
Gap Analysis:
The purpose of this task was to guide the CHARMe project towards areas that need particular attention and innovation. An early approach to elaborate this document consisted on an in depth study of the use cases collected in WP310 identifying which technologies would be required to fulfil each of the use cases.
We found that there were several technical issues that wouldn't be discoverable through this analysis and decided to perform a technical study on the CHARMe system as a whole. The use cases imply that the CHARMe system consists of a group of technical areas: the data model, data storage, geospatial referencing, network protocols, user interface, authentication and the WP700 tools.
We studied each of these technical areas and detailed which technologies would be considered for their implementation and the foreseen gaps expected for each of them, if any. The gaps have been categorised depending on their impact (Low, Medium, High) and their type (implementation, knowledge, expertise). During this analysis, we also discovered several risks that may affect the repercussion caused by gaps, which were also included in the project's Risk Register. The study revealed a total of 15 gaps, the most challenging being related to moderation of user commentary, initial population of the CHARMe Database and mechanism for user authentication/authorization.
The solutions chosen as a result of this initial analysis was to adopt a Linked Data approach for CHARMe and use Open Annotation (OA) as an overall framework, as discussed in D400.1. A summary of which is presented below.
OA is concerned with the annotation of data with additional information.
[The following section uses the open annotation naming convention e.g. "oa:" followed by class information e.g. "oa:Motivation"]
Core to the model are these basic concepts:
• target – the subject of an annotation
• body – a comment, classification or another resource which is to be associated with the target
• annotation - the conceptual linkage between the two
Body and target can be typed but the model deliberately avoids defining explicit types for these. This allows flexibility since for example the body of one annotation may be the target of another.
This enables the building of a chain of linked annotations much in the same way as a discussion thread used on mailing lists or web forums.
A number of other variations are possible to meet different requirements: a given annotation can have more than one target, more than one body or even no body at all. Target and bodies may be as simple as links to existing web-based resources such as documents, images or datasets for example, or can be new objects created for the annotation. The obvious example is an annotation that is a comment about a given target. Here the annotation body contains the comment text. More complex associations may be made via Specifiers, a means of describing a subset of a given resource.
The oa:Annotation class enables the association of metadata including provenance data and a controlled vocabulary to identify the motivation for creating the annotation. This is extended in the case of tagging. This enables annotations to be classified, associating them with a given text keyword or term from a vocabulary specified in the annotation body.
Analysis of Information Types:
An analysis of the types of information to be supported provided a basis for the model. This was drawn from the following sources:
1. The proposal document: initial analysis to address the project call
2. D300.2 Analysis of Existing Technical Solutions
3. The User Requirements Document (URD)
4. Results from discussions with the project partners and requests for feedback
( they were requested to list the types of grey literature that they wish to include in the system.
Gathering these various sources together, it showed that regarding the content:
• Nearly all the types of information identified were external to the CHARMe system and already in existence (e.g. datasets, instrument information, validation reports, operation reports, etc).
• The majority of information types are unstructured
• Significant Events are notable in that they are new, likely to be structured and could be stored internally within a CHARMe node.
Building on Linked Data principles , the first requirement for these information types is that instances MUST be HTTP URIs, enabling them to be uniquely identified and resolved. For structured content, a second question arises regarding their serialisation. Representation as RDF enables further possibilities for linking and discovery within CHARMe and other similar systems. However, the potential benefits needed to be weighed carefully against the implementation effort especially with large legacy systems.
These examples could equally form bodies or targets for annotations.
Open Annotation provides the framework for expressing relationships for the information types identified above.
There are key properties that are common to all annotations. They are associated with the oa:Annotation class.
Motivations, provenance, authorship, creating agent, management of modification and deleting of annotations.
Motivations provide important context information answering the question why a given annotation was created. The model provides a class oa:Motivation derived from skos:Concept. A controlled vocabulary defines the possible motivations. These are applicable in the context of CHARMe.
Provenance includes the authorship of annotations and the creating agent, the associated date/times for creation and also, versioning information.
Considering authorship, the OA model allows for an oa:annotatedBy property of an annotation. OA stipulates that there should be at least one oa:annotatedBy but there may be none or more than one. For CHARMe, there must be one or more authors and this is expressed with FOAF (Friend of a Friend). This is expected to be individual users in which case the foaf:Person class should be used. However, there are cases where foaf:Organization is more appropriate, for example, for bulk creation of annotations by a program at a data provider site.
• foaf:name is used as the descriptive, human readable identifier. This is not guaranteed to be unique.
• foaf:mbox - an e-mail address may be provided as a contact for the user. For reasons of user privacy this is not mandatory.
The URI for the Person object provides a unique identifier.
The nature and requirements for author information have been arrived at after careful consideration. The system needs to be able to attribute authorship and notify users of changes to annotations. The model should also strike a balance between measures to prevent misuse of the system but it should also protect user privacy. Handling of e-mail addresses is key:
• Users provide their e-mail address to the CHARMe node on registration with the CHARMe node. They do so optionally in order that they can be notified of changes to annotations they have authored. This information is private and only for the purpose of allowing the node to notify the author of changes.
• When a given author creates a new annotation, they can optionally provide an e-mail address for inclusion in the oa:annotatedBy foaf:Person object. This information is public. They provide this to give other users a contact point associated with that annotation. This could be for example an e-mail address for a helpdesk where others users can make further enquiries.
When a new annotation is submitted, the node sets a unique URI for the foaf:Person object submitted by the client. This acts as a primary key between the node’s internal user records and the annotations submitted enabling a direct link between annotation author and their e-mail address.
The second aspect of provenance to consider, the creating agent can be captured with the oa:serializedBy property. This can be used to set metadata for the software agent creating or updating a given annotation and can provide useful contextual information.
Management of Modification and Deletion of Annotations
The ability to modify or delete existing annotations is an important requirement particularly, for example if a user submits an annotation and realises that they have made a mistake and wish to correct it or if a moderator wishes to delete inappropriate material.
CHARMe organises data in a node into two main graphs named submitted and retired. New annotations are added to the submitted graph. When a request is made to delete an annotation it is re-assigned from the submitted to the retired graph. The annotation is effectively retained in the triple store but is moved to a separate graph to indicate its new status.
Modification of an annotation presents some challenges semantically. Should an existing annotation be modified, it potentially now has a completely new meaning and context. This has implications for other annotations or nodes that reference it. Imagine an annotation A created by user Alice asserting that a given dataset has an incorrect calibration. User Ben comments on this annotation and refutes this with a comment in annotation B. Alice then realises that she has made a mistake and modifying annotation A, changes the body text to correct it. However, Ben's annotation still remains and makes no sense now since it was based on Alice's original assertion, not on the corrected version of the annotation.
In order to enable traceability, a modification operation creates a new annotation in the submitted graph and moves the annotation it replaces to the retired graph. This addresses the case above where an annotation is modified which has already been deleted. Ben's annotation still points to the deleted annotation that he originally commented on. However, it now has a deleted status so it is clear that it has been superseded by a new version.
This still leaves the problem of how to trace between a modified annotation and the one it replaced.
Open Annotation has a provenance model that applies a simplified approach to the PROV-O model from which it derives.
(For background - PROV-O provides a set of classes, properties, and restrictions that can be used to represent and interchange provenance information generated in different systems and under different contexts. It can also be specialized to create new classes and properties to model provenance information for different applications and domains).
It is possible to set an oa:annotatedBy predicate to an annotation but if an annotation is a modified version of an original, there is no way to represent this with Open Annotation. Since Open Annotation uses PROV-O, though the latter can be readily exploited to represent provenance information associated with a change or modification:
The new annotation can be identified as a modification since it has a prov:wasRevisionOf predicate pointing to the deleted annotation it replaces. The deleted annotation likewise can be identified as a deletion with the prov:wasInvalidatedBy predicate. This predicate points to the activity of modifying the annotation rather than directly back to newAnno1. In this way it is possible to differentiate between a deleted annotation and one that has been deleted as the result of a modification. In the case of the latter, the modifying activity points back to the new annotation via prov:generated. In addition, author information – via FOAF - and creation time can be added to the modifying activity – using prov:startedAt and prov:endedAt predicates.
Core annotation types:
Text-based Annotations, citations
Text-based Annotations
This is the simple case where a user writes a free text comment about a given target. The text is created and attached as a new annotation body. Unstructured plain text is stored as cnt:ContentAsText. Structured content is also possible via cnt:ContentAsXML for representing for example XHTML.
Citation
A natural extension of the concept of a document linking to a dataset is a paper citing a dataset. Here we use the CiTO ontology together with OA to express this relationship in more concrete terms:
CrossRef and DataCite provide standardised metadata for DOIs. This information can be linked via the sameAs relationship matching with the paper’s DOI included in the CitationAct cito:hasCitingEntity property. Although the information is available directly from the DOI, we cache this in the CHARMe repository to avoid the need to explicitly pull the information from an external source on subsequent requests.
Rather than represent independent citation and annotation objects, the citation object is both an oa:Annotation and a cito:CitationAct. It has predicates for both. In this way it is compatible with reasoners that are aware of either of the two models.
An extension of the model was required for WP700 (CHARMe applications) to include new information types and profiling to define the particular scope or domain of use.
Work package 700 provided a starting point from which to evaluate the model against practical use cases. ( CHARMe Maps, Significant Event Viewer, Faceted search). These are not exhaustive and further use cases are expected outside the scope of the current project as the system is deployed and developed into the future.
Software development.
The software development cycle was different from what was originally planned. An iterative approach was used to prove the basic concepts, rather than a standard waterfall approach. This also ensured that any issues regarding integration with the Data Providers websites and datasets was discovered early on in the process.
This early integration also assisted the data model development in that specific concerns were highlighted and could be accommodated with enough time for resolution.
The WP200 steering group was used as the decision making body of the development and integration, with ECMWF representing the project data providers.
First trial: June 2013. CHARMe Node based on Apache Jena with Django frontend UI. Demonstrated ability to add text-based and URI-based annotation bodies. Basic Javascript UI enables annotations to be made from datasets displayed in a PyDAP application.
Iteration 1: September 2013. Node and more fully featured plugin. UC-102 (view commentary metadata for a dataset), supporting free text, URI-based and citations only. This was mainly to prove working process and technical knowledge sharing process. JSON-LD web service interface between Javascript client plugin and CHARMe node.
Iteration 2: October 2013. Node and Plugin. Further development of use cases.
Iteration 3: February 2014. Node and Plugin. This iteration was aimed at providing a version suitable for test integration.
Iteration 4: June 2014. Node and plugin. Iteration 4 mainly focuses on the integration of the faceted search.
Iteration 5: September 2014. Node and plugin. Enhancements for faceted search. Support for annotations with multiple targets. Node admin updates.
Iteration 6: December 2014. Node and plugin. Additional features added including modification and deletion. Several bugs fixed.
Iteration 7: January 2015. Node and plugin. Moderation fully implemented and annotation on annotation feature.
At the end of this cycle, the project had completed the main feature list necessary for the data providers to be able to put the CHARMe system into general operation.
Going forward, CGI have agreed to maintain the current codebase of the Java script plugin. STFC have also agreed to support the CHARMe node software. This level of support is on a reasonable endeavours basis. Any new functionality will need to come from additional funding sources, beyond the scope of the CHARMe 2 year project funding.
A diagram showing the CHARMe node architecture plus interfaces is attached as a PDF to the final report.
Open Annotation was used as a way to meet the design requirements of the CHARMe system. One of the main aims of the project was about expanding the access to datasets and providing tools that could assist the community in achieving this.
By ensuring that the CHARMe node and Java script plugin code is Open Source based, it fulfils this aim.
The CHARMe node and Java script plugin are released under a BSD licence, enabling further development of code by the research community
Data & Usage policy:
For the central node/ distributed Java script plugin system, we determined a usage policy describing acceptable behaviour and informing the user of any consequences as a result of malicious action.
Also for data protection reasons, as the CHARMe node (hosted at STFC on the JASMIN system) was storing email addresses, the CHARMe user had to be informed of this. Details are included below:
“Data Protection:
On registering with the CHARMe node, STFC will store your email address. The username you select will be made public. Your email will also be made public, if you have selected this option in your user profile.
The annotation data will be stored at STFC, however STFC are not responsible for the content of the annotation nor for any comments/ views held therein.
Inappropriate content will be reported to the moderators. Users who abuse the Usage Policy Appendix A1.2 may have their accounts barred/ removed.
Usage Policy:
By registering with the CHARMe node, you are agreeing to be held responsible for the information you provide and confirming that you accept and understand the following rules of use:
• Annotations will be free from malicious, abusive or obscene comments/ links
• Annotations will not contain any links to services relating to marketing, advertising or recruitment
• All annotations reflect the views of the author of the annotation. STFC will not be held responsible for the content of any annotation.
• The author of an annotation retains the copyright of his/her annotation.
• Any user who attempts to cause technical problems for the system will be reported to the moderator and will be barred.
• STFC reserves the right to store the annotations and make available to other users according to this Usage Policy.
• The author grants STFC permission to, without changing content, translate the data to any medium or format for the purpose of future preservation and accessibility.
Note that
• the CHARMe node is not responsible for maintaining the permanence of URL’s. The CHARMe node shall not monitor for permanence of URLs or broken links.
• STFC accepts no responsibility for the network connection between the CHARMe node and the CHARMe plugin.
These rules are not exhaustive and the CHARMe moderators reserve the right to edit/delete annotations and/ or take other actions as necessary in order to maintain the operation and availability of the CHARMe system. “
Potential Impact:
Impact:
All too often, users have to go through each dataset in order to find the right dataset for their needs. There are many instances where the same problems are found and nowhere to report them. With the CHARMe commentary system, users have a facility to feed this information back to the scientific community and the data providers themselves to enable a more efficient search of data archives.
New users may be able to determine quicker the optimal dataset for their purposes, through the benefit of crowd sourcing. Having a known place to start can make the initial foray into a data providers archives less daunting.
User commentary information itself may not be all that is required, however. It may be that additional information is needed to better assess a datasets fitness for purpose. That is why the CHARMe system’s ability to attach supporting documentation to a dataset is a very valuable feature. Information regarding provenance, results of calibration or data policy and licencing issues can be directly linked to the dataset itself. This powerful feature effectively connects the dataset to the “web of knowledge”. In using open source and linked technology, the metadata information is computer readable and searchable and could provide the ground work for further potential developments.
As an exemplar of how this data can be used and manipulated, the CHARMe maps tool has been developed. This uses the CHARMe system to enable uses to comment on a geospatial level. Users can determine an area on a map and insert commentary relevant to a specific area.
With increasing investments seen in visualisation tools, CHARMe Maps has proven that the CHARMe system has the flexibility to cope with different methods of data representation.
Conferences and poster sessions:
The CHARMe consortium has been very active in spreading the information about the CHARMe concept around its host institutions, collaborative institutions and new and external conferences. This can be seen in the list of outreach activities at the end of the report.
The presentations and poster sessions were targeted at scientists, policy makers, consultants, new and existing users alike to target the climate data users.
Initially the outreach consisted of informing the community of our intentions and aims. As the project advanced, however, we were able to show video demonstrations of test systems and more detail on the way the data model enabled the user commentary to attach to datasets.
Our Greek partner, TerraSpatium have also engaged with Greek Data Providers who are very interested in the CHARMe system and keen to see it in operation.
Outreach was also directed at the data informatics community as well.
Engagement was undertaken with the Open Annotation community – CHARMe was represented at the Open Annotation conference and W3C in the USA. The CHARMe data model was not a proven data model at the start of the project, thus several discussions were undertaken between STFC and OA experts to confirm the data model concept and direction.
Links to European projects have also proved very valuable. The CORE-CLIMAX co-location meetings have kept the project informed of the various initiatives that are being undertaken at the moment within the EC climate research arena and many of the projects also assisted in CHARMe’s final seminar – how to apply CHARMe in these initiatives to “Share our collective expertise” eg in CLIP-C and QA4ECV.
We have also appreciated being invited to the CCI co-location meetings and having the opportunity to present CHARMe to the CCI teams.
The project advisors have had a very important role in the project. Having John Bates, Mark Dowell and Joerg Schulz advise from a European and US perspective has moved the project in the right direction and provided a high level of support in the climate research fora. Paolo Manghi’s data informatics background also ensured we had representation from a technology perspective. This was important as we were working with a concept which was, on the whole, new to the project team.
CHARMe demonstrations:
Video demonstrations were an important part of the outreach. Being able to see the software system in action can often explain a system quicker than pages of description. Video demonstrations were made by CGI from iteration 2 onwards to assist in the outreach.
Video demonstrations and access to a CHARMe test system were used at the Darmstadt Climate Symposium in October 2014. The CHARMe project was able to use a dedicated exhibition stand to demonstrate the CHARMe system, rather than a static poster. This generated a lot of interest and support.
Our final outreach consisted of a CHARMe launch and seminar, hosted at ECMWF.
The CHARMe launch showed the CHARMe system (icon) in place at various data provider sites. ECMWF displayed the ERA-CLIM datasets with the CHARMe icon on its webpage and also described the Significant Event Viewer Tool, with the CHARMe icon embedded in the screen. DWD showed their CM SAF screenshots displaying the CHARMe icon. DWD also showed the CHARMe maps tool, which they have configured to allow side by side comparison of datasets and metadata. The CHARMe icon was also visible in KNMI’s live link to their ECA&D website.
Airbus presented a different configuration of the CHARMe system. Airbus are using their own dedicated CHARMe node for Copernicus Quality Control purposes. This is an internal node and commentary metadata is not shared outside of Airbus. This could change in the future, as the possibility to federate multiple CHARMe nodes was discussed, but was considered out of scope for this 2 year project.
The final seminar looked at the direction from GCOS and guidance from advisory bodies including the strategy document “Strategy towards and Architecture for Climate Monitoring from Space” and questioned how we could apply CHARMe in EC initiatives to “Share our collective expertise”.
To summarise, CHARMe has shown its relevance now to data providers but has also has a place in an era where the availability of and the use of climate data is set to expand.
The ESA CCI portal tender raises CHARMe, as one of the projects in particular to cooperate with, in order to capitalise results and contribute to a system of best practice within the climate community.
CHARMe is also relevant to future Copernicus Climate Services; being able to make sense of "Big Data" and provide not only a user feedback interface but a system whereby the metadata is machine readable, meets both the demands for greater community interaction and ease of data manipulation.
The CHARMe system is already being used by Airbus for Copernicus Quality Control. It seems a logical step to expand the CHARMe concept to become a core infrastructure requirement to future Copernicus Climate Services.
List of Websites:
The external CHARMe website is www.charme.org.uk
Contact: Project Coordinator - Rhona Phipps,
Department of Meteorology,
University of Reading,
Earley Gate, Reading RG6 6BB, UK
r.a.phipps@reading.ac.uk
The CHARMe project, which started in January 2013, was an EC funded collaborative project between nine partners: the University of Reading, Airbus Defence & Space (formerly Infoterra), STFC, DWD, ECMWF, KNMI, CGI (formerly Logica), TerraSpatium (formerly SIH) and the UK Met Office.
The CHARMe project provides a platform for data providers and users to share and annotate commentary metadata improving the amount and quality of information that can be discovered about climate data, and helping users to decide whether a dataset will meet their needs.
It harnesses Semantic Web and Linked Data technologies, to generate machine readable commentary which can be interpreted by humans and automated software. A generic Open Annotation (OA) web data model enables data to be universally shared using a unique Digital Object Identifier (DOI) or URL.
The CHARMe system comprises of a central node, at STFC, UK and java script based client software (CHARMe plugin) which is installed locally on a data providers site.
The CHARMe system can be accessed via the CHARMe plugin at ECMWF, DWD and KNMI.
Airbus have installed their own CHARMe node for Copernicus Quality Control purposes. This node is separate from the node installed at STFC.
The option of federated CHARMe nodes has been raised but was deemed to be out of scope for this project, but could potentially be achieved with further funding.
Addditional tools were developed alongside the core CHARMe system to provide exemplars of how the CHARMe commentary metadata could be exploited.
SEVT – a tool developed at ECMWF and using ECMWF's events database. CHARMe commentary can be appended to significant events.
CHARMe maps – commentary can be applied to a particular part of a dataset. Note this CHARMe maps is a prototype only.
CHARMe has been installed on the test ESGF (Earth System Grid Federation) platform. The ESGF frontend software is in a state of transition as of the time of writing. Over the next few months this will be replaced by a new portal application called CoG (https://earthsystemcog.org/projects/cog/(s’ouvre dans une nouvelle fenêtre)). However, working in collaboration with the CoG development team it is expected that the CHARMe plugin will be integrated with this new front end system.
The ESA CCI portal tender raises CHARMe, as one of the projects in particular to cooperate with, in order to capitalise results and contribute to a system of best practice within the climate community.
NASA JPL have also been interested in CHARMe for incorporation into Obs4MIPS.
The consortium has achieved the project's core aims and objectives. (As agreed with the project officer, some deliverables were ammended due to an adaptation in the processes to allow us to reach our final technical solution).
Our Data Provider partners have put CHARMe into operation at their own sites and there is a great deal of interest both at European and International level.
There is potential further work that could be undertaken to expand the CHARMe system and add additional features. This would, however, need additional external funding.
Project Context and Objectives:
Introduction:
A major difficulty faced by users of climate data is how to judge whether the data are fit for purpose. This is a serious barrier to widening the use of climate data by non-expert users. Different users require different information, such as reports on validation campaigns, the robustness of the algorithms used, and the data policy. We term this information ‘Commentary' metadata. Much work has been done on producing aspects of Commentary metadata, but there is as yet no robust and consistent mechanism to link it to the datasets themselves.
This project entitled “CHARMe” - Characterization of metadata to allow high-quality climate applications and services - will provide these essential links.
The aim of the CHARMe project was to create a repository of Commentary metadata (hosted by CHARMe or elsewhere) plus a set of interfaces through which users can interrogate the information over the Internet. The project also aimed to build some example applications that show the value of exploiting this information in real scientific problems.
Scope of commentary metadata:
For this project, we define the scope of Commentary metadata to include:
• Post-fact annotations, e.g. citations, adhoc comments and notes;
• Results of assessments, e.g. validation campaigns, intercomparisons with models or other observations, reanalysis, quantitative error assessments;
• Provenance, e.g. dependencies on other datasets, processing algorithms and chain, data source.
• Properties of data distribution, e.g. data policy and licensing, timeliness (is the data delivered in real time?), reliability;
• External events that may affect the data, e.g. volcanic eruptions, El Nino index, satellite or instrument failure, operational changes to the orbit calculations.
This definition encompasses both quantitative and non-quantitative metadata.
For instance, a user who wishes to develop commercial applications based on satellite data might be interested in the whether the data can be obtained in real time, whether there are license restrictions on its use, and whether there is a commitment to keep supplying the data in the future. A scientist might be interested in which algorithm was used in processing the data, what other datasets were used in getting to this product, and whether papers have been published on the data.
Where scientists have carried out assessments of the data, e.g. through validation campaigns, intercomparisons or statistical analysis, assertions can be made about the quality of the dataset, with reference to the methods used to derive the statements, following the principles of QA4EO. These assertions on quality, together with descriptions of the work carried out (both are examples of Commentary metadata) may be written up as journal articles or technical reports, and should be unambiguously linked to the data they refer to.
Although many types and sources of Commentary metadata currently exist, the mechanism to do the unambiguous linking to the data is not in place. Although readers of a journal article may (if the data are properly referenced) be able to find the data under consideration, finding all reports and comments on a particular dataset is much more difficult, and in many cases impossible.
Real experience of these different user needs is found in the Satellite Applications Facility on Climate Monitoring (CM SAF). The EUMETSAT Satellite Application Facility on Climate Monitoring (CM SAF) provides long time series of Essential Climate Variables (ECVs) derived from meteorological satellites. The focus of this activity is on components of the atmospheric water and energy cycles (therefore including: cloud properties, atmospheric water vapour, surface and radiation). However, different types of users are interested in different products. For example, the CM SAF product on surface incoming solar radiation is frequently used by users from the renewable energy sector (as for example in the Photovoltaic Geographical Information System (PVGIS) of the Joint Research Centre of the European Commission: http://re.jrc.ec.europa.eu/pvgis/(s’ouvre dans une nouvelle fenêtre)) whereas a typical application of the atmospheric water vapour product is the validation of climate models.
These different types of users have different requirements for data formats and accompanying metadata. Scientists in climate research are typically able to extract the required information from the detailed documentation and can handle complex data formats, whereas users from other disciplines typically prefer to access the data with easy-to use tools, either by direct web-access or in their Geographical Information Systems. For these users, the development of a standardized simple approach, which allows the delivery of all the meta-information relevant for their application will significantly contribute to the appropriate usage of the data. The development of a standardized ‘climate service’ (that should include standardized ways of delivering relevant metadata) is therefore most relevant for such ‘downstream’ users. The priority of developing such services might therefore be higher for products that are used by ‘non-scientific’ users, who are typically most interested in near-surface parameters.
The CHARMe project is not attempting to alter the entire approach, formats and standards used by the climate and EO community, but we will engender a different way of working so that the vital Commentary metadata and archival practices can be understood from a common perspective; allowing users (from whatever origin) to be able to understand and choose data appropriate to their needs. We need to enable both data providers and data consumers to share Commentary information about resources, whether local or remote, and facilitate the recording of this information alongside the data, however it is accessed. The CHARMe concept would provide the user community with a means of finding datasets that are fit for purpose, as well as serving the scientific community with tools for the inter-comparison of metadata records and best practice for their maintenance and generation.
The main objectives of the project were to build:
• robust and reusable frameworks for linking datasets with Commentary metadata, wherever it is held;
• reusable software tools that allow climate scientists and users to exploit this information in their own applications;
• development of best-practice procedures for owners of data archives to exploit these innovations to maximum effect;
• improved search, intercomparison and time-series analysis tools for large and diverse datasets.
The project consortium encompassed data providers, scientists, and developers of future climate services, who participate in major European investments such as Copernicus, ERA-Clim, ESA's Climate Change Initiative, the Climate Satellite Applications Facility and EURO4M.
This partnership is uniquely qualified to ensure that the CHARMe system is suited to the needs of diverse user groups, and that existing investments are levered to maximum effect.
The CHARMe project is specifically concerning itself with climate data, however the data model is flexible to accommodate further adaptation by other research areas.
Project Results:
Prior to any scientific developments, a user requirements exercise was performed as well as a review of existing technology and a gap analysis.
User Requirements:
All partners contributed to this exercise by distributing user questionnaires, participating in the user workshop, adding to the user requirements and actively participating in WP300 discussions on the wiki and via teleconference. The outcome of this task is recorded in D300.1 User Requirements Document.
To accomplish this task, we firstly gathered user inputs from a wide range of communities from different scenarios and countries via user questionnaires and a user workshop held in Reading in March 2013.
We combined these inputs with previous experience of the CHARMe partners and advice from our advisory panel, thus elaborating a comprehensive set of use cases. These were later derived into individual user requirements and recorded in D300.1. This document was open to new user requirements that might be found in later stages of the project.
The user workshop was very helpful to accomplish this task, giving the partners the chance to meet face to face with potential CHARMe users through several brainstorming sessions. During these sessions, users expressed their relationship with the data (data providers, climate modellers, commercial users, IT management for climate data, etc.). We discussed with them about how they judge fitness-for-purpose and what specific supporting information is needed in order to make this judgement.
The workshop was very worthwhile and produced important output, including the addition of two new use cases we didn't think of initially, and a large number of suggestions that are out of scope but have been recorded in case we can include more functionality to the project.
There was a great deal of consensus between the outcomes of the user workshop and the comments we got from the user questionnaires. These questionnaires were distributed to several European potential users identified by the CHARMe consortium and to several African communities.
We got back a total of 42 replies containing 101 comments from European users, and 18 questionnaires from African communities covering different scenarios. Most of the feedback covered different themes: weather, climate, agriculture, water sources and ocean where the most numerous. We also received questionnaires related to disaster events, health & public safety, resources (oil, gas & mineral), renewable energy, urban design, aeronautics and IT.
The background of the authors of the questionnaires ranged from scientists and researchers to humanitarian institutions and policy makers, working in different scenarios such us seasonal forecasting, mapping of geological features, impact studies, uncertainties assessments, etc.
Report on existing technical best practice:
The research and analysis of existing technologies was performed by surveying across five areas:
1. Existing data models that capture different aspects of Commentary metadata, including ISO standards, community-specific models, the Metafor Common Information Model and GeoViQua’s information model.
2. Current and planned mechanisms for data citation, for associating Commentary metadata unambiguously with their parent dataset.
3. Best practices for linking together diverse and geographically distributed sources of information, particularly focusing on the Linked Data community.
4. A survey of existing projects that are addressing similar problems and collation of their outputs and conclusions.
5. A survey of current practice in data archives regarding the handling of Commentary metadata and related concepts such as data quality information.
The details and conclusions of this study have been documented in D300.2 Analysis of Existing Technologies. One of the highlights and recommendations from this document if the use of Linked Data, as reviewing work related has confirmed its close alignment to the objectives of CHARMe. The Open Annotation specification builds on these principles to provide a framework around which users will be able to add and link relevant information to datasets of interest.
Gap Analysis:
The purpose of this task was to guide the CHARMe project towards areas that need particular attention and innovation. An early approach to elaborate this document consisted on an in depth study of the use cases collected in WP310 identifying which technologies would be required to fulfil each of the use cases.
We found that there were several technical issues that wouldn't be discoverable through this analysis and decided to perform a technical study on the CHARMe system as a whole. The use cases imply that the CHARMe system consists of a group of technical areas: the data model, data storage, geospatial referencing, network protocols, user interface, authentication and the WP700 tools.
We studied each of these technical areas and detailed which technologies would be considered for their implementation and the foreseen gaps expected for each of them, if any. The gaps have been categorised depending on their impact (Low, Medium, High) and their type (implementation, knowledge, expertise). During this analysis, we also discovered several risks that may affect the repercussion caused by gaps, which were also included in the project's Risk Register. The study revealed a total of 15 gaps, the most challenging being related to moderation of user commentary, initial population of the CHARMe Database and mechanism for user authentication/authorization.
The solutions chosen as a result of this initial analysis was to adopt a Linked Data approach for CHARMe and use Open Annotation (OA) as an overall framework, as discussed in D400.1. A summary of which is presented below.
OA is concerned with the annotation of data with additional information.
[The following section uses the open annotation naming convention e.g. "oa:" followed by class information e.g. "oa:Motivation"]
Core to the model are these basic concepts:
• target – the subject of an annotation
• body – a comment, classification or another resource which is to be associated with the target
• annotation - the conceptual linkage between the two
Body and target can be typed but the model deliberately avoids defining explicit types for these. This allows flexibility since for example the body of one annotation may be the target of another.
This enables the building of a chain of linked annotations much in the same way as a discussion thread used on mailing lists or web forums.
A number of other variations are possible to meet different requirements: a given annotation can have more than one target, more than one body or even no body at all. Target and bodies may be as simple as links to existing web-based resources such as documents, images or datasets for example, or can be new objects created for the annotation. The obvious example is an annotation that is a comment about a given target. Here the annotation body contains the comment text. More complex associations may be made via Specifiers, a means of describing a subset of a given resource.
The oa:Annotation class enables the association of metadata including provenance data and a controlled vocabulary to identify the motivation for creating the annotation. This is extended in the case of tagging. This enables annotations to be classified, associating them with a given text keyword or term from a vocabulary specified in the annotation body.
Analysis of Information Types:
An analysis of the types of information to be supported provided a basis for the model. This was drawn from the following sources:
1. The proposal document: initial analysis to address the project call
2. D300.2 Analysis of Existing Technical Solutions
3. The User Requirements Document (URD)
4. Results from discussions with the project partners and requests for feedback
( they were requested to list the types of grey literature that they wish to include in the system.
Gathering these various sources together, it showed that regarding the content:
• Nearly all the types of information identified were external to the CHARMe system and already in existence (e.g. datasets, instrument information, validation reports, operation reports, etc).
• The majority of information types are unstructured
• Significant Events are notable in that they are new, likely to be structured and could be stored internally within a CHARMe node.
Building on Linked Data principles , the first requirement for these information types is that instances MUST be HTTP URIs, enabling them to be uniquely identified and resolved. For structured content, a second question arises regarding their serialisation. Representation as RDF enables further possibilities for linking and discovery within CHARMe and other similar systems. However, the potential benefits needed to be weighed carefully against the implementation effort especially with large legacy systems.
These examples could equally form bodies or targets for annotations.
Open Annotation provides the framework for expressing relationships for the information types identified above.
There are key properties that are common to all annotations. They are associated with the oa:Annotation class.
Motivations, provenance, authorship, creating agent, management of modification and deleting of annotations.
Motivations provide important context information answering the question why a given annotation was created. The model provides a class oa:Motivation derived from skos:Concept. A controlled vocabulary defines the possible motivations. These are applicable in the context of CHARMe.
Provenance includes the authorship of annotations and the creating agent, the associated date/times for creation and also, versioning information.
Considering authorship, the OA model allows for an oa:annotatedBy property of an annotation. OA stipulates that there should be at least one oa:annotatedBy but there may be none or more than one. For CHARMe, there must be one or more authors and this is expressed with FOAF (Friend of a Friend). This is expected to be individual users in which case the foaf:Person class should be used. However, there are cases where foaf:Organization is more appropriate, for example, for bulk creation of annotations by a program at a data provider site.
• foaf:name is used as the descriptive, human readable identifier. This is not guaranteed to be unique.
• foaf:mbox - an e-mail address may be provided as a contact for the user. For reasons of user privacy this is not mandatory.
The URI for the Person object provides a unique identifier.
The nature and requirements for author information have been arrived at after careful consideration. The system needs to be able to attribute authorship and notify users of changes to annotations. The model should also strike a balance between measures to prevent misuse of the system but it should also protect user privacy. Handling of e-mail addresses is key:
• Users provide their e-mail address to the CHARMe node on registration with the CHARMe node. They do so optionally in order that they can be notified of changes to annotations they have authored. This information is private and only for the purpose of allowing the node to notify the author of changes.
• When a given author creates a new annotation, they can optionally provide an e-mail address for inclusion in the oa:annotatedBy foaf:Person object. This information is public. They provide this to give other users a contact point associated with that annotation. This could be for example an e-mail address for a helpdesk where others users can make further enquiries.
When a new annotation is submitted, the node sets a unique URI for the foaf:Person object submitted by the client. This acts as a primary key between the node’s internal user records and the annotations submitted enabling a direct link between annotation author and their e-mail address.
The second aspect of provenance to consider, the creating agent can be captured with the oa:serializedBy property. This can be used to set metadata for the software agent creating or updating a given annotation and can provide useful contextual information.
Management of Modification and Deletion of Annotations
The ability to modify or delete existing annotations is an important requirement particularly, for example if a user submits an annotation and realises that they have made a mistake and wish to correct it or if a moderator wishes to delete inappropriate material.
CHARMe organises data in a node into two main graphs named submitted and retired. New annotations are added to the submitted graph. When a request is made to delete an annotation it is re-assigned from the submitted to the retired graph. The annotation is effectively retained in the triple store but is moved to a separate graph to indicate its new status.
Modification of an annotation presents some challenges semantically. Should an existing annotation be modified, it potentially now has a completely new meaning and context. This has implications for other annotations or nodes that reference it. Imagine an annotation A created by user Alice asserting that a given dataset has an incorrect calibration. User Ben comments on this annotation and refutes this with a comment in annotation B. Alice then realises that she has made a mistake and modifying annotation A, changes the body text to correct it. However, Ben's annotation still remains and makes no sense now since it was based on Alice's original assertion, not on the corrected version of the annotation.
In order to enable traceability, a modification operation creates a new annotation in the submitted graph and moves the annotation it replaces to the retired graph. This addresses the case above where an annotation is modified which has already been deleted. Ben's annotation still points to the deleted annotation that he originally commented on. However, it now has a deleted status so it is clear that it has been superseded by a new version.
This still leaves the problem of how to trace between a modified annotation and the one it replaced.
Open Annotation has a provenance model that applies a simplified approach to the PROV-O model from which it derives.
(For background - PROV-O provides a set of classes, properties, and restrictions that can be used to represent and interchange provenance information generated in different systems and under different contexts. It can also be specialized to create new classes and properties to model provenance information for different applications and domains).
It is possible to set an oa:annotatedBy predicate to an annotation but if an annotation is a modified version of an original, there is no way to represent this with Open Annotation. Since Open Annotation uses PROV-O, though the latter can be readily exploited to represent provenance information associated with a change or modification:
The new annotation can be identified as a modification since it has a prov:wasRevisionOf predicate pointing to the deleted annotation it replaces. The deleted annotation likewise can be identified as a deletion with the prov:wasInvalidatedBy predicate. This predicate points to the activity of modifying the annotation rather than directly back to newAnno1. In this way it is possible to differentiate between a deleted annotation and one that has been deleted as the result of a modification. In the case of the latter, the modifying activity points back to the new annotation via prov:generated. In addition, author information – via FOAF - and creation time can be added to the modifying activity – using prov:startedAt and prov:endedAt predicates.
Core annotation types:
Text-based Annotations, citations
Text-based Annotations
This is the simple case where a user writes a free text comment about a given target. The text is created and attached as a new annotation body. Unstructured plain text is stored as cnt:ContentAsText. Structured content is also possible via cnt:ContentAsXML for representing for example XHTML.
Citation
A natural extension of the concept of a document linking to a dataset is a paper citing a dataset. Here we use the CiTO ontology together with OA to express this relationship in more concrete terms:
CrossRef and DataCite provide standardised metadata for DOIs. This information can be linked via the sameAs relationship matching with the paper’s DOI included in the CitationAct cito:hasCitingEntity property. Although the information is available directly from the DOI, we cache this in the CHARMe repository to avoid the need to explicitly pull the information from an external source on subsequent requests.
Rather than represent independent citation and annotation objects, the citation object is both an oa:Annotation and a cito:CitationAct. It has predicates for both. In this way it is compatible with reasoners that are aware of either of the two models.
An extension of the model was required for WP700 (CHARMe applications) to include new information types and profiling to define the particular scope or domain of use.
Work package 700 provided a starting point from which to evaluate the model against practical use cases. ( CHARMe Maps, Significant Event Viewer, Faceted search). These are not exhaustive and further use cases are expected outside the scope of the current project as the system is deployed and developed into the future.
Software development.
The software development cycle was different from what was originally planned. An iterative approach was used to prove the basic concepts, rather than a standard waterfall approach. This also ensured that any issues regarding integration with the Data Providers websites and datasets was discovered early on in the process.
This early integration also assisted the data model development in that specific concerns were highlighted and could be accommodated with enough time for resolution.
The WP200 steering group was used as the decision making body of the development and integration, with ECMWF representing the project data providers.
First trial: June 2013. CHARMe Node based on Apache Jena with Django frontend UI. Demonstrated ability to add text-based and URI-based annotation bodies. Basic Javascript UI enables annotations to be made from datasets displayed in a PyDAP application.
Iteration 1: September 2013. Node and more fully featured plugin. UC-102 (view commentary metadata for a dataset), supporting free text, URI-based and citations only. This was mainly to prove working process and technical knowledge sharing process. JSON-LD web service interface between Javascript client plugin and CHARMe node.
Iteration 2: October 2013. Node and Plugin. Further development of use cases.
Iteration 3: February 2014. Node and Plugin. This iteration was aimed at providing a version suitable for test integration.
Iteration 4: June 2014. Node and plugin. Iteration 4 mainly focuses on the integration of the faceted search.
Iteration 5: September 2014. Node and plugin. Enhancements for faceted search. Support for annotations with multiple targets. Node admin updates.
Iteration 6: December 2014. Node and plugin. Additional features added including modification and deletion. Several bugs fixed.
Iteration 7: January 2015. Node and plugin. Moderation fully implemented and annotation on annotation feature.
At the end of this cycle, the project had completed the main feature list necessary for the data providers to be able to put the CHARMe system into general operation.
Going forward, CGI have agreed to maintain the current codebase of the Java script plugin. STFC have also agreed to support the CHARMe node software. This level of support is on a reasonable endeavours basis. Any new functionality will need to come from additional funding sources, beyond the scope of the CHARMe 2 year project funding.
A diagram showing the CHARMe node architecture plus interfaces is attached as a PDF to the final report.
Open Annotation was used as a way to meet the design requirements of the CHARMe system. One of the main aims of the project was about expanding the access to datasets and providing tools that could assist the community in achieving this.
By ensuring that the CHARMe node and Java script plugin code is Open Source based, it fulfils this aim.
The CHARMe node and Java script plugin are released under a BSD licence, enabling further development of code by the research community
Data & Usage policy:
For the central node/ distributed Java script plugin system, we determined a usage policy describing acceptable behaviour and informing the user of any consequences as a result of malicious action.
Also for data protection reasons, as the CHARMe node (hosted at STFC on the JASMIN system) was storing email addresses, the CHARMe user had to be informed of this. Details are included below:
“Data Protection:
On registering with the CHARMe node, STFC will store your email address. The username you select will be made public. Your email will also be made public, if you have selected this option in your user profile.
The annotation data will be stored at STFC, however STFC are not responsible for the content of the annotation nor for any comments/ views held therein.
Inappropriate content will be reported to the moderators. Users who abuse the Usage Policy Appendix A1.2 may have their accounts barred/ removed.
Usage Policy:
By registering with the CHARMe node, you are agreeing to be held responsible for the information you provide and confirming that you accept and understand the following rules of use:
• Annotations will be free from malicious, abusive or obscene comments/ links
• Annotations will not contain any links to services relating to marketing, advertising or recruitment
• All annotations reflect the views of the author of the annotation. STFC will not be held responsible for the content of any annotation.
• The author of an annotation retains the copyright of his/her annotation.
• Any user who attempts to cause technical problems for the system will be reported to the moderator and will be barred.
• STFC reserves the right to store the annotations and make available to other users according to this Usage Policy.
• The author grants STFC permission to, without changing content, translate the data to any medium or format for the purpose of future preservation and accessibility.
Note that
• the CHARMe node is not responsible for maintaining the permanence of URL’s. The CHARMe node shall not monitor for permanence of URLs or broken links.
• STFC accepts no responsibility for the network connection between the CHARMe node and the CHARMe plugin.
These rules are not exhaustive and the CHARMe moderators reserve the right to edit/delete annotations and/ or take other actions as necessary in order to maintain the operation and availability of the CHARMe system. “
Potential Impact:
Impact:
All too often, users have to go through each dataset in order to find the right dataset for their needs. There are many instances where the same problems are found and nowhere to report them. With the CHARMe commentary system, users have a facility to feed this information back to the scientific community and the data providers themselves to enable a more efficient search of data archives.
New users may be able to determine quicker the optimal dataset for their purposes, through the benefit of crowd sourcing. Having a known place to start can make the initial foray into a data providers archives less daunting.
User commentary information itself may not be all that is required, however. It may be that additional information is needed to better assess a datasets fitness for purpose. That is why the CHARMe system’s ability to attach supporting documentation to a dataset is a very valuable feature. Information regarding provenance, results of calibration or data policy and licencing issues can be directly linked to the dataset itself. This powerful feature effectively connects the dataset to the “web of knowledge”. In using open source and linked technology, the metadata information is computer readable and searchable and could provide the ground work for further potential developments.
As an exemplar of how this data can be used and manipulated, the CHARMe maps tool has been developed. This uses the CHARMe system to enable uses to comment on a geospatial level. Users can determine an area on a map and insert commentary relevant to a specific area.
With increasing investments seen in visualisation tools, CHARMe Maps has proven that the CHARMe system has the flexibility to cope with different methods of data representation.
Conferences and poster sessions:
The CHARMe consortium has been very active in spreading the information about the CHARMe concept around its host institutions, collaborative institutions and new and external conferences. This can be seen in the list of outreach activities at the end of the report.
The presentations and poster sessions were targeted at scientists, policy makers, consultants, new and existing users alike to target the climate data users.
Initially the outreach consisted of informing the community of our intentions and aims. As the project advanced, however, we were able to show video demonstrations of test systems and more detail on the way the data model enabled the user commentary to attach to datasets.
Our Greek partner, TerraSpatium have also engaged with Greek Data Providers who are very interested in the CHARMe system and keen to see it in operation.
Outreach was also directed at the data informatics community as well.
Engagement was undertaken with the Open Annotation community – CHARMe was represented at the Open Annotation conference and W3C in the USA. The CHARMe data model was not a proven data model at the start of the project, thus several discussions were undertaken between STFC and OA experts to confirm the data model concept and direction.
Links to European projects have also proved very valuable. The CORE-CLIMAX co-location meetings have kept the project informed of the various initiatives that are being undertaken at the moment within the EC climate research arena and many of the projects also assisted in CHARMe’s final seminar – how to apply CHARMe in these initiatives to “Share our collective expertise” eg in CLIP-C and QA4ECV.
We have also appreciated being invited to the CCI co-location meetings and having the opportunity to present CHARMe to the CCI teams.
The project advisors have had a very important role in the project. Having John Bates, Mark Dowell and Joerg Schulz advise from a European and US perspective has moved the project in the right direction and provided a high level of support in the climate research fora. Paolo Manghi’s data informatics background also ensured we had representation from a technology perspective. This was important as we were working with a concept which was, on the whole, new to the project team.
CHARMe demonstrations:
Video demonstrations were an important part of the outreach. Being able to see the software system in action can often explain a system quicker than pages of description. Video demonstrations were made by CGI from iteration 2 onwards to assist in the outreach.
Video demonstrations and access to a CHARMe test system were used at the Darmstadt Climate Symposium in October 2014. The CHARMe project was able to use a dedicated exhibition stand to demonstrate the CHARMe system, rather than a static poster. This generated a lot of interest and support.
Our final outreach consisted of a CHARMe launch and seminar, hosted at ECMWF.
The CHARMe launch showed the CHARMe system (icon) in place at various data provider sites. ECMWF displayed the ERA-CLIM datasets with the CHARMe icon on its webpage and also described the Significant Event Viewer Tool, with the CHARMe icon embedded in the screen. DWD showed their CM SAF screenshots displaying the CHARMe icon. DWD also showed the CHARMe maps tool, which they have configured to allow side by side comparison of datasets and metadata. The CHARMe icon was also visible in KNMI’s live link to their ECA&D website.
Airbus presented a different configuration of the CHARMe system. Airbus are using their own dedicated CHARMe node for Copernicus Quality Control purposes. This is an internal node and commentary metadata is not shared outside of Airbus. This could change in the future, as the possibility to federate multiple CHARMe nodes was discussed, but was considered out of scope for this 2 year project.
The final seminar looked at the direction from GCOS and guidance from advisory bodies including the strategy document “Strategy towards and Architecture for Climate Monitoring from Space” and questioned how we could apply CHARMe in EC initiatives to “Share our collective expertise”.
To summarise, CHARMe has shown its relevance now to data providers but has also has a place in an era where the availability of and the use of climate data is set to expand.
The ESA CCI portal tender raises CHARMe, as one of the projects in particular to cooperate with, in order to capitalise results and contribute to a system of best practice within the climate community.
CHARMe is also relevant to future Copernicus Climate Services; being able to make sense of "Big Data" and provide not only a user feedback interface but a system whereby the metadata is machine readable, meets both the demands for greater community interaction and ease of data manipulation.
The CHARMe system is already being used by Airbus for Copernicus Quality Control. It seems a logical step to expand the CHARMe concept to become a core infrastructure requirement to future Copernicus Climate Services.
List of Websites:
The external CHARMe website is www.charme.org.uk
Contact: Project Coordinator - Rhona Phipps,
Department of Meteorology,
University of Reading,
Earley Gate, Reading RG6 6BB, UK
r.a.phipps@reading.ac.uk
