Improvements to EntitySetSlimmer

Use enum to specify available category
Handle multiple subject IDs as input

@nathandunn FYI

Sure, we can add expression as needed to support the AGR use-case (or they can issue a PR)

Actually, I think that having them issue a PR is the better way to go here.

Yes, making a note to add additional categories to the enum when they are supported.

So it's unclear exactly how this changes the URL that is used for the query. Would you spell it out please.

@selewis  I think the URL will be identical.  I think this just enumerates the categories explicitly.

huh?
They already look different.
https://api.monarchinitiative.org/api/bioentityset/slimmer/phenotype?
vs.
https://api.monarchinitiative.org/api/bioentityset/slimmer/function?
vs.
whatever we need for some other ontology...

The API is

https://api.monarchinitiative.org/api/bioentityset/slimmer/ https://api.monarchinitiative.org/api/bioentityset/slimmer/{ https://api.monarchinitiative.org/api/bioentityset/slimmer/phenotypecategory}

The mods requested that we enumerate the category, which seemed reasonable.
Nathan

On Aug 28, 2018, at 1:20 PM, Suzanna Lewis<EMAIL_ADDRESS>wrote:
huh?
They already look different.
https://api.monarchinitiative.org/api/bioentityset/slimmer/phenotype https://api.monarchinitiative.org/api/bioentityset/slimmer/phenotype?
vs.
https://api.monarchinitiative.org/api/bioentityset/slimmer/function https://api.monarchinitiative.org/api/bioentityset/slimmer/function?
vs.
whatever we need for some other ontology...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/biolink/biolink-api/pull/216#issuecomment-416689851, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt2qiK98sYNQeRX1jaWo-l27JW1vrpGks5uVYn4gaJpZM4WOjgD.

Sorry, still isn't clear (and not sure why we'd let the MODs be the deciders, opinions sure).
What would each URLs  be for GO, HPO, and UBERON exactly?

Everything is pretty much the same.   We were just specifying what we were providing AFAIK.
But its a collaborative process and this is something we all agreed on in the API call.

Could you just answer the question please. "Pretty much the same" doesn't give me any information.
What would each URLs  be for GO, HPO, and UBERON exactly?

The URL has not changed at all AFAIK.   They were just specified in the spec.   So the GO slim, HPO slim, uberon slim, etc. should be what you had before and will not have changed AFAIK.  Is this correct @deepakunni3 ?

@selewis @nathandunn The URLs haven't changed at all.
This PR pretty much shows what values are possible for the URL parameter category in the Swagger UI. It does not change the way the endpoint behaves.
@selewis To answer your question, following are the URLs:
GO - https://api.monarchinitiative.org/api/bioentityset/slimmer/function
HPO - https://api.monarchinitiative.org/api/bioentityset/slimmer/phenotype
UBERON - https://api.monarchinitiative.org/api/bioentityset/slimmer/expression (yet to be implemented)

Except there wasn't anything for UBERON, that's the one that was missing. Maybe it's there now, but we've lost some clarity here. If I look at the swagger page I can see "category * string", but nothing about what are the allowed values. And how does this change the URL? before the URL included "function" for GO or "phenotype" for HPO. Is that gone now? Is it now category="xxx" ?
Someone please spell this out - and ah! Deepak just did...

Note that the swagger presentation doesn't list any of these.

Let me know please when expression is ready.

@selewis Since this PR was merged yesterday, the latest changes are accessible at:
https://api-dev.monarchinitiative.org/api

Yes, saw that, but as I said this currently lacks any information on these options.

Oh, I see. Yes, I can describe the category parameter with more information

Thanks, that will help.
@deepakunni3 - also question on "expression", to be comprehensive it would meed to have slim classes from both Uberon and GO cellular component. Could make two calls (one on 'function' and one on 'anatomy') or one call (with 'expression' looking over both ontologies). What do you prefer?

I think one call looking over both ontologies would be ideal

Certainly would be more convenient from the client side.

That being said, perhaps it would be more neat if we have two separate calls from the client. Primarily because one call (function) is being routed to GOlr and the other (anatomy) is being routed to Monarch Solr. I guess its more of separation of concern.
@cmungall What would you recommend?


A question about the calculation of BD-Rate in the paper.

Normal bd-rate calculating tool, such as VCEG-AE07, can only calculate over four bit points. Meanwhile, to the best of my knowledge, the PSNR points of the RD curve of the proposed method should be similar to those of the anchor method when we calculate the bd-rate gain.
However, the RD curves of the paper cover more than four bit points. In addition, PSNR points are so far apart between the proposed method and the anchor one. These make me confused. I hope someone can answer this question.
Thank you. : )

Hi,
We use the Bjontegaard metric calculation function from: https://github.com/Anserw/Bjontegaard_metric/blob/master/bjontegaard_metric.py
Jianqiang


Replace Cabal-managed config loading with FileEmbed

This uses the file-embed package and TemplateHaskell to load custom
configuration during compilation instead of loading it at runtime.

👍  cool stuff


[Feature] Other distances besides Euclidean

The quality of an embedding in PyMDE is judged by the collection of of Euclidean distances between pairs of embedding distances.
Euclidean distance is natural for visualization, since it is the distance that humans use in the real world. It is also closely related to the standardization constraint (which puts an upper bound on the sum of squared Euclidean distances between embedding vectors).
There is nothing in the underlying optimization algorithm or code that requires the distances to be Euclidean, and the code could easily be extended to support other distances.
If this is something that you actively want, please react with a :+1: on this post.

Hi @akshayka
Thanks for asking for feedback. With my datasets, it seems that minkowski with p < 1 is a better choice to deal with the issue of distance concentration. I noticed that PyNNDescent supports several metrics including custom ones.

@ivan-marroquin ,
To clarify, do you want to use a different metric to measure the k-nearest neighbors of original data? Or do you want to use a different metric to measure distances in the embedding?
I'm guessing the former, because you mentioned PyNNDescent. But just thought I'd double check.

Hi @akshayka
Correct, I believe that it will be beneficial to use PyNNDescent to measure the -k-nearest neighbors, so then PyMDE can be used to compute a lower dimension while preserving neighbors.
Ivan

Can you please provide the Tanimoto distance (often used to compare molecular fingerprints) and Gower's distance (for mixed data records like patient data) as additional metrics in PyMDE?
Thanks,
Torsten

Can one use a precomputed distance matrix?


Choose a site generator for the blog

Original issue by @axelsimon:
Building the enarx.github.io landing page requires us to choose which tool we want to use to power the page / site.
@shaunix was telling me Jekyll is used in OSPO but only as a default, not a mandate.
I've also heard good things about Pelican (which I've played with a bit) and Hugo.
These are the choices that come to mind, any advice is welcome.
I'd like to settle on one of them quickly so we can then build a minimal but useful site.
Acceptance criteria: We have agreed on a site generator.

Comment by Shaun McCance:
Looking deeper, it looks like if you want to use GitHub Pages to publish and host, then you're using Jekyll. For now, we can just create a single static index.html with whatever CSS it needs embedded. We can deal with templating and stuff as we develop a content strategy for what the site needs later.

I've done some research on this fairly recently myself for my own Github Pages-hosted website.
If major organizational support is a priority, Jekyll is a very strong candidate: it's developed by Github themselves, and it's the default first-party supported solution for GH Pages. Integration is very tight, and unless you need to do something complex with style (think React components), it should do what you need it to very well.
I'm personally experimenting with eleventy, but it's still a one-person project and isn't quite feature-complete yet.

You might want to try Hugo over Netlify. You don't necessarily need both, but together they worked for me.

Netlify: deployments are far more easy to debug than Github pages, plus it's infinitely more customizable.
Hugo: you're not bound to Ruby (sorry, I don't know Ruby myself).


included methods to enable mouse events for windows and unix

Getting mouse events to be enabled and disabled in crossterm_input. This is to support Input Expansion: https://github.com/TimonPost/crossterm/issues/81
Next steps/branch:

translate windows inputs into csi / vt sequences
update windows_input read_async to send the translated vt_sequences into the channel
add a parse_event method to handle the vt sequences from AsyncReader

replacing this with combined (legacy) windows-api input handling for mouse and adv keyboard events


How to rebind paginated report .rdl to a different model?

How to rebind paginated report .rdl to a different model?
I'm trying to use rebind feature and doesn't work... give me an error...
I was looking in the docs, and I think there is an API function, but it's not implemented I think... API request
Can you help me?
Thank you,
Miguel

Hi Miguel, I think so as well not everything is supported at the moment


New Icons - Prisma Folder | TurboRepo

New icon for PrismaJs Folder. Locally tested.

Added New Icon to Preview.

added new icon for turbo.json file, turbo repo, issue #105

Thank you for the opportunity, in the next few I will separate the icons into different PRs.


parent of NEW GO:1990914 integral component of periplasmic side of plasma membrane

I created this term in TG FF yesterday and just noticed that its parent should be
is_a GO:0031237 intrinsic component of periplasmic side of plasma membrane.
Sorry, I missed that. I though the "intrinsic component of ~" didn't exist as the "integral component of ~" didn't exist.
Birgit

related to issues #12196

@dosumis If you can provide feedback, I can do the work.  Does this look ok?  Stanza from TG is this:
[Term]
id: GO:1990914
name: integral component of periplasmic side of plasma membrane
namespace: cellular_component
def: "The component of the plasma membrane consisting of the gene products that penetrate only the periplasmic side of the membrane." [GOC:bhm, IntAct:EBI-11297444, PMID:15919996]
comment: An example of this is hyaA in E. coli (P69739) in PMID:23260654 (inferred from direct assay).
subset: termgenie_unvetted
is_a: GO:0005887 ! integral component of plasma membrane
created_by: bhm
creation_date: 2015-12-09T14:38:57Z

It should have both parents, right?
is_a GO:0005887 integral component of plasma membrane
is_a GO:0031237 intrinsic component of periplasmic side of plasma membrane

We have design patterns for creating these which automatically classifies these terms correctly (and will reclassify them correctly if we add new terms).  Unfortunately these haven't yet made it into Term Genie templates.  Tanya: can you update to add:
intersection_of: 'integral component of membrane'
intersection_of: part_of 'periplasmic side of plasma membrane'

Thanks, David!

Thanks, David.
Done.
[Term]
id: GO:1990914
name: integral component of periplasmic side of plasma membrane
namespace: cellular_component
def: "The component of the plasma membrane consisting of the gene products that penetrate only the periplasmic side of the membrane." [GOC:bhm, IntAct:EBI-11297444, PMID:15919996]
comment: An example of this is hyaA in E. coli (P69739) in PMID:23260654 (inferred from direct assay).
is_a: GO:0005887 ! integral component of plasma membrane
intersection_of: GO:0005887 ! integral component of membrane
intersection_of: part_of GO:0098567 ! periplasmic side of plasma membrane
created_by: bhm
creation_date: 2015-12-09T14:38:57Z


Webpart dont appear in workbench 1.16/1.17

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested

[ ] 💥 Internet Explorer
[X] 💥 Microsoft Edge
[X] 💥 Google Chrome
[X] 💥 FireFox
[ ] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details

browser version
SPFx version 1.17
Node.js version 16.13.0
etc

Describe the bug / error
I have been working on a web part for the last couple of weeks, and everything has been working fine until 10/5/23. The problem I experience is that when I try to run my web part in the workbench, everything looks fine, but the web part doesn't appear. The workbench loads the manifest file on localhost:4321, but nothing loads in the workbench. Sometimes the web part appears, and I can load and run it one time, but then it crashes and disappears.
Steps to reproduce

Scaffold a new or old project and try to run it
Refrech workbeanch after load.
😭😭😭😭😭😭😭😭

Expected behavior
I cannot find the web part, or it appears for a little while and then disappears again.

We did a workaround to get it to work. I packed and shipped the web part, and uploaded it to the app catalog on the site I was using. That made the problem go away.

We did a workaround to get it to work. I packed and shipped the web part, and uploaded it to the app catalog on the site I was using. That made the problem go away.

So, after that you made it appear in workbench, even after a code change and refresh of window? Can't see that solving the issue?

Sorry for the regression.
It has been addressed. Locally served web parts and ACEs should be visible in the workbench toolbox again.
@lobba111  - could you please confirm on your end?

@AJIXuMuK it seems to work again :)

We did a workaround to get it to work. I packed and shipped the web part, and uploaded it to the app catalog on the site I was using. That made the problem go away.

So, after that you made it appear in workbench, even after a code change and refresh of window? Can't see that solving the issue?

yes :) nahh i was just as suprised


Fix missed webtest links on 5.2

See https://ci.openmicroscopy.org/view/Docs/job/OMERO-5.2-latest-docs/22/warnings3Result/
This PR manually rebases the changes from #1551 to the dev_5_2 branch because I started fixing the build and then remembered to check if I rebased the develop PR.

Build is green - https://ci.openmicroscopy.org/view/Docs/job/OMERO-5.2-merge-docs/31/

If you install the omero-webtest app this should be OMERO.webtest app

The link to "figure" repo should also be fixed
in contributing/ci-docs.txt, contributing/ci-release.txt

I haven't deleted the contributing folder on this branch but we only publish those docs from the develop branch. I'll push a commit to fix omero-webtest app now though, thanks.

Thanks @hflynn for clarification


Limit display on the AI Watch and Org Watch homepages to top 300 + ties with the 300th

https://orgwatch.issarice.com/#positions-grouped-by-person currently shows 4711 persons. That's a lot, and we expect it to grow as @sebastiansanchez123 adds more data.
So here's a thought! Limit the default homepage display for persons and organizations to the top 1000 by the sorting key (which for persons is number of organizations and for organizations is the number of person) but also include entries tied with the 100th. So e.g. if the top 900 persons have 3 or more organizations and the next 700 have 2, then show all 900 + 700 = 1600.
For organizations, this would be a non-binding constraint as we have fewer than 1000 organizations, so all of them are being shown right now. For persons, this constraint would already be binding.
Write the code so that the "1000" can be changed to another number easily.
Maybe allow a display=full option similar to what we have on DLW.
@riceissa found https://stackoverflow.com/a/30615764/3422337 that uses a subquery to accomplish the goal in a single MySQL query.

There are only 366 persons with 2 or more orgs, so having the cutoff at 1000 would mean we aren't displaying any fewer people, since the 1000th person has 1 org. (Actually, there are a small number of people with 0 orgs, but it doesn't really affect the length of the page.) So even for people, this would be a "non-binding constraint", which makes this strategy for cutting down on the length of the page kinda useless...
Maybe we can just use a hard cutoff, like "limit 1000"? Or pick a smaller number like 300 (so that we will end up showing the 366 people using your strategy)?

Thanks @riceissa -- how about wee go with a smaller number of 300, while using the strategy originally proposed in this issue?

Sounds good, let me see if I can get the right SQL query

This is now done

https://orgwatch.issarice.com/#positions-grouped-by-person
https://orgwatch.issarice.com/?display=full#positions-grouped-by-person

(it's also working for orgs, but limit is too high so not enforced)

LGTM, thanks @riceissa!


Cannot put equal sign in sign text

Today i found out I cannot put an equal sign in the text of any signs.  Instead I get some weird special escaped text.

Could you make an screenshot at daytime?
I cant see a thing on it.

Here is a day time picture.

Probably something with json formatting / escaping.

thats the UFT8-code for an equal. The one for § is for example is \u00A7 and is needed i.e. if you want colored motd in bukkit because it doesn't accept "§".


Use query_range for log streaming

Hello,
As mentionned by @buixor in the original PR, the tail endpoint is not actually designed to tail logs.
This PR uses the query_range endpoint to get batches of logs and move a sliding window to always get the last batch.

It got a bit more verbose than I hoped for but I guess it's the price.

Added a max_failure_duration configuration option (defaults to 30 seconds) : Before that, if loki crashed/stopped/etc, the datasource wouldn't try to connect back. On the other hand, we cannot afford to retry forever without ever failing. Now it will retry for max_failure_duration and will definitely kill the tomb if it doesn't manage to reconnect by then.
Added "modular" ticker : before it was querying every 100ms no matter what. Now it has a ticker that increases if there are no logs, but reset to the 100ms duration as soon as logs are available. I hope it will be more gentle on loki :)

Please @lperdereau let us know what you think. On our side, testing with those changes is conclusive and we're ready to merge for 1.5.6 !

@buixor after a review this sounds good to me.
Those two things, modular ticker and max_filure_duration are very good addition.