GA4GH RNASeq

Minutes and Actions 2021

These are the minutes for the RNASeq meetings,  a subgroup of the GA4GH Large Scale Genomics Work Stream. For further information, please visit the GA4GH Work Stream page.

Meeting Protocols

Agendas, Minutes and Actions

2021-12-08

2021-11-10

2021-10-27

2021-09-15

2021-08-04

2021-07-07

2021-06-09

2021-05-26

2021-04-28

2021-02-17

2021-02-03

2021-01-20: First Meeting 2021

2021-MM-DD: Template

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct.
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.
• Dates should be specified in the international format yyyy-mm-dd

Agendas, Minutes and Actions

Previous minutes available: 2017-2018 minutes, 2019 minutes 2020 minutes

Also of relevance Sequence Annotation 2020

2021-12-08

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: Anup Mahurkar (CFDE/UMB), Yash Pulingundla, Miro Cupak, Jonathan Fuerth, Jared Nedzel

Meeting Recording

2021-11-10

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: David Bujold, Emilio Righi, Keenan Graham, Yash Puligundla, Anup Mahurkar

Meeting Recording

Minutes

SU: Today we’ll talk more about paginating a matrix, then we’ll spend some time talking about the API in general at a conceptual level. We’ll decide where the divide should be between the retrieval api and then other things like the wep application, discovery etc. How do we want to address the growing need for search in particular. Anup has sent a list of goal of the CFDE. We will look at how well RNAget meets those goals.

Paginating a Matrix

SU: Has been an issue from early on since matrices can become very large especially when dealing with single cell. We have a simple idea of one approach ot paginating a matrix → slice it on the rows. Each page would be a subset with all the samples on the rows. This is a more organic approach. There are many analysis applications that want to look at entire samples. Paginating on rows means you won't’ have all the data on a sample until you pull the entire matrix anyways. The question I have is, how prevalent is that? Is it more important to get every feature for a sample in a page, or is it more important to get all the samples and then page out through the features? Eventually we will take this and turn it into the pagination recommendation.

AM: May want both directions: by row and by column (parameter) to select.

SU: Seems reasonable, and won’t be too much of a burden on implementers. (DB +1)

SU: Then we can use this for the start for design

Web Application Support

SU: Where do we see adding some more fairly extensive features to the API (E.g. search). Do we want to build a library on top of RNAget to support a visualization application? Envision an application as the starting point of discovery. Nice thing about that is, the number of entries will probably be small. Won’t have a data flood problem. But to do that, the object properties probably need to be expanded to be useful. This could be an entry point into a discovery search type application. These are the ideas that came up in the last call. Looking at RNAget as a retrieval API, is this out of scope of the API? Want to make sure we build in the port for these types of applications early. What type of things do people want to be building? Do we have good use cases for that?

DB: The main way to return objects right now is *continuous or the expression end point. If you want to build visualization apps, there’s already libraries to deal with the objects. Is that really the purpose of this working group? If you start thinking about returning objects as JSON objects... not sure how useable…

AM: I can see a use case for it, we are using it right now. GTEX has an API that allows you to query...CIB is trying to build a visualization tool where you could have a distributed federated system and you could see everything side by side. Can show you a demo of this next time. Having already implemented something similar, I can see a use case for it.

SU: Sounds like the idea fo tackling the web application is outside the group. As long as you can query the quantificatoins, then you can do the visualizatoin.

MA: No, JSON structure more useful to web app than loom/tsv or other file

SU: We don’t have requirements on the output formats. Right now we recommend a list of common formats. We have some definitions on how to structure tsv for instance. Maybe we need to define a json structure for returning quantification data. (AM +1) If we do that, we don’t need ot worry so much about creating big libraries for doing web applications.

AM: Yeah, and what you get back is pretty lightweight.

SU: I have an exert of the structure that GTEx is using for their visualization. It’s a vector for each gene, for each tissue.

CFDE Goals

SU:

• Retrieving a list of filter terms are in the API already
• Types of file formats supported is in the API
• Retrieving database on unique identifiers → You can get an expression ID and the ID defines a specific matrix, and that can be defined as a file
• Expression data retrieval API (that’s the json AM was talking about)
• Retrieve expression data through an API that matches search criteria → Could be solved with a json structure

Discovery is another GA4HG work stream, really focused on Search. We removed all of the search from the RNAget API when first released. We would either put it back, or the Discovery WS would figure out a way to incorporate search. Latter has not happened, so is this the right time to think about putting search into RNAget. Might have to remove later if Discovery comes up with overall search, or maybe they can use what we put together. Do we want to tackle putting search back in as a module? Or do we want to leave it? Leaving it out means that implementation is a bit more difficult for implementers.

DB: I still feel this is out of scope for RNAget. Asking about things like anatomy, gender etc. doesn’t belong here.

AM: What is the timeline for discovery coming up with the search process? Months or years?

SU: Not sure.

MA: Assuming that discovery takes into account aportal as wella s an API/computer way of specifying ID….

Organizing Metadata

2021-10-27

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: Jared Nedzel, Joseph Okonda, Anup Mahurkar, Emilio Righi, Qiuyue Liu

Meeting Recording

2021-09-15

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: Jared Nedzel, Ben Hitz, Joseph Okonda, Emilio Righi

Meeting Recording

2021-08-04

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”:

2021-07-07

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: Ben Hitz, Roderic Guigo, Neerjah Skantharajah (GA4GH)

SU: Threshold is a done thing that just needs to be merged. Units endpoint pretty much the same status. Agreed that there’s value there. Third PR is change in documentation advising providers to limit return size. Will change the term to DDOS and flag reviewers. Github requires reviewers to have write access to merge.

SU: When we add the threshold and units endpoints is this what we want in a 1.2 release or do we want to hold off on anything else. Have discussed things in the past like returning statistics on the side of the matrix, but still don’t have strong use cases so hadn’t moved forward. Does anyone see a need to put this in or are we all ok waiting for more concrete use cases to arrive?

BH: Leave it out.

SU: Sounds like we have the 1.2 feature set here. Looking past 1.2, how is single cells ataa handled in the API. Right now it’s handled as individual datasets. Recognize that this will generate large data matrices. Came up with this when HCA was involved. Had thought about taking another look into how single cell data is being used. Had looked into spatial datasets. Personally, don’t know if they’re being used or if there are work flows etc.

BH: Hubmat is using spatial data. But I don't know of any standards.

SU: Could I ask you to see what they’re doing with spatial data. If they see use or a future for it?

BH: May be premature. Doesn’t lend itself to splicing of API. In the next month will try to hunt someone down from hubmat who may be interested.

BH: We just remodeled everything because we had to come up with a way to deal with original data from Barabara’s lab. No one does single cell experiments like that anymore. Found a way to rewrite tha tinto a series. There’s a meeting on the 12th to discuss what file formats people want to consume. In general, my understanding is that you have barcodes, genes and transcription value and then samples.

SU: Attribute identifying sample as single cell sample. Would be interested to know about the outcomes of the meeting on the 12th.

BH: Problem is that there’s 9 different matrix formats. Willing to have some number of redundancy but not an infinite number. Because there’s no uniform pipeline there’s not set of**

It’s at 10:00am PT.

SU: Will mull on the idea of identifying sample columns as single cells vs bulk. Defining an attribute on the column and saying these are the terms to use and the values to select from.

2021-06-09

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: Emilio Righi, Ben Hitz, Jared Nedzel, Joseph Okonda Roderic Guigo

Minutes

SU: Plenary meeting upcoming in September and GTEx is planning to do their implementation of the API. Is there anything we need to do on our end to support this

JN: We are going to implement the RNAget API and part of our goal is the ENCODE folks have already done so and we want to be consistent with them and bring two large RNASeq repositories into using the same API

NH: We are stuck in beta for a few, but as Emilio pointed out if you got to our RNAget page there’s actually no way to get to the API. It’s there but we have to switch things around. Probably won’t happen for another month or two. Happy to help. Feel free to follow up on slack channel

SU: Key to get these two repositories online and consistent

SU: Would like to quickly go through open issues. Some of the ones discussed in last high level call that were tabled for use case may be something that GTEX is interested in. Had an idea where we would add directions into the API for including summary statistics as properties on the feature axis. Things like SD, mean, min, max. I Know that on our call it was said that GTEX calculates and provides these stats, do we want to put that into the API so that if anyone like GTEX or others want to provide it we have a languages they can use. Nad a post where they can put it into the matric. How do we want to proceed.

JN: Description of use case and how GTEX uses this: our standard use case is when a user is retrieving gene expression for a particular gene, we retrieve all the values for all the tissues. Max 1000 fo all the values. Where it becomes an issue is where we want to compare expression of multiple genes amongst multiple tissues. At that point (e.g. 50 egnes across 50 tissue) it would be too expensive. At that point we want to do some sort of dimension reduction retrieve medians. We store the medians so we don’t perform the computation on the fly

EP: median across individuals?

JN: yes, medina for all of the individuals across tha tissue.

NH: when we discussed hits in the last call, when we wandered down the path of subsetting the matrices, at that point you are returning a subset of…

JN: We don’t support subsetting for the medians.

BH: So it’s a separate endpoint but not a separate API. At the project level, give me the mean or stats value per gene, for a project you can return a value. That is actually useful and doesn’t run into the problem of recalculating every time.

SU: See that there is some interest in spending a bit of time looking into this. Perhaps restricting it to the project level. Is there interest to spec something out quickly? (RG, BH +1) Will capture this in a github issue.

SU: something that’s related to ticket return field. Have a ticket object that returns some descriptive info on matric (e.g. unites that it’s in, url) this could be a place to report this type of data but that issue was written at a time when it was thought that this would be calculated on the fly. But it looks like this might be something we put in at the project level. Do we want to present this? Where is the right place for it?

BH: Think it’s straightforward.

SU: EP has opened up a new issue that talks about accessing project by ...ID. Right now we have this kind of data set management lightweight layer where we have aproject then a study and all the samples sit beneath the study. The crux of this is that the structure is very lightweight Is that something we feel we need to flesh out more at this point? Structure was in there because we saw this structure when looking at the API entities, like ENCODE, GTEX, looks liek there’s this type of large grouping, small grouping in those databases. So we put that in as a means of doing a search API for RNA which would use the project study to restrict the scope of searches and data returned. Didn’t flesh it out too much because wanted to focus on RNA retrieval portion of API. Maybe management layer doesn’t really belong in retrieval APi but it’s it’s own type of limbs? System Is this API reasonable enough to move our efforts into fleshing it out? Breaking it out as a separate APi or making an end ot end RNA information management search system.

BH: Against it. Just going to make it harder for people to implement stuff. Everyone has their own way of organizing information sets.

SU: CANDig when they did their implementation, they also discarded the structure. They made everything one project and just used one of the layers. Jared, do you have a similar opinion?

JN: Not sure that it’s something that we would use. Haven’ looked at the API in a long time. For us, we would likely have a single project with multiple studies. And so, for GTEX, we do periodic releases, roughly once a year. Each release is a consistent data set that has all gone through the same pipeline and reference genome etc. We would not have multiple projects. Probably a single project with multiple data sets. Makes sense to me if it was just at the study level, then you wouldn’t necessarily have the hierarchical representation that GTEX v8 and v10 are part of this larger thing called GTEX.

SU: Sounds like study concept is more important than project concept

JN: If you think about it from the perspective of someone retrieving data and they want to know what GTEX projects are available, they don’t have that context...If there was sa portal or repository that contained both GTEX and ENCODE data then you would need to have that project level organization to group the studies hierarchically.

BH: think removing the projects layer doesn’t make sense because certain entities have multiple projects. Don’t think we should add anymore substructure.

SU: Reason for asking question is to get a feel for the difference in the landscape between GTEX and ENCODE. GTEX is really a single project with lots of studies and ENCODE is a lot of projects with a small number of studies in each one. Both use different structures. Not seeing a lot of excitement for developing project and study beyond the idea of them just being simple containers.

SU: Sounds like we will hold off on expanding anything re: project and study at least for now. As GTEX moves into doing implementation, potentially there will be things that come up. Just keep us apprised of anything we can do on our end to help out.

SU: That summarizes what is currently out there. Is there anything that people feel the API is missing? Have there been any other use cases that have come up? If API is okay for now, then that’s good.

Even thought we call it RNASeq API, we want it to relate to all omics data.

SU: actually it’s the RNAget API. RNASeq is how we refer to ourselves as a group

BH: Comes down to the fact tha because RNASeq data is the only type that maps to a gene, every other methods has infinite column...

2021-05-26

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: Sean Upchurch, Emilio Palumbo, Ben Hitz, Neerjah Skantharajah (GA4GH)

SU: Is it reasonable for the min max to be a half open interval from min, which has a min of zero to whatever that the max value is? Or is that odd?

EP: Agrees that it looks weird to have half an interval and may be confusing for people.

BH: Don’t gain anything from making it half open from an engineering standpoint. Suggest to leave it open.

SU: I think the use is driven by the removal of zeros. And so we have a half open on zero rather than have a negative number in there, which is just going to be a headache to deal with. If we have a min value of three, do we want three in the matrix?

BH: I think you’re right, half open is correct and the best compromise. May just need some documentation but not much. Excluding zero will be weird without a special case

SU: We definitely don’t want a special case.

EP: For most of the use cases, half open is good. Although some people may not expect it to work this way.And then they will be puzzled because it doesn't. If you read the documentation, it's fine. I mean, because for the use case, for the most part, I mean, for most of the use cases have opened this is good. I mean, it's, it's the way that you would think, to make a query. The problem is that some people would not read and would not expect this to work this way. And also, in my in my opinion, I mean, I mean, speaking about names, if you say I want mean to be zero, you think I mean, to me would mean, okay, zero would be included, because it would be the minimum value that they want to be in the matrix.

SU:  Why don't we just, let's go with closed on both ends and see if anyone else has any comments on that? Because I think that just makes more, you know, it's logically clearer. And, and that's also why, aside from handling the Remove zero cases, that's also why I selected closed on the max.

BH: I don't know why the API of our beta release is not exposed properly. Probably what happened was is that we, we just QAed the UI of it, because that's what how we think are thinking about it. But it's probably a minor fix. It looks like that this RNA get endpoint did not implement the override properly. Okay. So it might work, for example, if you curl it. But if not, we'll just fix it.

2021-04-28

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: Sean Upchurch, Emilio Palumbo, Ben Hitz, Roderic Guigo, Neerjah Skantharajah (GA4GH)

2021-02-17

Chair: Sean Upchurch

Attendees “Name (Affiliation)”: ,,,,, Jeremy Adams (GA4GH), David Bujold (McGill)

2021-02-03

Chair: Sean Upchurch

Attendees “Name (Affiliation)”: , , Benjamin Hitz (Encode) , Pedro Assis (Encode) , Emilio Palumbo (CRG),  Jeremy Adams (GA4GH)

2021-01-20: First Meeting 2021

Chair: Sean Upchurch

Attendees “Name (Affiliation)”: Emilio Palumbo (CRG), Roderic Guigo, Benjamin Hitz, Jeremy Adams

SU: Beacon and RNAseq use case

EP: they need functionality from RNAget and want to extend its use case rather than develop their own spec. Haven’t gotten feedback in a while

RG: contact Jordi and Salva

SU: would be great to do a kickoff at Connect 2021

SU: ENCODE has finished their annual meeting, they want to work on implementation

BH: toying with RNAget implementation for ~2yrs, attempted to extend the CanDIG RNAget. New engineer will be starting on implementing RNAget on ENCODE portal. Prototyping it now. How to handle projects vs studies

SU: related data submitted together is a study

BH: GGR as a separate project

SU: project, study structure mirrors ENCODE and GDC concepts. May be replaced by another GA4GH schema

BH: ENCODE talking about delivery of other matrix formats. May draft something that could be affixed to this API

SU: we have demo and PoC implementations, ENCODE will be first large scale production implementation effort

BH: IHEC - internal implementation, CanDIG - PoC implementation

SU: any more features, use cases to add? (Beacon, threshold filtering)

RG: signal continuous endpoint is implemented, we will be working with annotation API, put effort into the usage of the API, great to put API into a production. ENCODE is a good start. Promote the usage of the API in production mode

SU: we have single cell data, but not at the production scale

BH: a dimension to request cells? Or barcodes?

SU: currently, you would just get all the cells. Its a data transfer API, not discovery

RG: we don’t need to do anything for special transcriptomics data

SU: it’s general enough, a sample could be a bulk sample or a single cell

EP: more flexibility on filtering, e.g. filtering by metadata field. Need better definition of use cases

BH: to make it more powerful for single cell, you would need to make sure your data was mapped to a common annotation framework, data must be processed the same. Matching bulk samples to single cell samples

BH: ASTC - a big hubmap - assigns definitive genes into definitive cell locations. Phenopackets and UBERON are the same people

https://docs.google.com/spreadsheets/d/19m_xjwM5le7UKvt8966aEPA_a7HSCJBQY9Mq4qDe0ZQ/edit#gid=232587238

SU: consistent annotation of how samples are processed - we have a hook stating that all items in a study have the same processing pipeline. E.g. describe experiment pipeline at the study level

SU: FASP

SU: integrated demo of multiple APIs. does ENCODE have an implementation of htsget?

BH: No

BH: it wouldn’t be hard to implement, but we haven’t encountered a use case where someone would want to pull BAM data associated with RNAseq experiment. Maybe an API where you pull reads from a region from the same donor.

RG: Most ENCODE users are not interested in reads, mostly interested on purely signal data

BH: only useful for repeat calling

SU: not for a region, but for entire BAM

JA: for variants?

BH: ENCODE has almost no VCF files, not the focus.

SU: apps, libraries, clients that make use of it - parsing and retrieval - maybe Galaxy

EP: a python API, or R library - we expect them to do their experiments, more useful than a tool or application

SU: put together a demo notebook, maybe using this as a starting point

SU: CanDIG has plans to do some scaling up, I’ll contact David

EP: go in parallel development of R/Python library and development of CanDIG server

2021-MM-DD: Template

Chair: Sean Upchurch

Attendees “Name (Affiliation)”: