SCAR Data and Information Strategy

1. SCAR Data and Information Strategy Kim Finney Rome, Italy, 2-7 Sept 2007

2. 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 • Strategies to meet needs • Annual workplans

3. 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

4. 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.

5. 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).

6. 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.

7. JCADM Role • 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.

8. 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

9. Analysed Data Metadata Published Data Source Metadata Typical Data LifecycleJCADM needs to address this process “systematically” for data reuse and interoperability purposes? classify apply algorithms mine map annotate store classify mark-up process publish store researchers general public domain communities government NGOs industry instruments collections observations artefacts samples Processed Data End Use analyse discover link verify classify verify filter store Metadata Archived Data Metadata Re-use within research

10. 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

11. 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.

12. 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.

13. 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 ?

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