From b986ea3542b67a13cbe620011f676874c5419787 Mon Sep 17 00:00:00 2001 From: Michael Baudis <675030+mbaudis@users.noreply.github.com> Date: Mon, 19 Feb 2024 11:24:55 +0100 Subject: [PATCH] collationType PMID => pubmed ... and docs --- docs/beaconplus.md | 271 ------------------ docs/common/beacon-api.md | 234 +++++++++++++++ docs/img/logo_beacon.png | Bin 0 -> 8707 bytes mkdocs.yaml | 2 +- .../classificationTree/SubsetsTree.js | 17 +- .../searchForm/BiosamplesSearchForm.js | 2 +- src/modules/details-pages/celllinePage.js | 2 +- .../service-pages/dataVisualizationPage.js | 13 +- 8 files changed, 252 insertions(+), 289 deletions(-) delete mode 100644 docs/beaconplus.md create mode 100644 docs/common/beacon-api.md create mode 100644 docs/img/logo_beacon.png diff --git a/docs/beaconplus.md b/docs/beaconplus.md deleted file mode 100644 index 927dfe7b..00000000 --- a/docs/beaconplus.md +++ /dev/null @@ -1,271 +0,0 @@ -# Beacon - Discovery Services for Genomic Data - -![Beacon Icon](http://info.progenetix.org/assets/img/logo_beacon.png){ align=right width=25px}The Beacon protocol defines an open standard for genomics data discovery, -developed by members of the Global Alliance for Genomics & Health. Since 2016, -the Beacon protocols is being developed through the -ELIXIR Beacon project as a GA4GH driver project.

- -As part of the project, since early 2016 the [Theoretical Cytogenetics and Oncogenomics Group](http://info.baudisgroup.org) at the University of Zurich develops the -[Beacon+ demonstrator](https://beacon.progenetix.org/ui/), -to show current functionality and test future Beacon protocol extensions. - -The Beacon+ implementation is a -custom front end on top of the [Progenetix](http://progenetix.org) -dataset, with emphasis on structural genome variations from cancer samples. - -!!! note "Technical Documentation" - - An increasing amount of documentation relevant to the Progenetix API can be - found in those locations: - - * [`bycon` package documentation](http://bycon.progenetix.org) - * Beacon v2 [documentation site](http://docs.genomebeacons.org) - - - - -## BeaconPlus Data / Query Model - -The Progenetix / Beaconplus query model utilises the [GA4GH core data model](https://schemablocks.org/standards/ga4gh-data-model.html) for genomic and (biomedical, procedural) queries and data delivery. - -The GA4GH data model for genomics recommends the use of a principle object hierarchy, consisting of - -* `variant` (a.k.a. _genomicVariation_) - - a single molecular observation, e.g. a genomic variant observed in the analysis of the DNA from a biosample - - mostly corresponding to the "allele" concept, but with alternate use similar to that in VCF (e.g. CNV are no typical "allelic variants") - - in Progenetix identical variants from different sampleas are identified through - a compact digest (`variantInternalId`) and can be used to retrieve those distinct - variants (c.f. "line in VCF") -* `analysis` - - the entirety of all variants, observed in a single experiment on a single sample - - a _callset_ can be compared to a data column in a __VCF__ variant annotation file - - _callset_ has an optional position in the object hierarchy, since _variants_ describe biological observations in a biosample -* `biosample` - - a reference to a physical biological specimen on which analyses are performed -* `individual` - - in a typical use a human subject from which the biosample(s) was/were extracted - -In the Progenetix backend we mirror the GA4GH data model in the storage system, consisting of the corresponding - -* variants -* callsets (compares to runs + analyses) -* biosamples -* individuals - -collections of MongoDB databases. These collections are addressed by scoped queries. - -!!! note "BeaconPlus Extensions of the Beacon API" - - While the Progenetix Beacon API implements the Beacon framewiork and in general - follows the [Beacon v2 default model](http://docs.genomebeacons.org/models/) it also - adds some extended functionality - e.g. - - * limited support for Boolean filter use (i.e. ability to force an override of the general - `AND` with a general `&filterLogic=OR` option) - * experimental support of a `/phenopackets` entity type & `&requestedSchema=phenopacket` - output option - * overriding the Beacon JSON response format w/ a datatable export `&output=table` - e.g. for biosamples or individuals - - [progenetix.org/beacon/individuals/?filters=pgx:icdom-85003,EFO:0030041&output=table](http://progenetix.org/beacon/individuals/?filters=pgx:icdom-85003,EFO:0030041&output=table) ... delivers a - table with breast cancer individuals and "alive" status on last followup - * geoqueries using [`$geoNear`](https://www.mongodb.com/docs/upcoming/reference/operator/aggregation/geoNear/) - parameters or `city` matches - - -### `filters` Filters / Filtering Terms - -Filters represent a way to allow the resource provider to direct "self-scoped" query values to the corresponding attributes in their backend resource. In the Progenetix implementation, a lookup table followed by scope assignment is used to map prefixed filter values to the correct attributes and collections. Most of the filter options are -based on ontology terms or identifiers in CURIE format (e.g. `NCIT:C4033`, `cellosaurus:CVCL_0030` or `PMID:16004614`). For use case examples please -look below; documentation of available ontologies and how to find out about available -terms can be found on the [Classifications and Ontologies](common/classifications-and-ontologies.md) page. - -In Beacon v2, the new `FilteringTerms` schema adds options to specify different -types of filters (`OntologyFilter`, `AlphanumericFilter`, `CustomFilter`) which can -contain a number of parameters to define e.g. scope or matching behaviour. These -more complex terms are only available through `PUT` requests. Also, not all filtering -option may be implemented (e.g. fuzzy matches). - -Please see Beacon's [`Filters`](http://docs.genomebeacons.org/filters/) documentation -for more information. - -##### Example - -``` JSON -"filters": [ - { - "id": "NCIT:C4536", - "includeDescendantTerms": false - } -], -``` - -#### Hierarchical Terminologies in Filter Queries - -Hierarchical terminologies allow queries at different levels, to include all its children terms. The Progenetix query filter system adopts this inclusion logic if the classification / code type is hierarchy-based. However, the `includeDescendantTerms` pragma can be used to modify this behaviour - globally -if provided in a `GET` request (`&includeDescendantTerms=false`) or as part of -filter objects (see above). - -Examples for codes with hierarchical treatment within the filter space are: - -* NCIt - - true, deep hierarchical ontology of cancer classifications -* Cellosaurus - - derived cell lines are also accessible through the code of their parental line - --------------------------------------------------------------------------------- - -## Beacon API - -### Beacon-style JSON responses - -The Progenetix resource's API utilizes the `bycon` framework for data query and -delivery and represents a custom implementation of the Beacon _v2_ API. - -The standard format for JSON responses corresponds to a generic Beacon v2 -response, with the `meta` and `response` root elements. Depending on the endpoint, -the main data will be a list of objects either inside `response.results` or (mostly) -in `response.resultSets.results`. Additionally, most API responses (e.g. for biosamples -or variants) provide access to data using _handover_ objects. - -Example responses can be genrated through the [path examples](#beacon-v2-path-examples-in-progenetix) -below. - -Please be aware that Beacon responses use `camelCased` parameter names. - -### Beacon v2: Path Examples in Progenetix - -The Beacon v2 protocol uses a REST path structure for consistant data access. - -The Beacon+ implementation - developed oin the [`bycon` project](https://github.com/progenetix/bycon/) -implements an expanding set of those Beacon v2 paths for the [Progenetix](http://progenetix.org) -resource. - ----- - -#### Base `/` - -The root path provides the standard `BeaconInfoResponse`. - -* [/](http://progenetix.org/beacon/) - ----- - -#### Base `/filtering_terms` - -##### `/filtering_terms/` - -* [/filtering_terms/](http://progenetix.org/beacon/filtering_terms/) - - -##### `/filtering_terms/` + query - -* [/filtering_terms/?filters=PMID](http://progenetix.org/beacon/filtering_terms/?filters=PMID) -* [/filtering_terms/?filters=NCIT,icdom](http://progenetix.org/beacon/filtering_terms/?filters=NCIT,icdom) - ----- - -#### Base `/biosamples` - -##### `/biosamples/` + query - -* [/biosamples/?filters=cellosaurus:CVCL_0004](http://progenetix.org/beacon/biosamples/?filters=cellosaurus:CVCL_0004) - - this example retrieves all biosamples having an annotation for the Cellosaurus _CVCL_0004_ - identifier (K562) - -##### `/biosamples/{id}/` - -* [/biosamples/pgxbs-kftva5c9/](http://progenetix.org/beacon/biosamples/pgxbs-kftva5c9/) - - retrieval of a single biosample - -##### `/biosamples/{id}/g_variants/` - -* [/biosamples/pgxbs-kftva5c9/g_variants/](http://progenetix.org/beacon/biosamples/pgxbs-kftva5c9/g_variants/) - - retrieval of all variants from a single biosample - - currently - and especially since for a mostly CNV containing resource - `variants` means "variant instances" (or as in the early v2 draft `variantsInSample`) - -##### `/biosamples/{id}/analyses/` - -* [/biosamples/pgxbs-kftva5c9/analyses/](http://progenetix.org/beacon/biosamples/pgxbs-kftva5c9/analyses/) - ----- - -#### Base `/individuals` - -##### `/individuals/` + query - -* [/individuals/?filters=NCIT:C7541](http://progenetix.org/beacon/individuals/?filters=NCIT:C7541) - - this example retrieves all individuals having an annotation associated with _NCIT:C7541_ (retinoblastoma) - - in Progenetix, this particular code will be part of the annotation for the _biosample(s)_ associated with the returned individual -* [/individuals/?filters=PATO:0020001,NCIT:C9291](http://progenetix.org/beacon/individuals/?filters=PATO:0020001,NCIT:C9291) - - this query returns information about individuals with an anal carcinoma (**NCIT:C9291**) and a known male genotypic sex (**PATO:0020001**) - - in Progenetix, the information about its sex is associated with the _Individual_ object (and rtherefore in the _individuals_ collection), whereas the information about the cancer type is a property of the _Biosample_ (and therefore stored in the _biosamples_ collection). However, - cross entity queries are no problem since we support full aggregation across the different - models. - -##### `/individuals/{id}/` - -* [/biosamples/pgxind-kftx25hb/](http://progenetix.org/beacon/biosamples/pgxind-kftx25hb/) - - retrieval of a single individual - -##### `/individuals/{id}/genomicVariations/` - -* [/individuals/pgxind-kftx25hb/genomicVariations/](http://progenetix.org/beacon/individuals/pgxind-kftx25hb/genomicVariations/) - - retrieval of all variants from a single individual - - currently - and especially since for a mostly CNV containing resource - `variants` means "variant instances" (or as in the early v2 draft `variantsInSample`) - ----- - -#### Base `/genomicVariations` - -There is currently (April 2021) still some discussion about the implementation and naming -of the different types of genomic variant endpoints. Since the Progenetix collections -follow a "variant observations" principle all variant requests are directed against -the local `variants` collection. - -If using `g_variants` or `variants_in_sample`, those will be treated as aliases. - -##### `/genomicVariations/` + query - -* [/genomicVariations/?assemblyId=GRCh38&referenceName=17&variantType=DEL&filterLogic=AND&start=7500000&start=7676592&end=7669607&end=7800000](http://progenetix.org/beacon/genomicVariations/?assemblyId=GRCh38&referenceName=17&variantType=DEL&filterLogic=AND&start=7500000&start=7676592&end=7669607&end=7800000) - - This is an example for a Beacon "Bracket Query" which will return focal deletions in the TP53 locus (by position). - -##### `/genomicVariations/{id}/` or `/g_variants/{id}/` - -* [/genomicVariations/5f5a35586b8c1d6d377b77f6/](http://progenetix.org/beacon/genomicVariations/5f5a35586b8c1d6d377b77f6/) - -##### `/genomicVariations/{id}/biosamples/` - -* [/genomicVariations/5f5a35586b8c1d6d377b77f6/biosamples/](http://progenetix.org/beacon/genomicVariations/5f5a35586b8c1d6d377b77f6/biosamples/) - ----- - -#### Base `/analyses` (or `/callsets`) - -The Beacon v2 `/analyses` endpoint accesses the Progenetix `callsets` collection -documents, i.e. information about the genomic variants derived from a single -analysis. In Progenetix the main use of these documents is the storage of e.g. -CNV statistics or binned genome calls. - -##### `/analyses/` + query - -* [/analyses/?filters=cellosaurus:CVCL_0004](http://progenetix.org/beacon/analyses/?filters=cellosaurus:CVCL_0004) - - this example retrieves all biosamples having an annotation for the Cellosaurus _CVCL_0004_ - identifier (K562) - -------------------------------------------------------------------------------- - -## `bycon` Beacon Server - -The [`bycon`](https://github.com/progenetix/bycon) project provides a combination of a Beacon-protocol based API with additional API services, used as backend and middleware for the Progenetix resource. - -`bycon` has been developed to support Beacon protocol development following earlier implementations of Beacon+ ("beaconPlus") with now deprected Perl libraries. The work tightly integrates with the [ELIXIR Beacon](http://beacon-project.io) project. - -`bycon` has its own documentation at [bycon.progenetix.org](http://bycon.progenetix.org). - - - - - diff --git a/docs/common/beacon-api.md b/docs/common/beacon-api.md new file mode 100644 index 00000000..768f702a --- /dev/null +++ b/docs/common/beacon-api.md @@ -0,0 +1,234 @@ +# Beacon - Discovery Services for Genomic Data + + +![Beacon Icon](/img/logo_beacon.png){ align=right width=25px}The Beacon protocol +defines an open standard for genomics data discovery by the Global Alliance for +Genomics & Health GA4GH with technical implementation through the +ELIXIR Beacon project. Since 2015 the +[Theoretical Cytogenetics and Oncogenomics Group](https://info.baudisgroup.org) +at the University of Zurich has contributed to Beacon development, partially with the +[Beacon+ demonstrator](https://beacon.progenetix.org/ui/), +to show current functionality and test future Beacon protocol extensions. The +Beacon+ as well as the [Progenetix](https://progenetix.org) +and [cancercelllines.org](https://cancercelllines.org) websites run on top of the +open source [`bycon`](https://bycon.progenetix.org) stack which represent a full +Beacon implementation. + +!!! note "Technical Documentation" + + An increasing amount of documentation relevant to the Progenetix API can be + found in those locations: + + * [`bycon` package documentation](http://bycon.progenetix.org) + * Beacon v2 [documentation site](http://docs.genomebeacons.org) + + +## BeaconPlus Data / Query Model + +The Progenetix / Beaconplus query model utilises the Beacon core data model for +genomic and (biomedical, procedural) queries and data delivery. The model uses an +object hierarchy, consisting of + +* `variant` (a.k.a. _genomicVariation_) + - a single molecular observation, e.g. a genomic variant observed in the analysis of the DNA from a biosample + - mostly corresponding to the "allele" concept, but with alternate use similar to that in VCF (e.g. CNV are no typical "allelic variants") + - in Progenetix identical variants from different sampleas are identified through + a compact digest (`variantInternalId`) and can be used to retrieve those distinct + variants (c.f. "line in VCF") +* `analysis` + - the entirety of all variants, observed in a single experiment on a single sample + - the result of an _analysis_ represents a _callset_ , comparable to a data + column in a __VCF__ variant annotation file + - _callset_ has an optional position in the object hierarchy, since the _variants_ + themselves describe biological observations in a biosample +* `biosample` + - a reference to a physical biological specimen on which analyses are performed +* `individual` + - in a typical use a human subject from which the biosample(s) was/were extracted + +The `bycon` framework implemented for Progenetix and related collections such as +cancercelllines.org implements these core entities as data collections in a MongoDB database. + +!!! note "BeaconPlus Extensions of the Beacon API" + + The Progenetix Beacon API implements the Beacon framework and [Beacon v2 + default model](http://docs.genomebeacons.org/models/) with some extended functionality - + e.g. + + * limited support for Boolean filter use (i.e. ability to force an override of the general + `AND` with a general `&filterLogic=OR` option) + * experimental support of a `/phenopackets` entity type & `&requestedSchema=phenopacket` + output option + * additional service endpoints, e.g. for biosamples or individuals + * geoqueries using [`$geoNear`](https://www.mongodb.com/docs/upcoming/reference/operator/aggregation/geoNear/) + parameters or `city` matches + + +### `filters` Filters / Filtering Terms + +Besides variant parameters the Beacon protocol defines `filters` as (self-)scoped +query parameters, e.fg. for phenotypes, diseases, biomedical performance or technical +entities. Most of the filter options are based on ontology terms or identifiers in +CURIE format (e.g. `NCIT:C4033`, `cellosaurus:CVCL_0030` or `PMID:16004614`). For use case examples please +look below; documentation of available ontologies and how to find out about available +terms can be found on the [Classifications and Ontologies](common/classifications-and-ontologies.md) +page. Please see Beacon's [`Filters`](http://docs.genomebeacons.org/filters/) documentation +for more information, e.g. about `OntologyFilter`, `AlphanumericFilter`, `CustomFilter` types. + +The Progenetix query filter system adopts a hierarchical logic for filtering terms. +However, the `includeDescendantTerms` pragma can be used to modify this behaviour. +Examples for codes with hierarchical treatment within the filter space are: + +* NCIt + - true, deep hierarchical ontology of cancer classifications +* Cellosaurus + - derived cell lines are also accessible through the code of their parental line + +##### Example + +``` JSON +"filters": [ + {"id": "NCIT:C4536", "includeDescendantTerms": false} +], +``` + +### Beacon-style JSON responses + +The Progenetix resource's API utilizes the `bycon` framework for implementation of + the Beacon _v2_ API. The standard format for JSON responses corresponds to a generic Beacon v2 +response. Depending on the endpoint, the main data will be a list of objects either +inside `response.results` or (mostly) in `response.resultSets[...].results`. Additionally, +most API responses provide access to data using _handover_ objects. + +Example responses can be genrated through the [path examples](#beacon-v2-path-examples-in-progenetix) +below. Please be aware that Beacon responses use `camelCased` parameter names. + +### Beacon v2: Path Examples in Progenetix + +The Beacon v2 protocol uses a REST path structure for consistant data access. +The [`bycon` project](https://github.com/progenetix/bycon/) +implements an expanding set of those Beacon v2 paths for the {{config.api_site_label}} +resource. + +---- + +#### Base `/` + +The root path provides the standard `BeaconInfoResponse`. + +* [/]({{config.api_web_root}}/beacon/) + +---- + +#### Base `/filtering_terms` + +* [/filtering_terms/]({{config.api_web_root}}/beacon/filtering_terms/) + +##### `/filtering_terms/` + query + +* [/filtering_terms/?filters=PMID]({{config.api_web_root}}/beacon/filtering_terms/?filters=PMID) +* [/filtering_terms/?filters=NCIT,icdom]({{config.api_web_root}}/beacon/filtering_terms/?filters=NCIT,icdom) + +---- + +#### Base `/biosamples` + +##### `/biosamples/` + query + +* [/biosamples/?filters=cellosaurus:CVCL_0004]({{config.api_web_root}}/beacon/biosamples/?filters=cellosaurus:CVCL_0004) + - this example retrieves all biosamples having an annotation for the Cellosaurus _CVCL_0004_ + identifier (K562) + +##### `/biosamples/{id}/` + +* [/biosamples/pgxbs-kftva5c9/]({{config.api_web_root}}/beacon/biosamples/pgxbs-kftva5c9/) + - retrieval of a single biosample + +##### `/biosamples/{id}/g_variants/` + +* [/biosamples/pgxbs-kftva5c9/g_variants/]({{config.api_web_root}}/beacon/biosamples/pgxbs-kftva5c9/g_variants/) + - retrieval of all variants from a single biosample + - currently - and especially since for a mostly CNV containing resource - `variants` means "variant instances" (or as in the early v2 draft `variantsInSample`) + +##### `/biosamples/{id}/analyses/` + +* [/biosamples/pgxbs-kftva5c9/analyses/]({{config.api_web_root}}/beacon/biosamples/pgxbs-kftva5c9/analyses/) + +---- + +#### Base `/individuals` + +##### `/individuals/` + query + +* [/individuals/?filters=NCIT:C7541]({{config.api_web_root}}/beacon/individuals/?filters=NCIT:C7541) + - this example retrieves all individuals having an annotation associated with _NCIT:C7541_ (retinoblastoma) + - in Progenetix, this particular code will be part of the annotation for the _biosample(s)_ associated with the returned individual +* [/individuals/?filters=PATO:0020001,NCIT:C9291]({{config.api_web_root}}/beacon/individuals/?filters=PATO:0020001,NCIT:C9291) + - this query returns information about individuals with an anal carcinoma (**NCIT:C9291**) and a known male genotypic sex (**PATO:0020001**) + - in Progenetix, the information about its sex is associated with the _Individual_ object + (stored in _individuals_), whereas the cancer type is a property of the _Biosample_. + However, cross entity queries are supported through full aggregation across the different entities. + +##### `/individuals/{id}/` + +* [/biosamples/pgxind-kftx25hb/]({{config.api_web_root}}/beacon/biosamples/pgxind-kftx25hb/) + - retrieval of a single individual + +##### `/individuals/{id}/genomicVariations/` + +* [/individuals/pgxind-kftx25hb/genomicVariations/]({{config.api_web_root}}/beacon/individuals/pgxind-kftx25hb/genomicVariations/) + - retrieval of all variants from a single individual + - currently - and especially since for a mostly CNV containing resource - `variants` means "variant instances" (or as in the early v2 draft `variantsInSample`) + +---- + +#### Base `/genomicVariations` + +There is currently (April 2021) still some discussion about the implementation and naming +of the different types of genomic variant endpoints. Since the Progenetix collections +follow a "variant observations" principle all variant requests are directed against +the local `variants` collection. + +If using `g_variants` or `variants_in_sample`, those will be treated as aliases. + +##### `/genomicVariations/` + query + +* [/genomicVariations/?assemblyId=GRCh38&referenceName=17&variantType=DEL&filterLogic=AND&start=7500000&start=7676592&end=7669607&end=7800000](h{{config.api_web_root}}/beacon/genomicVariations/?assemblyId=GRCh38&referenceName=17&variantType=DEL&filterLogic=AND&start=7500000&start=7676592&end=7669607&end=7800000) + - This is an example for a Beacon "Bracket Query" which will return focal deletions in the TP53 locus (by position). + +##### `/genomicVariations/{id}/` or `/g_variants/{id}/` + +* [/genomicVariations/5f5a35586b8c1d6d377b77f6/]({{config.api_web_root}}/beacon/genomicVariations/5f5a35586b8c1d6d377b77f6/) + +##### `/genomicVariations/{id}/biosamples/` + +* [/genomicVariations/5f5a35586b8c1d6d377b77f6/biosamples/]({{config.api_web_root}}/beacon/genomicVariations/5f5a35586b8c1d6d377b77f6/biosamples/) + +---- + +#### Base `/analyses` + +The Beacon v2 `/analyses` endpoint accesses the information about the genomic variants +derived from a single analysis. In Progenetix the main use of these documents is the storage of e.g. +CNV statistics or binned genome calls. + +##### `/analyses/` + query + +* [/analyses/?filters=cellosaurus:CVCL_0004]({{config.api_web_root}}/beacon/analyses/?filters=cellosaurus:CVCL_0004) + - this example retrieves all biosamples having an annotation for the Cellosaurus _CVCL_0004_ + identifier (K562) + +------------------------------------------------------------------------------- + +## `bycon` Beacon Server + +The [`bycon`](https://github.com/progenetix/bycon) project provides a combination of a Beacon-protocol based API with additional API services, used as backend and middleware for the Progenetix resource. + +`bycon` has been developed to support Beacon protocol development following earlier implementations of Beacon+ ("beaconPlus") with now deprected Perl libraries. The work tightly integrates with the [ELIXIR Beacon](http://beacon-project.io) project. + +`bycon` has its own documentation at [bycon.progenetix.org](http://bycon.progenetix.org). + + + + + diff --git a/docs/img/logo_beacon.png b/docs/img/logo_beacon.png new file mode 100644 index 0000000000000000000000000000000000000000..e6311e52e6948be1a9d495d37b357076194c4cfc GIT binary patch literal 8707 zcmV+eBK+NnP)7X(yPL_sX5 zu>%64NUtJD@6wlLdoOo>a~5v0L11^;y9Isz_`H^~d-vY=J#)^Pxie>8K?uFllho4E z@@-;b;wk*|tA;)okikzt6IE7LPI7Q?sF*fw8VU{$J};F@dmH+k3=TzIrKF^+U$kfu zf9lk!Xy(kB$il(`xwyC_Gnvf)`yaqAL=eQ^!^6Y1l0kjiyhZt~R{( ze$mmTIA?%bJY zZf>p>xb}V#Uawxg>Vv=Itrr$xZf@?vl`B`aXyWhG6<9JH*W24W0!Q?LFB-tVMMg%t z{QUFJvhMmjbp@9F>#x5S*VWbi@In9-i^aW9o;-OOz-jC6H1UhemoMjJXJ@bI(E#am z`WJim?#+Z~*;#U|E5Qw$J$p8~b?eq|_*~xTaR3Vo3$53zS<|FWa;z(X#Y3bI2nhIH zBocklQvkkk|NedFdGqE;;p7bkuf1P%a&pRTXlNL1v;c8){VXafYWJQ!d(xq~>dW70 z;uoREbL`l$%TJy>nJ(ZLx zrsw75SsT;`MnpvH*AyT?f$kRs8Tc$Xc@Q*z_!~K7HEY%^1cMFa#e&r+e};4!WR9r` zY-acaT8=mX($L1Q*)b$;02_0^wpo00&2C8E*QGxKEtp>FIedI5_ykjT<)( z#>K@sq^GB^!%p73prF94q@=_QAKwh8L}pK)J~hLM@!X`OBnKRkk6(jtNZ{_>yECzcaRDL;RQV>u-!5Ic zgwtramt{{6E$oR;y#Gr_a_K877L5h z9}$B72+97bfyKPWX0r!lA2%C=@^f}}&RMWvff#No+3a(3b7vU^z`J+v?pwKXWm8a4 z&;{K5=JEM_6P2GM_$G2$$#|J0dX-cdcu36Oby>_^oh;(a$q}+G8ilM$Ekf3KtZ`UB zV*S)2Vq2DpI5s(Ao7cJ-ZqYierx65mv(0|ySI;#NV! zfd6e20C76g8#l?Wp%J1!a_JKbsqmD$n7b|k1ELEUpCJL`V~WErcaav zzYlJE|DZoV1OH==5{cMWCs-2SWbrYt*%Sc#Xs13?T?YZU3iJfSpU+OD;{F zE#bR_V5_PVFh;ap_@Fi*!?1=^prNgB$(z6&DHU-RKb8uETnSkvz|;tofdLY45c29# zQel9fh&{bZad8Sup%R!HKmjCtFY^njm}{3L6GyBk2=0eQ50H?Re=lTyD;Bg2Xlru% zf~E@QM@Y>3HQM+A63oFu)_1&Czhy{p?SyZrMBo~1^Z>Em5OJ4gwFU$u0QU#LezWoJwgmMNV%3aUdBZ zV0Cu-^qAR>f)gsdq|t*MJK033*LZ^uL1>(U=Ue5b`+`?%JG z*$4pQ8!4A2E$m4EUy%w=_!vhZ!FeF_8xbLI)OvQSUIEG^i3^OQ2@ggh&g=?=!hM{dnA09b7JnQ zWFhOPMhu5&c=EVReA^yd(*Hv$ zMuz2b`QL>?VLvvT{Q;d${|cr9*Vos7O{3AiW-u5dxLj^Ou~^(k)o~D#y(5ezK6kln~{;R`1lLP7$vva%L(I2?_hxEUkBH>;|uCWMEF2W;QI{psAfbLHgh1OP?#oELI3B|rtp zwzjqm4-b!+goK1mnm)cXC_sF&AIHYVZrQbKSJuxz|4aa|_Ok-?A#y4kd^f;6cI?=t zf`S5=NYw3R5IO~io6LZ7=gtMKSh0dZP7*Sfd4l9r6Zm=O&Ye$EQ&VB`xyECIIt5r) zS2qSuP}j>Cv=Q9U$&)9eLx&E<8y!F#S>JJRaCoK-K;?h|R?}X}fu+0O0hZV{bKkg{ zFzCpUBX`u9D@e}uBj@=+lZU^-Os<6s7mAlHTgF(mY87Mc+O>>z>((*s?Ccoe8Wt~J z%!0HArqd};nS;-ha|+eDNjUA9YLoyYA|n3V5kPVo7Qlj^A*cK0mtRV~yu9vRx^&6+ z;lqdP^78WLR99DzZEkM<9Q#ufn4lyQiA-?fYy$Iccs!m7&h-X1G&GDUD=Ra_Ipngt zckeo%K7BfL|Ni}{Yu2o(pEG9;0pHVEq;H#4$s@H{5Val?T>oYHEsb zrf{me$JED(zYbGxu@!96=Sp%l^cJ?xabaO$NAvUZXBacU7g`2Cfu1gdeKAB)95_BV zG=LrnkWQz6zGKIZ0$7F+6&1BtB9ZhmG>9Gp5J$qd4jed;GG)pXMOp(n+UCuhi|*gQ z?}YQbkMwX3Fqw$5!ex2~$Y!%maL-($PRDT~IZbAY_yk zq0l=(xm^C%;lqa$zydoPA(=aOE`fUz>DVf_FqzB|RDCx?So8h$Lgy^0T>MUt1*o_X z2IDjA14|*f?x?Q{e+~xRg05V-l5zCt(HohWnYQ@zYWYjPggGLi`qarIDN|%_3FDAQ z(gak?&b93E07*e#88_)fSQJPu3sW@+3a@r{c1$A=7WZv`T&|e@XQzq%2ZwUy z<@nD*oQa$FbPRHu6`D0?8d|z#651a=4dJG$uriOt34Z|xYWxH`#pr_E9evDTM4FZP3 zGI4^8f!C$fob{`0$g>JPcj4Ho6?RQz;AtPh!4h3vU6T+6a|8_vP9_)k&!qB|SUqPZv~uhg1wrLAm(E#Kd0! zB>AkEe1@EtmuKGN05XNOqoJv~VJlJx9QZ-7How#vf;+`7(G`r;B~rQQxvrZkL6wlm z$jCj*moH~PzxzM``2vN9UvcPB0I{E2iMv>A0HThyLGl~=WKBtCUHEToQR9E8I0puU z@uju(Z2CX{`7h++^4rNC1F*CualLo)PhAEF(zp4gT8bk|4&JF|WzWL_hO)6c+?@aA z>FIfV;J`tW_uuaYLuC+1jDNKzM@0MbSo&;EXYimYgD-^CCAB8hn|ClsouT&;2w!ZrBEm|ZXejlE1m-Bh)=Qw z%4>`~PUW!)0==D*l45OdZ+{Pb+H6RzH_ua2b}}Vr`_A=lVX8x z7rLONs&kD@VVzb!2gKoU23@&wWi!s_o|u??ggWza9jR~MerUjefyA|I*Y;C!eL4q- zyId!(J#|JgrM@V#*aN>Fl~yw!A4G`wm!`+6sHhn2?(TkK?AY&`p$US(kEsI=1fX#b zgc}_ly^^Zy(>1_XQ=Xkq1aS9CycLQn@xmb8QC8jc46e9Y<)$eFLHrY%+WPeyB8Lqd zu4tyJ{9Aj$`yqv~v00Q}US9q^mDi|KfY6IbtUCKFs@U@nfTSWY#Mm-FX$d_c2FZ9VLL&f{{?Yr36*r>B< zbUFoybHKM!pIv;a+=SaJw%iBBRr{jQN4wD`rxh(DzZ|7VL%`W<0*wR*pB+4S2+a73 zDlRS_tIO-tIY3YiD|dfHk=t|NVlcP|&-_r>qy5O%(FzS6J_Pl8zmHmJNM{y@!4Zy* zo1^pd^C_u^U=#qcAACQv_F5hZF}m~!dWgYY%{Ykcw#`<6>)op#hM-w9CG$D(al?m? z5O3eU<6>c9;dp(4(;GmLNXq>@sXC-QrULuDVlTAQV>$ZlixJ%h*RS6Pil+L-7bDp) zrdL^6IY!^$^a@a6iAXf!Lack^1dDG`pWgkk^=KAR72x`QfIr(0eKTgHIKV%^znRuT z`2uQV1^D+F0B8aYdK!KEVBpy5zMnV>?e<-XZs&T)pSIjhp$jUO$O*Z| zdw}#PfH045^X6afKq9M2fPmBmEENF$G~;{Z8f=dui@X$pC%Wv2A{mdw`DIG=`HEV0 z-ZrUROzDgRqX5X`@jqO)Y*`jKdUbO-1-M?&UmbvEEHFh!uWUgv7}$gAqly63KAJ;{ z1TYgSgBz=uS#A=UaPSKO5XzNo+TjM#?m zSNSO5sROPE>swoP#n#+NZ|=Oi$0S?5gA6r%yk{2#Jl2 zO-5Q;+H>QB0tx%eBHF_<_sjhG&{x(PByQTt)u9zlyfUa6O-aoxodOIA3E2hBva`PG zgbAi~w{PEut!ukn@WPicM;6i^w1U*qA|coS%$)k$kMMCR+hbEF0G*wkFF@o~h6kf6 zAAdYp?&jup5=N9YIUbcD!J@H?5a4Eg03TcH74o_O`1;(r^Kt-~a*&udZF*r=R+d)l zGXP|9bA0gq@&JK0Ai)wL^}*H{hokjyqXNj|@%oP*J%$cRGYEX$o;`am^7;IJRDB2b zkt2&RNU$Vrd?efi81UtYnz}uDLpi|G($X=|Q~}Wq%SZaYHx3!i*&d>w=zgY(=H3>7Dxy%ab*EKmasu% z7eo2Q`1$#}zVptzXw;~$6*EDDgM%+4incmaC4q$X6%ICMW6S&`0P>y&AOYf|%Ah8Z zlsC+v05@!~zXO58(z11R5lpQ;d-m*Qf*`0V?Wu-%;+7wuHr~4(UFt(X4ycJw%xjFg ztH}+g^u%E;u!V(1$=I>q{jq%`xpdXn*Y_6HYcx~|nq+p}jilD7+xc^uKjnp@OO7D6 zs8Q{pLg@+9XtYnpjT_JFXl)xTFW9+rXMSB>9c61Y)YRW-ymC9}iGVeB_JmN`3c;Tm z1Yk~1jyddR2$Q%wT4C9?Au=~1ApzzlQ&zV?9m(X<{*{ajZyacZT{Ua4)U;<8pCCl2 z)#an~B=6t9zXl+wTBZsX>hJG=lf`0DwwzyG@x+X=kLzzHkX^gyl5E_JagT?s?qp9& zPcAYta*aBr?!Yg?`=H1~a&qz-q^BsYq_=C?dAnfLC$a-;j3_=VZxK|h)nBIc#2!6* zWT(mkl|@$Qg~G564GmxG-x^!Sr`Lo(ZcTYw;YFADplkU~sF?n6h28({TlwiVUZ8$>xF?T2&6a7B~G%@^m8C@5dZ%GbmS z+ZUJEym@m;Mn(oqKhtRe?RI*-nwfnty3|)Oj}cZw-74Cr){cjipA7bC>pNQDr>@9d zs9jxM)1~Z9#5Y`z=Zg7IjgE*5v1M$Vk><6z<~ql+H6u!HtTuw=E={T zIdhJ|U{F@)r7NY>oIB>0_=94llz-YxAy-US`Mo+h5eNv7?`d29nB2Imdb~ZkgqD1*<>bvY2tZJFcJ>meSK3t_7QFT`huTpU)ku- zmQ&~3661lK{SI5!|Ku}Rp(HuKFJDN7pxwAk+b_=n!|BADKE>jPIls)85@qv3_ zVO^CMfd4`L28N)f%ejYo0|;tvZXUUB-@f#&seTX|7r6*HsD)l7N?2!gGDLPJ9X$&02EBIzH&=lc8mU&lA>3;0f0ZjoMl$?FLA zcj}ZGQ1*i*^oPa;kQCGagc5d;=TQw2tlQk&0xex+%Z_?@^~jB4r!;lz&-}Gs!+2D| zNbAs=4Gs_ll`Orzy`#uc8Oi`!S}Cf#+3hw*|BW1n+>_L|I%OYtBzcOQE~xHusf0lR zw&{)d_;^Ry+CppJIJ32~+rkwykaMV6YehE|g~__|e`g=t*2)M;ms5xh4et+OfAt?P zFRv)D#P0Y;DDea(@izQ66}df_^he>b?&`3jP-9Sls`EBDxc1hFyK0U&C23UG8p--t zOV(SWy;puh-suw+W%0Cu2fp%X>U1enSU0+-0aS?1W)BSv47>=@w5#NM25zoD&!35Y z@ioU6JyC0``@{MkjYaWQfoG8#555czt1IQ@16b?wW5LKRD}ywy9Vq2D4VD~d3B zYH4+UM&5BKD0@l0P|8+o3ZB6ssS;G^y>{)In~jZ)XsX3jh1D%wIYUt!&^xvJL87zB z3w0f;Sy^gtUT<(f>Z-AxHtOKv|K_YeWQN=xY9Ayzw!R-wTFnI?P0q{UVARy>mF(0d zp?RyTJyU|2vkBeIH-35Fi7aO+`p;dB>VPscGnX4JK%B6C5?k(bwKa{sO}5AH_do{*SEqdixw zQSb2TIC<9Ra#oe=-s)P1 z(rYhzA4#4f(`AGOk%b=5KUr7W#49x;&jI_fp?-dTx4JU|4xib$abu-KB6&ye0J-Ak z&u$d%PUy~a3C)}Acm==*mHrpRvJUrMdi}wJ2U}r#UQMRqfz?`DTN4!(6+h|~U=2HG z-l?objp{y1)JE_fftm9er7ekTRi0N(&4e90b`)yTq~X0$QBi*S0{D7P!_9q)-L&)& zD4?hOPCnDL|2wI~4q#E(ZVl4Dm@%T_&SnJS6J;(qS#?tegp=DT+7S{jbrf4OoEWwVm8P!QL+>qnxvss1Bv0D*^`(IL|4p)?Fd?4(LK024PvIZVPQx+)N zlH%VBcBZm~b>A2PEVZTa2XGp3no7S1Q*L1*BMfyBMAs98&)<-E<0-86WX3-GSyZ%gM( z7@r#Y0u2rjc8(6roZq6(JUw#D?x<3?Tiw|MxF<^G8|eJ1AE2wHDu8&j&2xEFb@Dt8 z7H=B*!i)xBX-nb?Rp|>P*I=P(wHG{)9!h>1lT^MTwII zLtlWQ)#X3yIR)k&_b|Rk@l_`-;P<>V(Y9LvpEgA~w)cM!Q0^B07K@wrOBHRq1@K|z zv0&v03^2oT?Tc}8t@c{77hPTb^R;XF+mp%ZxDYS`(r0lPf*PIgSJ{))=|7}$ai7y! zi<`*0Qt(>T9Jj^LCv0r$^dC%N-AJF5sWP&E`+I>?8hXik8S3c&0{{U3|H3J8|NZGu z*n;ieqfY;TH8S09OdU!Xr^K13t6D%62q^V!yk5KSKYb5{9WofF#E#pY>tV}uAAh`v z_xz}ljB!Z(V_SA9`+Dmk)Bmfk6kQmOa~U)Z!0*35Nl!l=^sxh&0&l-PoIKEu9LyN2 z;Hxip?7ENI{abK8@xhML*VYaV^e_bKx`Y8M=>!0c>n#WWdrS~ hp@abd009600|4xg2fprU-gf{1002ovPDHLkV1m~O%u@gW literal 0 HcmV?d00001 diff --git a/mkdocs.yaml b/mkdocs.yaml index 7a3e2de3..15e14255 100644 --- a/mkdocs.yaml +++ b/mkdocs.yaml @@ -19,7 +19,7 @@ nav: - Pages & Forms: ui - Services API: services - File Formats: file-formats - - Beacon+ API & bycon: beaconplus + - Beacon+ API Use: common/beacon-api - Analysis in R - pgxRpi: pgxRpi - Plotting & Visualizations: common/plotting - Use Case Examples: use-cases diff --git a/src/components/classificationTree/SubsetsTree.js b/src/components/classificationTree/SubsetsTree.js index d36bd61a..c373c4e6 100644 --- a/src/components/classificationTree/SubsetsTree.js +++ b/src/components/classificationTree/SubsetsTree.js @@ -182,6 +182,7 @@ function Node({ const isSearchPossible = subset && canSearch(subset) const even = index % 2 === 0 // const detailsPage = subsetId.match("cellosaurus") ? "celllines/cellline" : "subset" + const detailsPage = "subset" return ( ) } function DataVisualizationForm({ isQuerying, onSubmit }) { - const defaultValues = { "plotRegionLabels": null, "plotGeneSymbols": null @@ -259,7 +258,7 @@ function DataVisualizationForm({ isQuerying, onSubmit }) { ) } -function ResultPanel({ formValues, response, width }) { +function ResultPanel({ formValues, response, width, datasetIds }) { const resultsHandovers = response.response.resultSets[0].resultsHandovers const handoverById = (givenId) => @@ -272,8 +271,8 @@ function ResultPanel({ formValues, response, width }) { } }); - const histoplotUrl = handoverById(HANDOVER_IDS.histoplot).url + "&plotPars=" + mapped.join('::') - const samplesplotUrl = handoverById(HANDOVER_IDS.samplesplot).url + "&plotPars=" + mapped.join('::') + const histoplotUrl = handoverById(HANDOVER_IDS.histoplot).url + "&plotPars=" + mapped.join('::') + "&datasetIds=" + datasetIds + const samplesplotUrl = handoverById(HANDOVER_IDS.samplesplot).url + "&plotPars=" + mapped.join('::') + "&datasetIds=" + datasetIds return (
@@ -303,7 +302,7 @@ function ResultPanel({ formValues, response, width }) { // // { value: "NCITgrade", label: "NCIT Disease Grade" }, // // { value: "NCITstage", label: "NCIT Disease Stage" }, // // { value: "EFOfus", label: "followup status" }, -// { value: "PMID", label: "Publication (PubMed ID)" }, +// { value: "pubmed", label: "Publication (PubMed ID)" }, // // { value: "geo:GSE", label: "GEO Series ID" }, // // { value: "geo:GPL", label: "GEO Platform ID" }, // {