Closed deepakunni3 closed 6 years ago
@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/{category}
https://api.monarchinitiative.org/api/bioentityset/slimmer/function
https://api.monarchinitiative.org/api/bioentityset/slimmer/phenotype
The mods requested that we enumerate the category, which seemed reasonable.
Nathan
On Aug 28, 2018, at 1:20 PM, Suzanna Lewis notifications@github.com 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.
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.
~~~@cmungall What would you recommend?~~~~
Please disregard this.