1. The RESEARCH DATA ALLIANCE WG: Brokering Governance Wim Hugo – ICSU-WDS/ SAEON

2.  GEO BON  Meta-data interoperability  Input: ISO 19115, EML, NetCDF, SOS  Output: Darwin Core, Darwin Core +  ICSU-WDS  Meta-data interoperability  Input: ISO 19115, FGDC, EML, NetCDF, SOS, Dublin Core – but needs to grow beyond  Output: Darwin Core, Darwin Core +  DIRISA/ SAEON  Meta-data interoperability  Input: ISO 19115, FGDC, DDI, EML, NetCDF, SOS, Dublin Core*, Darwin Core  Output: DataCite +, Dublin Core, ISO 19115, Darwin Core +  Data Service Interoperability  WMS, KML, SOS, GeoRSS, NetCDF, Darwin Core + Use Cases

3.  Multiple global initiatives and infrastructures of which GEO BON is in part an aggregator  Almost all government/ grant funded with an open source grounding  Governance style: community-adopted standards  TDWG, OGC  Business model  Free services  Membership Governance Use Cases: GEO BON

4.  Membership-based participation  Governance likely to be community-driven and not WDS-driven  Governance style: community-adopted standards  Across many domains and disciplines  Can provide guidance but not substance  Business model  Member contributions in kind – hosting brokering services Governance Use Cases: ICSU-WDS

5.  National participation  Governance likely to be funder-driven  Governance style: community-adopted standards  Across many domains and disciplines  Can provide guidance and recommend policies  Business model  Grant-funded and will involve a local brokering instance  Brokering services free to government-funded researchers Governance Use Cases: SAEON/ DIRISA

6.  Participation from government-funded research and initiatives  Governance envisaged as RDA-style community engagement  Community-adopted standards  Across many domains and disciplines  Can provide guidance but not substance  Business model  Membership on behalf of community  Free services Governance Use Cases: DIRISA/ SAEON

7.  Machine-readable, automated engagement with a brokering service (SLA, contracting, …)  Services to execute transactions (depends on business model)  Services to provide provenance information and annotated citations  PIDs for brokering actions What is required? Use Case Commonalities

8. Considerations: SLA/ Transaction End User Status Business Model Identifier Options Support Options Execution Options Input/ Source Options Output Licensing Options

9.  End User Status  Registered/ Not Registered  Funded/ Not Funded  Business Model  Free/ Premium/ Pay per Use/ Membership  Identifier Options  Combinatory/ New PID  Support Options  None/ Best Effort/ Response Time Commitment  Execution Options  Provider/ Broker/ Client  Input/ Source Options  Output License Options  Combination/ Computed Use Case Variations

10. The RESEARCH DATA ALLIANCE IG: Brokering Wim Hugo – ICSU-WDS/ SAEON Michael Diepenbroek - PANGAEA

11. “Brokering Framework” Or “Brokering and Mediation Registry” Proposed New Working Group

12.  Multiple service protocols  Multiple content standards for data and meta-data  Multiple vocabularies and ontologies  Multiple brokering approaches/technologies for mediation exist which are largely incompatible  Project-driven limitations leads to lack of sustainability, loss of expertise, code, and infrastructure Diversity – Familiar to All

13.  Vision  “ To describe, develop, test, and implement a Brokering Framework that allows publication, discovery, and invocation of brokering and mediation components in a standardised manner.”  Mission  Community consensus on the way in which brokering and mediation components are described, discovered, and invoked, based on real use cases – “Brokering Framework” – leading to a formal service and content standard. The formalisation of the standard is an external process and may involve participants in the working group, but is not a task for the working group;  Demonstrating the value of the framework by developing, testing, and commissioning a reference implementation of a brokering and mediation registry. Vision and Mission

14.  Define a description schema for services, vocabularies, ontologies, content standards, and mediation components that allow services and clients to be matched.  Establish a prototype registry based on the above.  Describe a collection of mediation components that can interoperate through well-defined existing interface specifications and applicable standards to support implementation of a universal mediation capability, and populate the registry with a base set of these.  Define a test bed environment for testing interoperability of mediation alternatives leading to recommendations for application areas.  The focus will be on meta-data and data brokering across data systems that address different disciplines and scopes. Address the Need

15. Supporting RDA Outcomes

16. Value Proposition: Common Implementation Architecture

17.  Discovery and access including harvesting and synchronous distribution  Content transformation for both meta-data and data  Content enhancement and Linked Open Data enablement through vocabularies and ontologies  Application to popular protocols and service definitions Mediation Functions to be Supported

18.  RDI Implementations  Portal Builders  Data Centres/ Repositories  Science Publishers  Service Providers  Ontology and Vocabulary Services Who are the End Users?

19.  Contributions from members in respect of current working components and use cases, through regular working group meetings.  Such meetings will be held every 2 months, and aligned with RDA Plenary Meetings.  In-kind development contributions.  Provisionally, this will include work to be done by DIRISA. Methods

20.  Confirmation of the elements of a brokering framework: component description standard, registry specifications  A community consensus, achieved via RDA working group efforts, to develop and publish a brokering and mediation component description standard that can be used as the basis of a registry of such components.  Community consensus on the capabilities (service methods) of a registry: allowing discovery and description of a brokering and mediation component.  A shortlist of important components that are currently operational will be obtained with community assistance, and populated in the registry.  Testing the registry in the context of real-life applications Practical Outcomes

21.  Confirm use cases and examples of brokering mediation, with a view to classifying them and developing a data model for description of components.  Develop content and service standards for a registry of brokering and mediation components.  Create and populate a registry of mediation options that allow components to be shared and improved.  Create a test environment to examine existing and future capabilities.  Test and evaluate.  Consider governance of the registry and the test environment in collaboration with the Brokering Governance Working Group. Work Plan: Main Tasks

22. Deliverables and Milestones

23.  ESSI Lab  EarthCube  OpenAire  panFMP  SAEON/ DIRISA Existing Work

24.  Open framework allows one or more implementations/ instances based on the framework.  How do we describe a broker or mediator?  Metadata  Capabilities  Software and Deployment Platform  …  Do we need formal registries based on the framework?  How do we match objects and brokers?  Crowdsourcing?  Do we need metrics/ qualification for brokers and mediators?  Does our registry support services?  Automated registration and editing  Discovery/ Capabilities Some Practical Questions

25.  Michael Diepenbroek (PANGAEA)  Wim Hugo (SAEON, WDS-SC)  Stefano Nativi (ESSI Lab)  Jay Pearlman (EarthCube)  Paolo Manghi (OpenAIRE)  Uwe Schindler (PANGAEA, Apache Software Foundation)  Health  Life Sciences  Humanities including social sciences Participants