GA4GH RNASeq

Minutes and Actions 2022

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

2022-11-09:

2022-10-26:  CANCELLED (Due to unavailability of the leads)

2022-10-12:  CANCELLED (Due to unavailability of the leads)

2022-09-28:  CANCELED

2022-09-14: Canceled (Due to Plenary meeting)

2022-08-31: CANCELLLED (due to lead’s unavailability)

2022-08-03: CANCELLED

2022-06-22: CANCELED

2022-05-25: CANCELED

2022-05-11: CANCELED

2022-04-27: Testing & Compliance Suite

2022-04-13: RNA Search & Discovery

2022-03-30: Canceled

2022-03-16: Data Connect

2022-02-16: Search Schema

2022-02-02 : Common Search terms

2022-01-19: Data Connect & Json Schema

2022-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

2021 minutes

Also of relevance Sequence Annotation 2020

2022-11-09:  

Chair: Sean Upchurch.Emilio Palumbo

Attendees “Name (Affiliation)”:

Meeting recording:

Meeting minutes:

2022-10-26:  CANCELLED (Due to unavailability of the leads)

Chair: Sean Upchurch

Attendees “Name (Affiliation)”:

Meeting recording:

Meeting minutes:

2022-10-12:  CANCELLED (Due to unavailability of the leads)

Chair: Sean Upchurch

Attendees “Name (Affiliation)”:

Meeting recording:

Meeting minutes:

2022-09-28:  CANCELED

Chair: Sean Upchurch

Attendees “Name (Affiliation)”:

Meeting recording:

Meeting minutes:

2022-09-14: Canceled (Due to Plenary meeting)

Chair: Sean Upchurch

Attendees “Name (Affiliation)”:

Meeting recording:

Meeting minutes :

Discussed about Github96 issues

2022-08-31: CANCELLLED (due to lead’s unavailability)

Chair: Sean Upchurch

Attendees “Name (Affiliation)”:

Meeting recording:

Meeting minutes :

2022-08-03: CANCELLED

Chair: Sean Upchurch,Emilio Palumbo

Attendees “Name (Affiliation)”:

Meeting recordings:

Meeting minutes:

2022-06-22: CANCELED

Chair: Sean Upchurch,Emilio Palumbo

Attendees “Name (Affiliation)”:

Meeting recordings:

Meeting minutes:

2022-05-25: CANCELED

Chair: Sean Upchurch,Emilio Palumbo

Attendees “Name (Affiliation)”:

Meeting recordings:

Meeting minutes:

2022-05-11: CANCELED

Chair: Sean Upchurch,Emilio Palumbo

Attendees “Name (Affiliation)”:

2022-04-27: Testing & Compliance Suite

Chair: Sean Upchurch,Emilio Palumbo

Attendees “Name (Affiliation)”: Jeremy Adams,Emilio Palumbo,Emilior,Emilior,Alex Tsai,Reggan Thomas

Meeting Link:https://us02web.zoom.us/rec/share/Jm9zjGPiaX9eC-35dpVqkkBkOgGnmLtX13CrxSu-0tlg9sP4Al-KpD9W3OFxVwag.SdKAaIsU2UOu0yhn?startTime=1651067749000

Meeting minutes:

Harmonized  testbed infra Poc -

Motivation - Multiple testing initiatives

Walkthrough of existing API testing initiatives

TES compliance test bed and DRS+Passport - high level discussion happened.

Test bed Infra         - Library and Service

Walkthrough of Testbed API entity-relationship diagram

Next steps - develop new testbed to test more standards

Technical issue - Hardware problem. Can run it locally rather than on a server?

Registered platform could be the internal testing platform.

How to proceed testing the branch? - Manual testing perspective - setup instance in local machine.

Automated  - Into github actions, reports not needed to be shared but used for internal validation.

Gtex - Anyway to use the dataset centrally ?

Override the test with its own test dataset , still able to use GA4GH harmonized framework. Custom dataset to the desired out.

Implementation is compliant with schema?Based on the dataset.

Planned to merge the current branch.

What needs to be done before merging - Create a new VM and evaluate the output.

Or pass the command to Alex and he can spin up the server and test.

Next steps - automate the test steps.

Before the next meeting - Run all the tests and give the results back to Alex.

2022-04-13: RNA Search & Discovery

Chair: Sean Upchurch,Emilio Palumbo

Attendees “Name (Affiliation)”:

Meeting recording:

Meeting notes:

2022-03-30: Canceled

Chair: Sean Upchurch

Attendees “Name (Affiliation)”:

Meeting recording:

Minutes:

2022-03-16: Data Connect

Chair: Sean Upchurch,Emilio Palumbo

Attendees “Name (Affiliation)”: David Bujold, Anup Mahurkar, Emilio,Emilior, Jared Nedzel,Reggan Thomas

Meeting recording:https://us02web.zoom.us/rec/share/v-Opc3_XvDYlmUa5-qsog150IRIJB43UXfPM-43ADc6VCTG4wSJD6DSvygxagadB.0dFluRIK7Yfln0dE?startTime=1647439203000

Meeting notes :

SU - We have a draft document for the the data model for search

we can kind of knock it out. But there is a session proposal for the upcoming Connect meeting in April, to look at developing a set of GA four GH data models for various entities. This was started by the discovery team. Presumably, you know, moving on from from data connect and realizing that they do need these models, like the one that we're in the process of building right now

2022-02-16: Search Schema

Chair: Sean Upchurch,Emilio Palumbo

Attendees “Name (Affiliation)”: Anup Mahurkar, Emilior , Reagan Thomas

Link to the presentation - https://docs.google.com/presentation/d/1fFubITJnJsv-Cexe7AFS9QGjHfxI97T3/edit?usp=sharing&ouid=100161098099316587246&rtpof=true&sd=true

Link to meeting recording - https://us02web.zoom.us/rec/share/Sb4rjrjhigp8a4FSp6wl6x_njnaDjlev6rcL6fXI1L8vqONJ5_nKceaY0Jp5Wt3d.p6OWPRmhegJHh8mk?startTime=1645023484000

Minutes:

SU

RNA Search Advice - Targeted audience- Data providers

Purpose - To define a set of common RNA search terms that can be used by data providers

Provide guidance for implementing search based on GA4GH Data connect standards.

In scope - List of recommended search terms, designed to promote interoperability, designed to easy to implement

Out of Scope - Not an API, Exhaustive list of search terms

Search term descriptive

     Project name - Human readable name for project data

     Output format - Desired output format for matrix - Loom, Anndata, hdf5,tsv/csv, Matrix market

     Units -         Desired output units - TPM, count , FPKM

Type - String (use controlled language for these terms)

Search term experimental

Term -

Experimental type - scale term for overall type of experiment

Assay type - Experimental assay

Technique - Sequencing technique used

AM - Ontology based reference - obi-ontology.org

SU

Search term - Demographic

Term -

Gender - PATO 47 term

Race - racial descriptor

Age - Age of organism

Age Unit - Units on age - month, day, year

Search Term - Sample

Term

Tissue - Tissue type defined by Uberon ontology

Organism - defined by NCBI Taxon Ontology

Cell_line- defined by CLO ontology

Clinical_Phenotype - Phenotype as defined by Human phenotype ontology, NCIT or ICD

Clinical condition - DO , Mondo

Search Term - Genomic feature type

Transcript - ID from annotation

Gene - Name from annotation

Exon - ID from annotation

Exon - exon junction - ID from annotation , identity source needed

Variant - indel, SNP , mutation , deletion described by Variant ID

2022-02-02 : Common Search terms

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”:Jared Nedzel, Anup Mahurkar , Roderic Guigo , Reagan Thomas,Emilio Righi

Meeting recordings: https://us02web.zoom.us/rec/share/UhHg4feFsiAOca-HtMgbFocy0ozQGn3dcHVnmBwCCeQo2tX93svLmTAD52UQd02_.608VM5kTB7PCamKI?startTime=1643813764000

Link to the presentation - https://drive.google.com/file/d/1DSejVAPnu6MD490vTgC78siWPslgbFAn/view?usp=sharing

Notes:

SU: if we proceed with the plan of removing, project and study I don't think any of our implementers are really using it. And when we had our original approval, there was a discussion over, should we remove it or just realize it's going to be removed later.

I had an email response with some additional proposed search terms

JN

one thing that jumps out to me immediately is I would replace gender with sex. Gender is what people believe they are

SU

probably I got gender off with an older list.

JN

We had to make that change on GTEx portal.

SU

We have two items on the agenda today. The first is so that we can write the implementation advice and directions we wanted to come up with. We discussed this on the last call, a list of common, you know, RNA related search terms. So that way we can recommend the use of these terms and improve interoperability should you know everyone you know, adopts the same search fields in their data connect implementations.

The second item on the agenda is that the the Emilio's have a have a potential use for the bare expression ID and expression endpoints, to host

so diving right in. This is the list right now is this is essentially a list of all of the terms that, that I kind of dug out from looking at the the use case documents that we have collected over time, and looking at our, our metadata advice that's in the the RNA get standard, as well as some terms that were sent by by a member of the group. And so I think maybe we just take a look and see which terms we think we should be using. And I think the litmus for this should be that we want to pick terms that are, we think are common to, to most RNA directed search.

JD

I guess the one thing the you have sort of output format slash units, and those are orthogonal.

 I would change that into two separate ones: one would be format, one would be units.

looking at your, the right side, where you have, like, Gene and transcript.

Those to me are sort of an enumeration of a single thing.

AM

on the left hand side, so the third thing I was thinking about was only the scale that is asset type. And the third one is techniques, if you will, so for instance, a single cell coming from 10x is different from so coming from some of the other approaches. Were you doing one thing one cell at a time?

JD

here are two things. clinical conditions. I mean, that's a huge, difficult thing that would be a huge difficult thing. And that I think would really, I mean, on the GTEx side, both, you know, phenotypes and genotypes are, are protected. So that's not something that we could include

JD

We have a little, a little bit of a hierarchy, which is very minimal and somewhat immature of two levels, we have something called a tissue site, and a tissue site detail. So a tissue site might be heart and tissue site detail might be hard left ventricle. But both of those have an Uber on ID. And, and our, our distinction there is certainly not industry standard. So over on ID it is more I think standard and, and we really don't take much advantage of that minimal hierarchy that we've defined. And even then we don't make a distinction between Oregon versus say, skin or skeletal muscle or anything like that.

SU

snip mutation variant deletion. The question I have for that is does that fall into our assembler category? Is the coding the uncoding level of detail? Or are those useful kind of high level search terms?

JD

Whatever variant ID you recommend, there has to be some way of dealing with a variant, which is not yet in the database, because any project will have those?

EM

the idea is to to slightly change the API to make it more we can say browser friendly, and try to in this way, implement a feature to slice the metrics We will return from the API

Emilior

The idea is to finally start using the bare endpoint. So we will start from here, which is the the most important endpoint, I would say that we can use the expression at the bare endpoint to return the structure of the matrix, for instance, something like that the idea of the matrix and then the, the columns and the rows of the matrix in this way, then we can explore it another employee into that maybe I think we will, we should change the word because bytes is not the, the descriptive of this endpoint to return this Lysaght metric matrix. And that's almost settled say, same thing for what concerned the deployer endpoint. So we got the expressions and points which will return the list of expression matrix, but just this deplane structure. And this way we can, we are able to navigate through the various expressions. Because in from one side, you can take the structure of the matrix from the other side, you can slice it in this way the browser, the client can explore in a certain sense, the the API

EP

The bytes endpoint historically has been called bytes because it returns the data itself. And we were just returning looms or CSV. But since the idea is that we might return the JSON format of the matrix to this endpoint, probably, we should change it to something different.

SU

 I think speaking from history there, there are two things that we're looking at. The first is, again, to be more descriptive on this endpoint, returns the actual matrix data itself in line into the request response. And we call that bytes, and maybe there's a better name. The other is that there has been discussion in the past, on bringing back rather than being able to retrieve more descriptive information of the matrix like the axis labels, the size of the matrix, things like that.

Using the bare endpoint is one place for this we had discussed in the past, adding that information to the ticket and points since the ticket returns a JSON. However, doing that doesn't help anyone that wants the data in line.

the idea is not to store all the metadata here, but just destructor, in a certain sense of the matrix

SU

since it's an addition, we, you know, we don't have any, we can start doing the code to put it in, and then have it ready if, if we decide that everyone that you know, people want to use it. I do like the idea of the matrix I think you had at the time we kind of did it as a matrix.

JD

We are currently just finishing up our prototypes and working on our selection of architecture, which is likely to be loom pie as a storage and then should start our implementation and hopefully have our implementation done by end of next month.

JD

say a selection of gene IDs or a selection of sample IDs, there is likely to be a limit whereby we can't support a query of that many gene IDs or sample IDs.

So just from a processing standpoint, all is sometimes easier than a collection of 10,000 Gene IDs.

2022-01-19: Data Connect & Json Schema

Chair: Sean Upchurch, Emilio Palumbo

Attendees “Name (Affiliation)”: Anup Mahurkar,Reggan Thomas

Meeting recordings: https://us02web.zoom.us/rec/share/0-L61BERInmuWxpcspcFfPqdHVVtSgSA7lDdkM0NG_LIWQickCTrjLUH2s84fUHN.nEoQ5S23fErPPV6T?startTime=1642604131000

Presentation :  https://docs.google.com/presentation/d/1S3wyz02ObOEEJSUKapW-ZR-DmUEF2YPv/edit#slide=id.p1

 Notes :

• SU: So I, it looks like, again, a new viewer on these meetings. But it seems like it will probably work for our purposes, to kind of point at data connect as a means to retrieve the, you know, RNA get IDs, and use that as our search engine. Did you see any, any red flags? Have you had time to look in more detail at their specs?
• AM: No, I mean, I think the designer to be generic enough so that each implementer can use their own data model and support the search. So I don't see any major issues there. I think, as we discussed, right, the biggest gap is between their API just returning a set of IDs, and all of the RNA seeking API's user token, right on a particular single ID for whatever you want to call it. And so they need to do some way of translation from our list of ids, like questions, we get a bunch of doors IDs back, how do you translate that into what RNA seeks to get API uses? Just the only sort of gap I see?

• SU : we use the expression ID as, as a means of identifying a matrix, and that matrix ID is really kind of more on the provider side, in the sense that, you know, the actual matrix that's delivered in response to an RNA GET request, could act could be a subset of the matrix that is assigned to that expression ID, because we do have the slicing filters. If you have, like, GTEx, for instance, last we heard, they were planning on just having a single ID for their data, and it handles all of the filtering, you know, at request time. And so any, you know, any returns with GTEx would, basically that all have the exact same expression ID. so, if, you know, data connect, seems like it will work and so, do we want to come up with, you know, some advice document or something like that, you know, some kind of recommended search terms, ot part of the RNA gets back but you know, maybe a, you know, a practices document linked to the, you know, the, the top level, you know, read me,

if you want to use if you want to put tissue in as a metadata, then use the term tissue use

These use these ontologies to populate that term size. The question is, do we want to write something like that? You know, for search. ? when you return a search term, how do you, you know, how do you want to use the expression ID in there? And also, I think, you know, to kind of help promote interoperability, if we can come up with a search language that we could recommend. I think that that might, that might be a good idea. I mean, what are people's thoughts on coming up with some sort of advice and recommendation, you know, guidance.

• AM : Because I feel like essentially, the way the discovery API is written, it's left to the provider. And if every provider uses a different vocabulary for searching, then if there's a distributed federated data set, then every time every provider will have a different search term, right. And so at least if you had a recommendation, saying that, hey, this is what we recommend you use, then that makes it easier.

• EP : I think that conceptually, this would be basically the same as setting like an ontology for searching, right? It will just be like a recommendation, and not enforced. But

 at some point this would bring to maybe to the definition of a real ontology for searching and bring to something more official,

• SU : A few months ago, you know, a new one had a list of requirements that included searching by, by certain filters, and I tissue amongst them, you know, disease, state, things like that. And I think those are, those are common, you know, search terms. And so I think what we want to do is try to capture what we think are the most common ones. And then maybe not even, you know, recommend an ontology, but just sort of define what that term is. And we can pull that definition from an existing ontology. But then it's just it's just really a list of fields of filters.

• EP: to make the provider use the same terms. But probably in the long term. This should help to build a real search ontology for any GED because otherwise, there is always the risk that you recommend something but providers can do whatever they want, because there is no, there is not the official and centralise the search ontology for the service

• Improve the documentation.
• SU : ll the expression endpoints filter things the same way, it's just the description of the endpoints themselves. You know, some of them mentioned filtering, and some of them don't mention filtering. the other thing that could probably be clearer in the documentation is that the matrix is really the core entity of the API

way the documentation is written now, you know, we describe a lightweight, you know, Project study structure. And we kind of did it from the top down. But what that does mean is that project and study are the first two things that you read about when you're reading the API. And you don't really get into, you know, the expression and continuous objects until later. if we're going to use data connect, as our entry point, and data connect, is going to return expression IDs.

Is this the time to remove the project and study? o do they belong in the API now?

Is it a breaking change? If we do this? I mean, it's kind of a big, it's kind of a big change. I'm not sure if it's a breaking change. And I know from the discussions that we've had with, with Ben and Jaron, and actually with David, back a couple years ago, that, you know, the the, the whole project study structure is has been a little confusing, and in some ways a little unnecessary.

• EP: filtering, is that it's, it's, I mean, at least to him that it was not part of the of the design of the API, filtering an expression ID. So filtering one object for him is a bit weird.

you have an object, which is a matrix, which isn't divisible and you cannot filter that. But then you have expression or expression sets

that also have IDs, but that represents columns and rows of the matrix. I know that this is not probably the time to talk about these and it's quite a big change. But probably, it makes more sense than the

I mean, having one matrix and filter by,

by parameters. I don't know if I was clear about this.

And this would also bring to the using of project and studies. And as you were sitting and you said, Shawn, projects and studies, organisation has always been confusing, and probably it's the time to remove this and make the API more metrics and expression centric.

• SU: I think what you're proposing is, is two levels of i t's What do you have a, you have a matrix ID, which is similar to the current expression ID Exactly. In that it identifies the core, the core matrix? Exactly. And then we get and then you want to add expression, set ID, whatever is right to

specify basically a subset of devices. Yes. Yes. The core of the mother matrix?

• SU: if you want to think of it in terms of where RNA gets currently, you're going to see what you specify. When you retrieve, you specify the ID, and then you can slice it. Yeah, and that's what that's where we sit now, that Id never changes, which is similar to what you're proposing here. So really, what we're adding is, when you actually retrieve that specified slice, you're going to get another ID that represents that slice. And if you want to go back and get that same slice again, you can do it with this ID, rather than going to the

the original expression ID and feed it the same parameters.

Usually a shortcut, so you don't have to feed it all the same filtering parameters

• EP:  And one more thing that we were discussing on top of this is maybe changing the way that the filtering is done. So that instead of using like, instead of calling these filters on the matrix, you can just

it's just a matter of changing the, the endpoints and like, calling it in a different way, or creating endpoints just for selecting for slicing

metrics. So it's not filtering, but it's slicing, or selecting columns and rows.

• AM : if we say that a sub slice gets its own expression ID, then then we are saying that that slice is no longer ephemeral, right, that the data provider has to keep a log of the slice and ID that was issued of for some duration of a permanently depending on what the contract is. this is an idea that we could eventually, to avoid the persistence of, of expressions that IDs, we could skip this part, keep just the matrix ID as, as it's now, but re rephrase the idea of filters and calling them slicing selectors or as I send in the charts, maybe filter by matrix ID, and then like an additional
• SU: If there's a semantic that we can take that makes it clear that we are providing a subset of an already selected object, then that's, that's a good, that's a good clarity point for the documentation.
• EP : We can think about or scaping this completely, or maybe like using it as a caching mechanism that can last like 24 hours, six hours. So it's just like, Okay, I do this search. Now, if I do it again,

the thing is cached, and there's an ID, so I can reuse it. And after one day, this ID is not valid anymore. And the thing is,

is deleted. So I don't know, this depends on how we think the use case would fit better.

the most important thing was this because there's the idea of filtering versus slicing or selecting.

• AM : I think I mean, I can see your value in it right about having a separate ID for your

query, it just will observe things from an implementation standpoint. And whether we would sort of have some mechanism where if somebody queries with an ID and the provider does not have it, it's out of the caches run out, right? Then there should be a valid error code. So the API,

make sure that the client understands.

• EP: we could remove the expression ID and put like slash metrics slash ID endpoints that will return the entire metrics, or we can keep it as it is like you're writing like, expressions measure ID. more clear, like slash metrics, slash ID and then slash expression for filtering.

But I mean, we are changing the whole API here now.

So this is going to be a breaking change.

• AM : this sort of slicing, having a slicing endpoint is that then the implementer can decide right? Like, essentially, for a particular expression, ID and a set of parameters.

If they save it, they can then persist the sub slice to improve performance. And as long as the query is the same, they know they can use an existing matrix without having to filter on the fly.

• SU : If we remove the non ID endpoints, then we destroy this model.So we have to kind of decide if we're going to decide what we want to do.

if we remove it We need to, to add another new endpoint for while I'm actually not 100% sure whether it will be seen as a breaking change to remove an endpoint

My understanding of a breaking change is that new versions of the API need to be able to handle, you know.Queries, no query queries to do.

I'm sorry, it's too early for me to think about this right?

ou need to be backwards compatible for it to not be breaking. So if we have a 1.1 query come in,it needs to be able to be handled

by a 2.0. Because when you do a breaking change, you become a 2.0.Now removing an end point,you're just going to end up with a, you know, you're going to throw an error.

What to look at? exactly see what is considered a breaking change in the eyes of the steering committee?

• AM: yeah, because even removing filtering parameters from the ID endpoint can be considered a breaking change, right?
• EP: I mean, depends, because what breaking change means no. Because through that, if you remove filters, and they were optional, it's not going to break the API itself. But then you will get the meaning less reply. No, because right, you won't get.

Yeah, yeah. So this kind of talk from this point of view is breaking because you get the wrong response. But still the API is working. That's true, is not, is not breaking. So I don't know what they consider breaking.

• AP : we can have a timeline for deprecation, right? Because a slicer endpoint and you give some people a year or two to deprecate the old filtering, so that people have time to implement it, but they know it's going to be deprecated. Okay, but this I don't know if this works for Global Alliance as well. No. So if they accept these kind of things, or if they consider any way of breaking change, removing this, I mean, I don't know. But I think yeah, no, I do. I think you have a very good point is
• SU: we need to provide what the new endpoint is going to look like. And we could just we could, we could do that by pointing to a dev build.

• And then, and then have a date, where it will become, you know, the next release. And then everything just just breaks. So we just have people build to dev for, you know, six months or something like that,before the dev builds or do a release candidate or something like that for a period of time.

• SU : maybe Emilio, you could could write up

a subparagraph, or something describing what you want to do that we could, we could email out to the list before the next call. Some No, maybe, you know, maybe by the end of the week, or early next week, to give people time to think about it before the call.

• EP: We try to try to discuss this a bit more with the with the media, and we can try to formalise

what we think would be a good way of doing this, and then we send it to the whole list.

• EP: about projects and studies, I think we would also need to discuss these with the rest

Yeah. Because I mean, I agree that probably this is the time to remove these because they are redundant and not used.

But we need to talk to two other people and see what,

what they think.

• SU : If you and Emilio could write up, you propose changes to the endpoints, I'll kind of put together a kind of a list of what we've been already discussing. Your Reagan's going to do the agenda as well, by the second email, specifically raising these points for more detailed discussion on the call in two weeks, and get that out, maybe by Monday afternoon. So to give people you know, at least a week to think about it.

                 JSON schema for delivering output matrices

• SU : last thing I had here on the agenda is to start looking at the JSON output and how we want to define it I'm not sure how deeply you want to delve into this right now, but my

Basic idea for it is essentially based on what GTEx. And to an extent what ENCODE is already putting out. But I think the main thing is how we want to represent the matrix in JSON. And what GTEx has, is they've got a, they have a JSON element that contains a vector of the expression values.

• SU : probably the way to do it in JSON, is just to have the, essentially each row of the matrix be a vector, and then

probably have a header block, which is which will contain the ID of the matrix and the

the sample labels.

So that way, you know which entry in the array corresponds to what sample, and then after that does pretty much be the GTEx output.

• AM: think to a large extent, that's true. But the only nuance that I think, you know, definitely Jared can speak more to but if I remember correctly, the way we use the GTEx APR at the centre of the JSON, there are some attributes that come with that, like, for instance, they might organised within the tissue based on males and females, because that's one of the toggles that you can do in there. Some other API so you can get information about some attributes.

And there may be slightly different ways they organise that information.

• SU: My understanding and correct me if I'm wrong, is that they're out there. JSON output is their primary output.
• AM: not a huge issue, but they are definitely discuss a little bit because one of the things that they don't return is that they don't return any sample attributes with expression value.

So you will know if let's say you want there are some outliers and you wanted to find out okay, what are the IDs of these outliers right

at the endpoint there's no way simple way of doing it because they just give you a vector of all the values for the gene expression across all the samples we got any very nice sample information

• SU : I think one big advantage of JSON is that
• It's, you know, it's slices paginates, you know, nicely and the structure works for both small and then large.

2022-MM-DD: Template

Chair: Sean Upchurch

Attendees “Name (Affiliation)”: