1 of 43

ga4gh.org

2 of 43

Data Model & Schema Consensus Study Group

Kathy Reinold et al.

ga4gh.org

3 of 43

Introduction

ga4gh.org

4 of 43

  • Treat everyone with respect, empathy, consideration, and professionalism
  • Consider other points of view, eliminate your own biases
  • Acknowledge others’ contributions
  • Respect GA4GH and venue policies and rules.

Code of Ethics and Community Conduct

Help us create an inclusive environment

  • Abuse or harassment in any form, or threats thereof
  • Violating boundaries when previously communicated
  • Photographing or recording others without their consent
  • Disrespectful communication and any other behaviours that lead to hostile environment

The following will NOT be tolerated:

Read the full CECC on our website

ga4gh.org/code-of-conduct

Read the Guidelines for Respectful Behaviour

bit.ly/ga4gh-respectful-

engagement

Have questions or want to report? Contact Safe GA4GH Officer Paula Brantner at

conduct@ga4gh.org

ga4gh.org

5 of 43

Intro to DaMaSC

  • Study Group launched in May 2022 – Discovery Workstream
    • Initial focus on schema registry
    • Didn’t address many of the challenges of interoperability
      • “A lack of coordination and alignment between standards has resulted in irreconcilable challenges. “ – Alex Wagner
    • GA4GH Connect in Nov 2022
      • “Still need a strategy for describing data” – Melissa Haendel
      • “There needs to be a pan-GA4GH set of requirements of how to produce information models and schemas” – Jeremy Adams
      • “We should make recommendations for this guidance our top priority.’” - Alex Wagner

Kathy Reinold

ga4gh.org

6 of 43

DaMaSC Charter

  • Situation
      • Workstreams develop standards, frameworks and tools
        • Domain experts – deep, focused efforts
        • Operate independently
        • Often define different vocabulary & data representation
        • Presents barriers when bringing standards together
  • Objectives
      • Brainstorm and develop ideas to facilitate interoperability across workstreams
        • Should GA4GH recommend guidelines?
          • For common information models, vocabularies, ontologies, schemas
      • Prepare and submit appropriate product proposals

ga4gh.org

7 of 43

Story Thus Far

  • Study Group launched prior to Product Process
      • Revisiting this now to relaunch
  • Recommendation for Schema Registry
      • But this is not enough
  • Interesting discussions
    • 30+ people from various perspectives
      • Different cross-sections in nearly every meeting
      • Looking for larger core and schedule meetings around availability

ga4gh.org

8 of 43

Agreed

  • Not one solution
  • Need a strategy to describe data
    • Prescriptive model for all GA4GH is not possible
    • Provide clear definitions of entities without specifying data representation
    • “Semantically if we all come back to the same model it will make it easier.” – Larry Babb
    • Proposal must include a reference schema
  • Need to provide a framework to guide data representation
  • Schema registry is useful
  • Focus on GA4GH standards/workstreams
  • Build on existing standards – GA4GH and industry
  • Follow product development process to propose solutions

ga4gh.org

9 of 43

Activities in 2024

  • Define use cases
      • Today and more …
  • Landscape survey
      • Schema registries and data standards/frameworks
  • Overlap analysis
      • Data representation across existing GA4GH standards
  • Prepare Product Proposals
      • Summarize product ideas to survey members on potential impact
      • Prepare product proposal for Schema Registry
  • Roadmap

ga4gh.org

10 of 43

Aim of Today’s Meeting

  • Explore interoperability challenges through use cases

  • Brainstorm ideas for easing interoperability challenges

  • Discuss the benefits of proposed ideas
      • Forum to discuss data representation across workstreams
      • Strategy for describing data
      • Standards or guidelines for defining vocabulary/data representation
        • Recommended vocabularies or ontologies
      • Schema registry

ga4gh.org

11 of 43

Interoperability Challenges

  • Welcome and thank you speakers!
    • Alex Wagner
      • VRS and Phenopackets
    • David Bujold
      • Launching Experimental Metadata Study Group
    • Jordi Rambla De Argila
      • Beacon data model
    • Miro Cupak
      • Data Connect
    • Michael Baudis
      • Challenges of this issue in Discovery Workstream

ga4gh.org

12 of 43

Interoperability Challenges

Use Cases

ga4gh.org

13 of 43

Technical Interoperability Challenges

  • Issue
    • Lack of common organizational framework for model definitions
  • Use Case
    • Development of the VRS standard in a JSON-Schema framework
      • Using Phenopackets under a protobuf framework
    • Encountered challenges in reconciling differences
      • Consider whether these could have been reduced through the use of a common framework
  • Talk to be scheduled soon! We’ll keep you posted!

Alex Wagner (Kathy Reinold)

ga4gh.org

14 of 43

Expediting Experimental Metadata Effort

David Bujold

  • Establish a minimal checklist to characterise -omics datasets
    • Enough information to understand what the experiment is about
    • Prioritize usage of relevant ontologies, over controlled vocabularies, to characterise common concepts
    • Build upon/improve existing checklists, such as the one at ENA
    • Checklist should be modular, as relevant properties are dependant on the type of experiment

ga4gh.org

15 of 43

Expediting Experimental Metadata Effort

David Bujold

What problems are we trying to solve?

  • Improve the understanding of available data
  • Improve the discovery of genomic experiments
  • Help new initiatives to better capture their experiments metadata, by providing guidelines on the right way to do so
  • Provide a dictionary of experiment properties to be supported by other GA4GH standards
  • Obtain details on potential experimental biases that may characterise a dataset

ga4gh.org

16 of 43

Expediting Experimental Metadata Effort

What we’d like from DaMaSC

  • To formalise our product, we’d like to stay close to what others in GA4GH are doing
  • Discussions on JSON Schemas vs Protobuff vs others is beyond our scope
    • Participants have shown strong interest in JSON Schemas so far
  • Will allow us to focus on the content (properties, values, ontologies)
  • Will help making what we do more reusable in other GA4GH products

David Bujold

ga4gh.org

17 of 43

Beacon perspective

Beacon v2 is a complex product:

Multiple components, with variations

Multiple types of requests and corresponding responses

A rich schema definition is required

Beacons being part of a network is a core asset of Beacon

We need to check (validate) the conformance of requests and responses to the schemas on the fly (at query time)

Jordi Rambla De Argila

ga4gh.org

18 of 43

Beacon perspective

We have links (dependencies?) to other GA4GH products

It leads into a composite response

Should be coherent at different levels to make it intuitive, easy, palatable to implementers

How to integrate them seamlessly if different schema solutions are being used?

How to integrate them elegantly if different style books are used?

Is a schema repository solving these issues?

Not actually ;-) it solves other issues

Jordi Rambla De Argila

ga4gh.org

19 of 43

Use Case: Data Connect

Miro Cupak (miro@dnastack.com)

ga4gh.org

20 of 43

Data Connect: Overview

  • Provides a mechanism for:
  • Describing data and its data model.
    • Table API organizes data into "Tables" and describes their data model.
    • Leverages the JSON Schema standard.
  • Searching the data with the given data model.
    • Search API queries "Tables" of data.
    • Leverages the SQL standard without requiring a particular data store.

  • Does not define said data models.
    • Bring your own, or use other GA4GH standards (e.g. Phenopackets).

ga4gh.org

21 of 43

Data Connect: What we have

  • Data Connect organizes data into Tables, which are represented as arrays of JSON objects.

subject_id

dob

bp

aa001

1990-04

130/84

aa002

1970-06

125/83

{

"data": [

{ "subject_id": "aa001", "dob": "1990-04", "bp": "130/84" },

{ "subject_id": "aa002", "dob": "1970-06", "bp": "125/83" }

]

}

ga4gh.org

22 of 43

Data Connect: What we have

  • The "rows" of the Table need not be flat. Any valid JSON is acceptable.

subject_id

dob

bp

aa001

1990-04

Systolic: 130

Diastolic: 84

aa002

1970-06

Systolic: 125

Diastolic: 83

{

"data": [

{ "subject_id": "aa001", "dob": "1990-04", "bp": { "sys": 130, "dia": 84 },

{ "subject_id": "aa002", "dob": "1970-06", "bp": { "sys": 125, "dia": 83 }

]

}

ga4gh.org

23 of 43

Data Connect: What we have

  • A Data Connect table also has a JSON Schema. Each JSON Object (row) in the table conforms to that schema.

subject_id

dob

bp

aa001

1990-04

130/84

aa002

1970-06

125/83

{

"data_model": {

"$id": "https://example.com/table/subjects/info",

"$schema": "http://json-schema.org/draft-07/schema#",

"description": "Information about subjects at study intake time",

"properties": {

"subject_id": {

"description": "Unique identifier for a subject in this study",

"type": "string"

},

"dob": {

"description": "Subject's year and month of birth",

"type": "string"

},

"bp": {

"description": "Subject's blood pressure (systolic/diastolic in mmHg)",

"type": "string"

},

}

"data": [

{ "subject_id": "aa001", "dob": "1990-04", "bp": "130/84" },

{ "subject_id": "aa002", "dob": "1970-06", "bp": "125/83" }

]

}

ga4gh.org

24 of 43

Data Connect: What we have

  • JSON Schema supports external references, so the reusable concepts can be factored out into reusable modules.

subject_id

dob

bp

aa001

1990-04

130/84

aa002

1970-06

125/83

{

"data_model": {

"$id": "https://example.com/table/subjects/info",

"$schema": "http://json-schema.org/draft-07/schema#",

"description": "Information about subjects at study intake time",

"properties": {

"subject_id": {

"$ref": "https://example.org/study_schema#subject_identifier"

},

"dob": {

"$ref": "https://example.org/study_schema#subject_dob_my"

},

"bp": {

"$ref": "https://example.org/study_schema#blood_pressure"

},

}

"data": [

{ "subject_id": "aa001", "dob": "1990-04", "bp": "130/84" },

{ "subject_id": "aa002", "dob": "1970-06", "bp": "125/83" }

]

}

ga4gh.org

25 of 43

Data Connect: What we have

https://example.org/study_schema

subject_identifier

$id: https://example.org/study_schema#subject_identifier

subject_dob_my

$id: https://example.org/study_schema#subject_dob_my

Dataset 1

Dataset 2

Subjects table

Symptoms table

Subjects table

Symptoms table

Data Connect adds semantic meaning to $ref elements, specifying that any two schema properties that refer to the same URI are referring to the same concept.

ga4gh.org

26 of 43

Data Connect: Multiple levels of sharing schemas

Harmonized data following a common model

Unharmonized data as is, with model/schema

Provide the schema

Harmonized data

Link to the model

Data available, queryable and mergeable via a common API.

Usable by data detectives. Data out in the open where the issues can be seen and the community can work on.

Tabular data with column names

Provide CSV, TSV,

JSON etc.

Data meaning described for use by a scientist.

Instant federation.

Benefit

Requirement

Entry point

ga4gh.org

27 of 43

Data Connect: What we’d want

  • As a data custodian of a new study:
    • Place to discover useful schemas to use
      • Standardized GA4GH schemas and useful community-curated schemas
  • As data custodians of studies sharing concepts:
    • Place to put our schemas
  • As a researcher who created mappings between concepts:
    • Way to share mappings with others
  • As a standards maintainer:
    • Canonical GA4GH schemas to point adopters to
      • Interoperable with Data Connect (based on JSON Schema)

ga4gh.org

28 of 43

Improve Interoperability w Data Representation Standards

  • Biomedical API and document standards differ in extent of parameters and specific data models but usually share common concepts
    • “organ a biopsy was derived from”, “observation time after diagnosis”, “genotypic sex of subject”...
  • Representation of individual parameters can differ in their local context (i.e. the schema component they’re embedded in) and in the values used
    • number & unit or terminology or ISO8601 expression for age
  • Interoperability among GA4GH products and with external standards can be promoted through documentation of
    • common schema components
    • recommended data standards
    • selected terminologies

Michael Baudis

ga4gh.org

29 of 43

Improve Interoperability w Data Representation Standards

  • Representation of individual schema components facilitates development of and mapping between standards
    • How to represent an ontology class in my schema?
    • How to represent a geographic location?
    • Options for expressing age of a subject at a given time point?
  • Common schema language and stable URIs facilitate re-use or referencing of such components

Michael Baudis

ga4gh.org

30 of 43

Improve Interoperability w Data Representation Standards

  • Documentation of common data types, standards and practices in GA4GH helps to curtail “re-inventions”
  • Knowledge transfer among community members with broad spectrum of scientific and technical backgrounds
  • “Soft alignment” w/o necessity to use a single solution

ga4gh.org

31 of 43

Improve Interoperability w Data Representation Standards

TASC-led community effort?!

  • + between-standards mappings?
  • + cataloguing preferential ontologies, classifications?

ga4gh.org

32 of 43

Brainstorming

ga4gh.org

33 of 43

Ideas?

  • What can we do to facilitate interoperability?

ga4gh.org

34 of 43

Discussion

ga4gh.org

35 of 43

Topics

  • Schema Registry
  • Data representation standards
  • Strategy for describing data
  • Driver project with Experimental Metadata Study Group
  • Other ideas/comments/contributions

ga4gh.org

36 of 43

Schema Registry

  • Schema Registry
    • Seems to be consensus that this is useful
    • Prepare product proposal
      • Landscape survey – consider BioSchemas.org and other existing repositories
      • Other activities

ga4gh.org

37 of 43

Data Representation Standards

  • Data representation standards
    • Should we consider recommending vocabularies/ontologies?
      • Note: need not be a single recommendation
      • Units of measure
      • Species – NCI Taxonomy?
      • Gene, protein
      • Cell type, Sample type
      • Data type

ga4gh.org

38 of 43

Strategy for describing data

  • Strategy for describing data
    • Must have clear definitions of key entities and attributes
    • Must be minimal
      • Only define entities required to integrate across workstreams/standards
    • Must not specify data representation
    • DaMaSC to decide (i.e. recommend)
      • Terminology - Information model, metamodel, conceptual model?
      • How to represent this (LinkML under consideration, simple table format, …)
  • Comments, suggestions ??

ga4gh.org

39 of 43

Driver Projects

  • Experimental Metadata Study Group
      • What can DaMaSC provide to simplify this work?
  • Useful exercises?
      • Review VRS challenges;
      • Variant representations (VCF, VRS, Beacon) – what is the common ground?
        • Maybe this has already been done?
  • Other ideas for driver projects?

ga4gh.org

40 of 43

Discussion

  • Other ideas?
  • General comments?
  • Discussion …

ga4gh.org

41 of 43

Wrap Up

ga4gh.org

42 of 43

Wrap up

  • Thank you to speakers
  • Join us!

Kathy Reinold

ga4gh.org

43 of 43

ga4gh.org