1. CF Conventions Support at BADC Alison Pamment Roy Lowry (BODC)

2. CF Support at BADC BADC took over responsibility for supporting CF standard names in April 2006 Funding for ½ person to act as Standard Names Manager Manager responds to all proposals for new standard names Responsible for all changes to the Standard Name Table

3. Standard Names Management (1) Proposal for new standard name is made on CF-Metadata mailing list: http://www.cgd.ucar.edu/mailman/listinfo/cf -metadata Standard names manager responds to the proposal and any other member of CF community can comment via mailing list

4. Standard Names Management (2) Sometimes there is a clear-cut case for adding a new standard name Often names require several iterations before suitable terminology can be agreed Standard Names Manager can’t be an expert in everything! ― new committee structure very important

5. Standard Names Management (3) Need to respond to ever expanding user requirements Change needs to be rapid or users lose interest Need to maintain information quality and internal consistency Need to reconcile these conflicting requirements

6. Standard Names Management (4) Once discussion is concluded the new standard name is added to the table Currently this involves editing template files which are processed by perl scripts Only way to refer to previous discussion of standard names is via mailing list archive New CF website will make the process much easier!

7. The need for mapping controlled vocabularies Grid based infrastructures such as NERC DataGrid cannot function operationally without metadata and data semantic interoperability This will never be achieved without: –Readily accessible standard terms whose meaning is clearly understood –Readily accessible semantic maps both within and between lists of standard terms –Semantic maps between local terms and standard terms

8. The Solution? Implementation of a Vocabulary Server Building OWL ontologies mapping between domain-relevant de-facto standard vocabularies Deploying the ontologies through a Web Service thesaurus server Making tools available for users to build and deploy local ontologies

9. NDG Vocabulary Model Entry (timestamped) KeyTermDefinition Entry (timestamped) KeyTermDefinition Entry (timestamped) KeyTermDefinition List (versioned, timestamped and labelled with key, name and definition) List (versioned, timestamped and labelled with key, name and definition) Constraint (Aggregation of lists across which entry keys are unique)

10. Vocabulary Technical Governance Versioning should: –Provide a unique label for each instantiation of the list –Enable any previous instantiation of the list to be recreated –Provide timestamp information for creation and modification of every object in the vocabulary system Delivery should –Be from the master, not a copy –Be accessible to software agents to allow automated synchronisation of local copies

11. Mappings and Thesaurus Server There will never be a single list for a given topic Term mapping therefore an essential part of semantic interoperability Marine Metadata Interoperability (http://marinemetdata.org) have developed tooling and trialled mappings in the measurement phenomena arenahttp://marinemetdata.org

12. Mappings and Thesaurus Server NERC DataGrid Plans –Use MMI technology plus domain expertise available in BODC, BADC and their user communities to build a complete map between BODC Parameter Discovery Vocabulary (300 terms) CF Standard Names (5-600 terms) GCMD Parameter Valids (2-300 relevant terms) –Incorporate this map into the NDG Discovery Service to facilitate smart searching (e.g. ‘pigments’ finds dataset labelled ‘chlorophyll’) through MMI Web Service –Integrate ontology maintenance into source list maintenance