Scar data and information strategy
1 / 14

SCAR Data and Information Strategy - PowerPoint PPT Presentation

  • Uploaded on

SCAR Data and Information Strategy. Kim Finney Rome, Italy, 2-7 Sept 2007. Overview. Strategy development to date Suggested method to complete Strategy Strategy Overview Rationale for current document structure JCADM’s role Data management and SCAR science groups Our current system

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'SCAR Data and Information Strategy' - toril

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Scar data and information strategy

SCAR Data and Information Strategy

Kim Finney

Rome, Italy,

2-7 Sept 2007


  • Strategy development to date

  • Suggested method to complete Strategy

  • Strategy Overview

    • Rationale for current document structure

    • JCADM’s role

    • Data management and SCAR science groups

    • Our current system

    • Strategies to meet needs

    • Annual workplans

Strategy development
Strategy Development

  • Task arising from last SCAR (Hobart, 2006) meeting.

  • Draft ToC developed in 2006 (Bruin & Finney) – circulated to group via list server for feedback.

  • Two email surveys sent out June 2007 – (a) JCADM community (b) SCAR Science groups.

  • Draft Strategy prepared – using:

    • Survey responses,

    • Reference to JCOMM, IODE, ICSU CODATA Strategies, JCADM Review.

    • Knowledge and familiarity with “some” SCAR programs and scientific needs.

    • Background information via participation in existing national and global data management forums (ICSU WDC SCID, AODC JF Virtual Data Centre, IODE, GBIF, SCAR-MarBIN, OBIS etc).

  • Circulation of draft Strategy on JCADM listserver

What now
What Now ?

  • Quick re-cap of the Strategy as its stands.

  • This forum to provide opportunity for input, views – to shape the document and directions that we “all” wish to take.

  • Propose to give everyone chance to provide feedback separately on any aspect of the draft document.

  • Followed by more structured discussion on key issues (also informed by session above).

  • Formation of a small drafting team to edit Strategy in light of feedback and discussions.

Draft strategy document
Draft Strategy Document

  • Rationale for how Draft is currently structured.

    • Executive summary – for those who won’t read any further.

    • Summary of recommendations (without any context) – for those who just want to see what the key actions are.

    • Body of document

      • Says what is in scope and why we are even writing a strategy (section 1).

      • Then explains what SCAR is, how it is organised, where JCADM and SC-AGI fit in (section 2).

      • Followed by an explanation of the “science” data management needs (section 3).

      • Then explains how we are (or are not) currently meeting these needs and why not (if we aren’t) [section 4].

      • Main “strategic” directions suggested are then explained – which should make sense – given the context that has already been provided in previous sections (section 5).

Jcadm role

  • Regardless of the structure of the “document” our responsibility is to provide:

    • A single portal for recording information about data holdings – the AMD,

    • A distributed system for storing and providing access to that data – the Antarctic Data Centres (NADCs and ADMS).

  • Our Strategy must “as a minimum” aim to meet these responsibilities. The ToRs provide further guidance – “sustainable repositories”; “best practice; “linkages to other data management systems”; “fundamental datasets”.

  • Many of these roles are “services” – which implies taking into account the needs of those that you are providing “services” to.

Jcadm role1

  • Is JCADM more than the sum of its parts ?

    • Current strategy takes the view that it is.

    • Strategy implies role for JCADM as a

      • Point of advice on data management policy and best practice,

      • Coordinator of a “system” – with implication of organisation, procedures, codes of practice, standards, collaboration.

      • Through its membership, a provider of services.

  • Alternative – JCADM is an umbrella “name” for a loose collection of a few independently functioning Data Centres and national Antarctic data contacts who share a metadata system.

Strategy section 3
Strategy - Section 3

  • Needs outlined in Section 3 – are context for any recommendations that we make

    • Data Discovery

      • AMD related issues

      • Motivational aspects of providing metadata (and data)

    • Data Access

      • Real-time vs delayed mode data streams - issues they raise:

        • Duplicate handling, versioning, language, gated vs public access

    • Data Exchange

      • Data encodings & formats (e.g. xml, netCDF, KML, RDF, GML)

      • Data exchange protocols (web services, TAPIR, DiGIR, OpenDAP)

    • Data Quality

    • Data Integration

      • Species registers, standard terminologies, ontologies, feature and symbology catalogues

    • Data Archiving








Typical Data LifecycleJCADM needs to address this process “systematically” for data reuse and interoperability purposes?


apply algorithms











general public

domain communities











End Use










Archived Data


Re-use within research

Strategy section 4
Strategy - Section 4

  • Brief Situation Analysis -

    • Brings in our role and ToRs

    • Mentions key findings from JCADM member survey.

      • Few fully operational NADCs

      • Most JCADM members – data contacts (often with dual roles).

      • Highly variable level of data management proficiency.

      • Not much “data” handling going on.

      • Limited resources.

    • Re-states important conclusions from JCADM review.

      • Mentions lack of strategy

      • Need to forge links with other systems/networks

      • Poor compliance with Treaty obligations re data access

      • Importance of adequate funding of data management in science projects

      • etc

Strategy section 5
Strategy – Section 5

  • Starts by painting a picture for JCADM and science groups about what a well-functioning – co-ordinated system would look like – via 2 hypothetical testimonials from a young and older scientist.

  • Then summarises what components are required to achieve such a goal.

  • Each component is then examined in detail – given our current context and recommendations are made as to how we might put in place each of these components.

Questions ?

  • Any questions before we give you an opportunity to comment generally on the Strategy ?

  • Don’t feel you have to repeat someone else’s comments. If points you agree with have already been made just state this.

  • Max 10 mins per person.

  • Opportunity in later sessions to discuss key issues/points.

Discussion topics
Discussion Topics

  • Do people agree with concept that JCADM is more than just the sum of its parts ?

  • Do we have enough core resources (particularly through existing NADC’s) to work towards goals in Strategy - or is this fantasy ?

  • Is it realistic for us to be able to jointly apply for, and obtain US or European funding ?

  • What do people think of regional hosting services ?

  • Could we make better use of collaborations with larger systems like the WDC or IODE systems ?

  • What do people think of the changes suggested to our governance/establishment of a Tech Committee ?

  • How can we improve our communications and collaborations ?

  • What changes would people like to see in the document – content and/or structure ?

Interoperability linkages requires use of standards agreed protocols
Interoperability (linkages) – requires use of “standards” & “agreed protocols”