InterMine Community Call - Thursday, 19 April
Locked
InterMine Community Call - Thursday, 19 April
 
|
Hello all,
We have a call tomorrow, here's the agenda and call in information: https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit We'll be talking about our FAIR project, and unique URIs for InterMine. We'd like your input! Cheers Julie TIMES: 09:00 PDT 11:00 CDT 12:00 EDT 17:00 BST _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
S&P URIs: we need your input!!
|
|
Hi all!
I have transferred the content of the FAIR presentation in a google doc: https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing to facilitate an open discussion :) We really need your tech input and experience in different scenarios. Please add your comments and suggestions!! Thanks! Daniela > Hello all, > > We have a call tomorrow, here's the agenda and call in information: > > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit > > We'll be talking about our FAIR project, and unique URIs for > InterMine. We'd like your input! > > Cheers > Julie > > TIMES: > 09:00 PDT > 11:00 CDT > 12:00 EDT > 17:00 BST > _______________________________________________ > dev mailing list > [hidden email] > https://lists.intermine.org/mailman/listinfo/dev _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
Just to give some extra context, this is about the presentation [1] given in yesterday's call about our thinking for implement FAIR stable and persistent URIs
in InterMine, which is the bedrock for a lot of other FAIR stuff. The presentation itself has a little bit more background, though otherwise it is the same content as in the doc. Essentially, we're debating two major different approaches and got some very useful feedback on yesterday's call from people operating mines as to which is better. But we want to make sure we get as much input as possible. So if you get time, please read and comment on the doc or on this list. In any case, this is complex, ongoing work and we'll be regularly consulting everyone as planning and then implementation moves forward. [1] https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc -- Justin Clark-Casey, http://justincc.org Research Software Engineer, InterMine, Cambridge ELIXIR-UK technical coordinator On 20/04/18 08:58, [hidden email] wrote: > Hi all! > > I have transferred the content of the FAIR presentation in a google doc: > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing to facilitate an open discussion :) > We really need your tech input and experience in different scenarios. > Please add your comments and suggestions!! > > Thanks! > Daniela > >> Hello all, >> >> We have a call tomorrow, here's the agenda and call in information: >> >> https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit >> >> We'll be talking about our FAIR project, and unique URIs for >> InterMine. We'd like your input! >> >> Cheers >> Julie >> >> TIMES: >> 09:00 PDT >> 11:00 CDT >> 12:00 EDT >> 17:00 BST >> _______________________________________________ >> dev mailing list >> [hidden email] >> https://lists.intermine.org/mailman/listinfo/dev > dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
Justin and Dani, I've been wondering about the implementation details for this, a little bit. What are the stable URIs actually pointing to - a jsp report page? Something else? I'm curious how will it work given that we are in the process of decoupling the UI from the webapp? I don't mean only bluegenes, but any UI that pulls data via the API, including our mobile apps and any of the many scripts / mini-apps we have floating about. Yo On 20 April 2018 at 11:06, Justin Clark-Casey <[hidden email]> wrote: Just to give some extra context, this is about the presentation [1] given in yesterday's call about our thinking for implement FAIR stable and persistent URIs in InterMine, which is the bedrock for a lot of other FAIR stuff. The presentation itself has a little bit more background, though otherwise it is the same content as in the doc. _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
It would be nice to register the BlueGenes UI (if exists) and assign it
to relative InterMine server. If a mine instance is served by the new BlueGenes interface the request flymine.org/gene/FBgn0000606 should be redirected to the corresponding bluegenes instance, for example <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868">http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868 where flymine.org/gene/FBgn0000606 is the Stable and Persistent URI and <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/1073868">http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/1073868 the access URL Dani > Justin and Dani, > > I've been wondering about the implementation details for this, a > little bit. What are the stable URIs actually pointing to - a jsp > report page? Something else? I'm curious how will it work given that > we are in the process of decoupling the UI from the webapp? I don't > mean only bluegenes, but any UI that pulls data via the API, including > our mobile apps and any of the many scripts / mini-apps we have > floating about. > > Yo > > On 20 April 2018 at 11:06, Justin Clark-Casey <[hidden email]> > wrote: > >> Just to give some extra context, this is about the presentation [1] >> given in yesterday's call about our thinking for implement FAIR >> stable and persistent URIs in InterMine, which is the bedrock for a >> lot of other FAIR stuff. The presentation itself has a little bit >> more background, though otherwise it is the same content as in the >> doc. >> >> Essentially, we're debating two major different approaches and got >> some very useful feedback on yesterday's call from people operating >> mines as to which is better. But we want to make sure we get as >> much input as possible. So if you get time, please read and comment >> on the doc or on this list. In any case, this is complex, ongoing >> work and we'll be regularly consulting everyone as planning and then >> implementation moves forward. >> >> [1] >> > https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc >> [1] >> >> -- >> Justin Clark-Casey, http://justincc.org >> Research Software Engineer, InterMine, Cambridge >> ELIXIR-UK technical coordinator >> >> On 20/04/18 08:58, [hidden email] wrote: >> Hi all! >> >> I have transferred the content of the FAIR presentation in a google >> doc: >> > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing >> [2] to facilitate an open discussion :) >> We really need your tech input and experience in different >> scenarios. >> Please add your comments and suggestions!! >> >> Thanks! >> Daniela >> >> Hello all, >> >> We have a call tomorrow, here's the agenda and call in information: >> >> > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit >> [3] >> >> We'll be talking about our FAIR project, and unique URIs for >> InterMine. We'd like your input! >> >> Cheers >> Julie >> >> TIMES: >> 09:00 PDT >> 11:00 CDT >> 12:00 EDT >> 17:00 BST >> _______________________________________________ >> dev mailing list >> [hidden email] >> https://lists.intermine.org/mailman/listinfo/dev [4] > _______________________________________________ > dev mailing list > [hidden email] > https://lists.intermine.org/mailman/listinfo/dev [4] > > > > Links: > ------ > [1] > https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc > [2] > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing > [3] > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit > [4] https://lists.intermine.org/mailman/listinfo/dev _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
In reply to this post by Yo Yehudi-2
Yes, this is a topic we need to discuss. We did some very brief rough thinking to check it probably isn't impossible (which Dani posted on the other fork of
this thread) but we need to do much more. On 20/04/18 11:21, Yo Yehudi wrote: > Justin and Dani, > > I've been wondering about the implementation details for this, a little bit. What are the stable URIs actually pointing to - a jsp report page? Something else? > I'm curious how will it work given that we are in the process of decoupling the UI from the webapp? I don't mean only bluegenes, but any UI that pulls data via > the API, including our mobile apps and any of the many scripts / mini-apps we have floating about. > > Yo > > On 20 April 2018 at 11:06, Justin Clark-Casey <[hidden email] <mailto:[hidden email]>> wrote: > > Just to give some extra context, this is about the presentation [1] given in yesterday's call about our thinking for implement FAIR stable and persistent > URIs in InterMine, which is the bedrock for a lot of other FAIR stuff. The presentation itself has a little bit more background, though otherwise it is the > same content as in the doc. > > Essentially, we're debating two major different approaches and got some very useful feedback on yesterday's call from people operating mines as to which is > better. But we want to make sure we get as much input as possible. So if you get time, please read and comment on the doc or on this list. In any case, > this is complex, ongoing work and we'll be regularly consulting everyone as planning and then implementation moves forward. > > [1] https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc > <https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc> > > -- > Justin Clark-Casey, http://justincc.org > Research Software Engineer, InterMine, Cambridge > ELIXIR-UK technical coordinator > > > On 20/04/18 08:58, [hidden email] <mailto:[hidden email]> wrote: > > Hi all! > > I have transferred the content of the FAIR presentation in a google doc: > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing > <https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing> to facilitate an open discussion :) > We really need your tech input and experience in different scenarios. > Please add your comments and suggestions!! > > Thanks! > Daniela > > Hello all, > > We have a call tomorrow, here's the agenda and call in information: > > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit > <https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit> > > We'll be talking about our FAIR project, and unique URIs for > InterMine. We'd like your input! > > Cheers > Julie > > TIMES: > 09:00 PDT > 11:00 CDT > 12:00 EDT > 17:00 BST > _______________________________________________ > dev mailing list > [hidden email] <mailto:[hidden email]> > https://lists.intermine.org/mailman/listinfo/dev <https://lists.intermine.org/mailman/listinfo/dev> > > > _______________________________________________ > dev mailing list > [hidden email] <mailto:[hidden email]> > https://lists.intermine.org/mailman/listinfo/dev <https://lists.intermine.org/mailman/listinfo/dev> > > dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
In reply to this post by Daniela Butano-2
I like that. We do have user stories that might not involve always getting redirected to BlueGenes though. I am thinking of user pathways where the user is browsing on a non-bluegenes app (e.g. a mobile app, cross intermine search, etc) and ends up clicking one of these URIs - they might not *wish* to be directed out of the application they are using, but instead simply go to the report page as presented by their mobile application or the cross intermine search. Maybe this can be masked entirely by internal application logic, so they never see the URIs and hence are never accidentally redirected to bluegenes when that's not what they're looking for? https://xkcd.com/869/ sort of points out how strict redirects can lose a user's pathway completely. I think what I am trying to say is that a bluegenes registered instance is great but we ought to optionally allow other pathways (maybe just via an optional post param or something) to navigate our data, because BlueGenes is not one UI to rule them all. On 20 April 2018 at 11:42, <[hidden email]> wrote: It would be nice to register the BlueGenes UI (if exists) and assign it to relative InterMine server. _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
As Justin said we need more thinking about this, but, I would say that,
for example, the cross intermine search will not use URIs to link an item displayed in a list, with its relative detail page. In general the URIs will never be used internally by the apps. > I like that. We do have user stories that might not involve always > getting redirected to BlueGenes though. > > I am thinking of user pathways where the user is browsing on a > non-bluegenes app (e.g. a mobile app, cross intermine search, etc) and > ends up clicking one of these URIs - they might not *wish* to be > directed out of the application they are using, but instead simply go > to the report page as presented by their mobile application or the > cross intermine search. Maybe this can be masked entirely by internal > application logic, so they never see the URIs and hence are never > accidentally redirected to bluegenes when that's not what they're > looking for? > > https://xkcd.com/869/ sort of points out how strict redirects can lose > a user's pathway completely. > > I think what I am trying to say is that a bluegenes registered > instance is great but we ought to optionally allow other pathways > (maybe just via an optional post param or something) to navigate our > data, because BlueGenes is not one UI to rule them all. > > On 20 April 2018 at 11:42, <[hidden email]> wrote: > >> It would be nice to register the BlueGenes UI (if exists) and assign >> it to relative InterMine server. >> If a mine instance is served by the new BlueGenes interface the >> request flymine.org/gene/FBgn0000606 [1] should be redirected to the >> corresponding bluegenes instance, for example >> > <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868">http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868 >> [2] >> where flymine.org/gene/FBgn0000606 [1] is the Stable and Persistent >> URI and >> > <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/1073868">http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/1073868 >> [3] the access URL >> >> Dani >> >> Justin and Dani, >> >> I've been wondering about the implementation details for this, a >> little bit. What are the stable URIs actually pointing to - a jsp >> report page? Something else? I'm curious how will it work given that >> we are in the process of decoupling the UI from the webapp? I don't >> mean only bluegenes, but any UI that pulls data via the API, >> including >> our mobile apps and any of the many scripts / mini-apps we have >> floating about. >> >> Yo >> >> On 20 April 2018 at 11:06, Justin Clark-Casey >> <[hidden email]> >> wrote: >> >> Just to give some extra context, this is about the presentation [1] >> given in yesterday's call about our thinking for implement FAIR >> stable and persistent URIs in InterMine, which is the bedrock for a >> lot of other FAIR stuff. The presentation itself has a little bit >> more background, though otherwise it is the same content as in the >> doc. >> >> Essentially, we're debating two major different approaches and got >> some very useful feedback on yesterday's call from people operating >> mines as to which is better. But we want to make sure we get as >> much input as possible. So if you get time, please read and comment >> on the doc or on this list. In any case, this is complex, ongoing >> work and we'll be regularly consulting everyone as planning and then >> implementation moves forward. >> >> [1] >> >> > https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc >> [4] >> [1] >> >> -- >> Justin Clark-Casey, http://justincc.org >> Research Software Engineer, InterMine, Cambridge >> ELIXIR-UK technical coordinator >> >> On 20/04/18 08:58, [hidden email] wrote: >> Hi all! >> >> I have transferred the content of the FAIR presentation in a google >> doc: >> >> > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing >> [5] >> [2] to facilitate an open discussion :) >> We really need your tech input and experience in different >> scenarios. >> Please add your comments and suggestions!! >> >> Thanks! >> Daniela >> >> Hello all, >> >> We have a call tomorrow, here's the agenda and call in information: >> >> > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit >> [6] >> [3] >> >> We'll be talking about our FAIR project, and unique URIs for >> InterMine. We'd like your input! >> >> Cheers >> Julie >> >> TIMES: >> 09:00 PDT >> 11:00 CDT >> 12:00 EDT >> 17:00 BST >> _______________________________________________ >> dev mailing list >> [hidden email] >> https://lists.intermine.org/mailman/listinfo/dev [7] [4] >> _______________________________________________ >> dev mailing list >> [hidden email] >> https://lists.intermine.org/mailman/listinfo/dev [7] [4] >> >> Links: >> ------ >> [1] >> > https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc >> [4] >> [2] >> > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing >> [5] >> [3] >> > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit >> [6] >> [4] https://lists.intermine.org/mailman/listinfo/dev [7] > > > > Links: > ------ > [1] http://flymine.org/gene/FBgn0000606 > [2] > http://bluegenes.apps.intermine.org/#%23/reportpage/flymine/Gene/1073868 > [3] > http://bluegenes.apps.intermine.org/#%23/reportpage/flymine-beta/Gene/1073868 > [4] > https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc > [5] > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing > [6] > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit > [7] https://lists.intermine.org/mailman/listinfo/dev _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
In reply to this post by Yo Yehudi-2
I’m still fuzzy on what exactly is the scope of the problem we’re trying to solve.
Is there a set of use cases you’re working from? There are for sure API-level use cases, in addition to UI-level,
When we talk of persistent, stable URIs, are we talking about pages? entities? Apis?
I wonder about other InterMine objects, like lists and templates, even the mine instances themselves.
Does/should FAIRness include all those objects as well?
Joel
--
Joel E. Richardson, Ph.D.
Sr. Research Scientist
Mouse Genome Informatics
The Jackson Laboratory
600 Main Street
Bar Harbor, Maine 04609
207-288-6435
From: dev <[hidden email]> on behalf of Yo Yehudi <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]> Date: Friday, April 20, 2018 at 6:59 AM To: Daniela Butano <[hidden email]> Cc: InterMine Devs <[hidden email]> Subject: Re: [InterMine Dev] S&P URIs: we need your input!! --- The information in this email, including attachments, may be confidential and is intended solely for the addressee(s). If you believe you received this email by mistake, please notify the sender by return email as soon as possible. _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
In reply to this post by Daniela Butano-2
On 20 April 2018 at 12:49, <[hidden email]> wrote: As Justin said we need more thinking about this, but, I would say that, for example, the cross intermine search will not use URIs to link an item displayed in a list, with its relative detail page. In general the URIs will never be used internally by the apps. I think you are probably right about this - I just wanted to point out that we should avoid thinking of BlueGenes as the only UI portal into InterMine data. I like that. We do have user stories that might not involve always _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
In reply to this post by Joel Richardson-2
Hi Joel,
when we talk about stable and persistent URIs (Uniform Resource Identifier) we talk about any data object that a user may store in InterMine, e.g. the eve gene, the P09089 protein, but not lists or templates. As you know, at the moment, there is no way to map an entity with a stable url; for instance, the url http://www.flymine.org/flymine/report.do?id=1007180, pointing to the eve report page, is not stable at all because the id will change on the next flymine build. Within the FAIR project, we want to implement a mechanism which provides stable and persistent URI to uniquely identify for instance the eve gene object using the URI flymine.org/gene/FBgn0000606 (or whatever schema we will decide is most suitable). When the user will make an HTTP request to flymine.org/gene/FBgn0000606, he will automatically redirected to the flymine report page. If a machine will make the HTTP GET request to flymine.org/gene/FBgn0000606, a different representation of the gene will be returned. Using the same URI flymine.org/gene/FBgn0000606, it will be possible to represent the same object using different representations (via HTTP content negotiation or by URL). Some example: flymine.org/gene/FBgn0000606 flymine.org/gene/FBgn0000606.json flymine.org/gene/FBgn0000606.gff flymine.org/gene/FBgn0000606.rdf The new S&P URI will replace the "portal" links currently provide by InterMine with the 'Share' button. Hope this can clarify a bit Daniela > I’m still fuzzy on what exactly is the scope of the problem we’re > trying to solve. > Is there a set of use cases you’re working from? There are for sure > API-level use cases, in addition to UI-level, > When we talk of persistent, stable URIs, are we talking about pages? > entities? Apis? > > I wonder about other InterMine objects, like lists and templates, even > the mine instances themselves. > Does/should FAIRness include all those objects as well? > > Joel > -- > Joel E. Richardson, Ph.D. > Sr. Research Scientist > Mouse Genome Informatics > The Jackson Laboratory > 600 Main Street > Bar Harbor, Maine 04609 > 207-288-6435 > [hidden email] > > From: dev <[hidden email]> on behalf of Yo Yehudi > <[hidden email]> > Reply-To: "[hidden email]" <[hidden email]> > Date: Friday, April 20, 2018 at 6:59 AM > To: Daniela Butano <[hidden email]> > Cc: InterMine Devs <[hidden email]> > Subject: Re: [InterMine Dev] S&P URIs: we need your input!! > >> I like that. We do have user stories that might not involve always >> getting redirected to BlueGenes though. >> >> I am thinking of user pathways where the user is browsing on a >> non-bluegenes app (e.g. a mobile app, cross intermine search, etc) >> and ends up clicking one of these URIs - they might not *wish* to be >> directed out of the application they are using, but instead simply >> go to the report page as presented by their mobile application or >> the cross intermine search. Maybe this can be masked entirely by >> internal application logic, so they never see the URIs and hence are >> never accidentally redirected to bluegenes when that's not what >> they're looking for? >> >> https://xkcd.com/869/ sort of points out how strict redirects can >> lose a user's pathway completely. >> >> I think what I am trying to say is that a bluegenes registered >> instance is great but we ought to optionally allow other pathways >> (maybe just via an optional post param or something) to navigate our >> data, because BlueGenes is not one UI to rule them all. >> >> On 20 April 2018 at 11:42, <[hidden email]> wrote: >> It would be nice to register the BlueGenes UI (if exists) and >> assign it to relative InterMine server. >> If a mine instance is served by the new BlueGenes interface the >> request flymine.org/gene/FBgn0000606 [1] should be redirected to the >> corresponding bluegenes instance, for example >> > <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868">http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868 >> [2] >> where flymine.org/gene/FBgn0000606 [1] is the Stable and Persistent >> URI and >> > <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/1073868">http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/1073868 >> [3] the access URL >> >> Dani >> >> Justin and Dani, >> >> I've been wondering about the implementation details for this, a >> little bit. What are the stable URIs actually pointing to - a jsp >> report page? Something else? I'm curious how will it work given that >> we are in the process of decoupling the UI from the webapp? I don't >> mean only bluegenes, but any UI that pulls data via the API, >> including >> our mobile apps and any of the many scripts / mini-apps we have >> floating about. >> >> Yo >> >> On 20 April 2018 at 11:06, Justin Clark-Casey >> <[hidden email]> >> wrote: >> >> Just to give some extra context, this is about the presentation [1] >> given in yesterday's call about our thinking for implement FAIR >> stable and persistent URIs in InterMine, which is the bedrock for a >> lot of other FAIR stuff. The presentation itself has a little bit >> more background, though otherwise it is the same content as in the >> doc. >> >> Essentially, we're debating two major different approaches and got >> some very useful feedback on yesterday's call from people operating >> mines as to which is better. But we want to make sure we get as >> much input as possible. So if you get time, please read and comment >> on the doc or on this list. In any case, this is complex, ongoing >> work and we'll be regularly consulting everyone as planning and then >> implementation moves forward. >> >> [1] >> >> > https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc >> [4] >> [1] >> >> -- >> Justin Clark-Casey, http://justincc.org [5] >> Research Software Engineer, InterMine, Cambridge >> ELIXIR-UK technical coordinator >> >> On 20/04/18 08:58, [hidden email] wrote: >> Hi all! >> >> I have transferred the content of the FAIR presentation in a google >> doc: >> >> > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing >> [6] >> [2] to facilitate an open discussion :) >> We really need your tech input and experience in different >> scenarios. >> Please add your comments and suggestions!! >> >> Thanks! >> Daniela >> >> Hello all, >> >> We have a call tomorrow, here's the agenda and call in information: >> >> > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit >> [7] >> [3] >> >> We'll be talking about our FAIR project, and unique URIs for >> InterMine. We'd like your input! >> >> Cheers >> Julie >> >> TIMES: >> 09:00 PDT >> 11:00 CDT >> 12:00 EDT >> 17:00 BST >> _______________________________________________ >> dev mailing list >> [hidden email] >> https://lists.intermine.org/mailman/listinfo/dev [8] [4] >> _______________________________________________ >> dev mailing list >> [hidden email] >> https://lists.intermine.org/mailman/listinfo/dev [8] [4] >> >> Links: >> ------ >> [1] >> > https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc >> [4] >> [2] >> > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing >> [6] >> [3] >> > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit >> [7] >> [4] https://lists.intermine.org/mailman/listinfo/dev [8] > > --- > > The information in this email, including attachments, may be > confidential and is intended solely for the addressee(s). If you > believe you received this email by mistake, please notify the sender > by return email as soon as possible. > > Links: > ------ > [1] http://flymine.org/gene/FBgn0000606 > [2] > http://bluegenes.apps.intermine.org/#%23/reportpage/flymine/Gene/1073868 > [3] > http://bluegenes.apps.intermine.org/#%23/reportpage/flymine-beta/Gene/1073868 > [4] > https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8NYCc > [5] http://justincc.org > [6] > https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs0u6TJc/edit?usp=sharing > [7] > https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGKH5KKgM/edit > [8] https://lists.intermine.org/mailman/listinfo/dev _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
Thanks Daniella, I definitely understand the issue with this: http://www.flymine.org/flymine/report.do?id=1007180 Also, I do appreciate that the existing Share links require a Class parameter, which is not ideal. Adopting more RESTful url patterns is a good thing, as the examples you show demonstrate. But of course, providing RESTful endpoints is different thing than ³minting² stable, persistent IDs (to go into the stable, persistent URIs). As discussed on the call, this goal is very problematic and opens whole cases of worms. In short, I think supporting RESTful endpoint URLs is definitely worthwhile, but I don¹t think it makes InterMine fundamentally more FAIR than it already is using the Share links. Joel -- Joel E. Richardson, Ph.D. Sr. Research Scientist Mouse Genome Informatics The Jackson Laboratory 600 Main Street Bar Harbor, Maine 04609 207-288-6435 [hidden email] On 4/23/18, 10:06 AM, "[hidden email]" <[hidden email]> wrote: >Hi Joel, > >when we talk about stable and persistent URIs (Uniform Resource >Identifier) we talk about any data object that a user may store in >InterMine, e.g. the eve gene, the P09089 protein, but not lists or >templates. >As you know, at the moment, there is no way to map an entity with a >stable url; for instance, the url >http://www.flymine.org/flymine/report.do?id=1007180, pointing to the eve >report page, is not stable at all because the id will change on the next >flymine build. > >Within the FAIR project, we want to implement a mechanism which provides >stable and persistent URI to uniquely identify for instance the eve gene >object using the URI flymine.org/gene/FBgn0000606 (or whatever schema we >will decide is most suitable). >When the user will make an HTTP request to flymine.org/gene/FBgn0000606, >he will automatically redirected to the flymine report page. >If a machine will make the HTTP GET request to >flymine.org/gene/FBgn0000606, a different representation of the gene >will be returned. >Using the same URI flymine.org/gene/FBgn0000606, it will be possible to >represent the same object using different representations (via HTTP >content negotiation or by URL). Some example: >flymine.org/gene/FBgn0000606 >flymine.org/gene/FBgn0000606.json >flymine.org/gene/FBgn0000606.gff >flymine.org/gene/FBgn0000606.rdf > >The new S&P URI will replace the "portal" links currently provide by >InterMine with the 'Share' button. > >Hope this can clarify a bit >Daniela > > >> I¹m still fuzzy on what exactly is the scope of the problem we¹re >> trying to solve. >> Is there a set of use cases you¹re working from? There are for sure >> API-level use cases, in addition to UI-level, >> When we talk of persistent, stable URIs, are we talking about pages? >> entities? Apis? >> >> I wonder about other InterMine objects, like lists and templates, even >> the mine instances themselves. >> Does/should FAIRness include all those objects as well? >> >> Joel >> -- >> Joel E. Richardson, Ph.D. >> Sr. Research Scientist >> Mouse Genome Informatics >> The Jackson Laboratory >> 600 Main Street >> Bar Harbor, Maine 04609 >> 207-288-6435 >> [hidden email] >> >> From: dev <[hidden email]> on behalf of Yo Yehudi >> <[hidden email]> >> Reply-To: "[hidden email]" <[hidden email]> >> Date: Friday, April 20, 2018 at 6:59 AM >> To: Daniela Butano <[hidden email]> >> Cc: InterMine Devs <[hidden email]> >> Subject: Re: [InterMine Dev] S&P URIs: we need your input!! >> >>> I like that. We do have user stories that might not involve always >>> getting redirected to BlueGenes though. >>> >>> I am thinking of user pathways where the user is browsing on a >>> non-bluegenes app (e.g. a mobile app, cross intermine search, etc) >>> and ends up clicking one of these URIs - they might not *wish* to be >>> directed out of the application they are using, but instead simply >>> go to the report page as presented by their mobile application or >>> the cross intermine search. Maybe this can be masked entirely by >>> internal application logic, so they never see the URIs and hence are >>> never accidentally redirected to bluegenes when that's not what >>> they're looking for? >>> >>> https://xkcd.com/869/ sort of points out how strict redirects can >>> lose a user's pathway completely. >>> >>> I think what I am trying to say is that a bluegenes registered >>> instance is great but we ought to optionally allow other pathways >>> (maybe just via an optional post param or something) to navigate our >>> data, because BlueGenes is not one UI to rule them all. >>> >>> On 20 April 2018 at 11:42, <[hidden email]> wrote: >>> It would be nice to register the BlueGenes UI (if exists) and >>> assign it to relative InterMine server. >>> If a mine instance is served by the new BlueGenes interface the >>> request flymine.org/gene/FBgn0000606 [1] should be redirected to the >>> corresponding bluegenes instance, for example >>> >> <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868">http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868 >>> [2] >>> where flymine.org/gene/FBgn0000606 [1] is the Stable and Persistent >>> URI and >>> >> >><a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/10738">http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/10738 >>68 >>> [3] the access URL >>> >>> Dani >>> >>> Justin and Dani, >>> >>> I've been wondering about the implementation details for this, a >>> little bit. What are the stable URIs actually pointing to - a jsp >>> report page? Something else? I'm curious how will it work given that >>> we are in the process of decoupling the UI from the webapp? I don't >>> mean only bluegenes, but any UI that pulls data via the API, >>> including >>> our mobile apps and any of the many scripts / mini-apps we have >>> floating about. >>> >>> Yo >>> >>> On 20 April 2018 at 11:06, Justin Clark-Casey >>> <[hidden email]> >>> wrote: >>> >>> Just to give some extra context, this is about the presentation [1] >>> given in yesterday's call about our thinking for implement FAIR >>> stable and persistent URIs in InterMine, which is the bedrock for a >>> lot of other FAIR stuff. The presentation itself has a little bit >>> more background, though otherwise it is the same content as in the >>> doc. >>> >>> Essentially, we're debating two major different approaches and got >>> some very useful feedback on yesterday's call from people operating >>> mines as to which is better. But we want to make sure we get as >>> much input as possible. So if you get time, please read and comment >>> on the doc or on this list. In any case, this is complex, ongoing >>> work and we'll be regularly consulting everyone as planning and then >>> implementation moves forward. >>> >>> [1] >>> >>> >> >>https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8 >>NYCc >>> [4] >>> [1] >>> >>> -- >>> Justin Clark-Casey, http://justincc.org [5] >>> Research Software Engineer, InterMine, Cambridge >>> ELIXIR-UK technical coordinator >>> >>> On 20/04/18 08:58, [hidden email] wrote: >>> Hi all! >>> >>> I have transferred the content of the FAIR presentation in a google >>> doc: >>> >>> >> >>https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs >>0u6TJc/edit?usp=sharing >>> [6] >>> [2] to facilitate an open discussion :) >>> We really need your tech input and experience in different >>> scenarios. >>> Please add your comments and suggestions!! >>> >>> Thanks! >>> Daniela >>> >>> Hello all, >>> >>> We have a call tomorrow, here's the agenda and call in information: >>> >>> >> >>https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGK >>H5KKgM/edit >>> [7] >>> [3] >>> >>> We'll be talking about our FAIR project, and unique URIs for >>> InterMine. We'd like your input! >>> >>> Cheers >>> Julie >>> >>> TIMES: >>> 09:00 PDT >>> 11:00 CDT >>> 12:00 EDT >>> 17:00 BST >>> _______________________________________________ >>> dev mailing list >>> [hidden email] >>> https://lists.intermine.org/mailman/listinfo/dev [8] [4] >>> _______________________________________________ >>> dev mailing list >>> [hidden email] >>> https://lists.intermine.org/mailman/listinfo/dev [8] [4] >>> >>> Links: >>> ------ >>> [1] >>> >> >>https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8 >>NYCc >>> [4] >>> [2] >>> >> >>https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs >>0u6TJc/edit?usp=sharing >>> [6] >>> [3] >>> >> >>https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGK >>H5KKgM/edit >>> [7] >>> [4] https://lists.intermine.org/mailman/listinfo/dev [8] >> >> --- >> >> The information in this email, including attachments, may be >> confidential and is intended solely for the addressee(s). If you >> believe you received this email by mistake, please notify the sender >> by return email as soon as possible. >> >> Links: >> ------ >> [1] http://flymine.org/gene/FBgn0000606 >> [2] >> http://bluegenes.apps.intermine.org/#%23/reportpage/flymine/Gene/1073868 >> [3] >> >>http://bluegenes.apps.intermine.org/#%23/reportpage/flymine-beta/Gene/107 >>3868 >> [4] >> >>https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8 >>NYCc >> [5] http://justincc.org >> [6] >> >>https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs >>0u6TJc/edit?usp=sharing >> [7] >> >>https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGK >>H5KKgM/edit >> [8] https://lists.intermine.org/mailman/listinfo/dev > --- The information in this email, including attachments, may be confidential and is intended solely for the addressee(s). If you believe you received this email by mistake, please notify the sender by return email as soon as possible. _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
Re: S&P URIs: we need your input!!
|
|
Yes, I think we'll proceed on the basis of using external IDs, as I
think we've moved pretty firmly against minting IDs. I think there are going to be a lot of hidden complexities here. Even genes and proteins vary a lot by biological domain, finding unique IDs may be a very messy process. Not to mention other biological entities and making mechanisms generic enough that people can use other data models or put any completely non-biological data into InterMine and still get FAIR URIs. This is also the initial building block of a lot of other stuff, such as more extensive semantics where the data model itself will be labelled with ontology terms that define genes and all their properties, for instance. Of course, this will also be a point of extensive consultation with you all, if you are willing to donate the time :) I think we will try and keep this initial document living and change it to reflect the decisions we make, so that we can all have a good reference point for the evolving design. On 2018-04-23 15:41, Joel Richardson wrote: > Thanks Daniella, > > I definitely understand the issue with this: > http://www.flymine.org/flymine/report.do?id=1007180 > > > Also, I do appreciate that the existing Share links require a Class > parameter, which is not ideal. > Adopting more RESTful url patterns is a good thing, as the examples you > show demonstrate. > > But of course, providing RESTful endpoints is different thing than > ³minting² stable, persistent IDs (to go into the stable, persistent > URIs). > As discussed on the call, this goal is very problematic and opens whole > cases of worms. > > In short, I think supporting RESTful endpoint URLs is definitely > worthwhile, but I don¹t think it makes InterMine fundamentally more > FAIR > than it already is using the Share links. > > Joel > > -- > Joel E. Richardson, Ph.D. > Sr. Research Scientist > Mouse Genome Informatics > The Jackson Laboratory > 600 Main Street > Bar Harbor, Maine 04609 > 207-288-6435 > [hidden email] > > > > > > On 4/23/18, 10:06 AM, "[hidden email]" <[hidden email]> > wrote: > >> Hi Joel, >> >> when we talk about stable and persistent URIs (Uniform Resource >> Identifier) we talk about any data object that a user may store in >> InterMine, e.g. the eve gene, the P09089 protein, but not lists or >> templates. >> As you know, at the moment, there is no way to map an entity with a >> stable url; for instance, the url >> http://www.flymine.org/flymine/report.do?id=1007180, pointing to the >> eve >> report page, is not stable at all because the id will change on the >> next >> flymine build. >> >> Within the FAIR project, we want to implement a mechanism which >> provides >> stable and persistent URI to uniquely identify for instance the eve >> gene >> object using the URI flymine.org/gene/FBgn0000606 (or whatever schema >> we >> will decide is most suitable). >> When the user will make an HTTP request to >> flymine.org/gene/FBgn0000606, >> he will automatically redirected to the flymine report page. >> If a machine will make the HTTP GET request to >> flymine.org/gene/FBgn0000606, a different representation of the gene >> will be returned. >> Using the same URI flymine.org/gene/FBgn0000606, it will be possible >> to >> represent the same object using different representations (via HTTP >> content negotiation or by URL). Some example: >> flymine.org/gene/FBgn0000606 >> flymine.org/gene/FBgn0000606.json >> flymine.org/gene/FBgn0000606.gff >> flymine.org/gene/FBgn0000606.rdf >> >> The new S&P URI will replace the "portal" links currently provide by >> InterMine with the 'Share' button. >> >> Hope this can clarify a bit >> Daniela >> >> >>> I¹m still fuzzy on what exactly is the scope of the problem we¹re >>> trying to solve. >>> Is there a set of use cases you¹re working from? There are for sure >>> API-level use cases, in addition to UI-level, >>> When we talk of persistent, stable URIs, are we talking about pages? >>> entities? Apis? >>> >>> I wonder about other InterMine objects, like lists and templates, >>> even >>> the mine instances themselves. >>> Does/should FAIRness include all those objects as well? >>> >>> Joel >>> -- >>> Joel E. Richardson, Ph.D. >>> Sr. Research Scientist >>> Mouse Genome Informatics >>> The Jackson Laboratory >>> 600 Main Street >>> Bar Harbor, Maine 04609 >>> 207-288-6435 >>> [hidden email] >>> >>> From: dev <[hidden email]> on behalf of Yo Yehudi >>> <[hidden email]> >>> Reply-To: "[hidden email]" <[hidden email]> >>> Date: Friday, April 20, 2018 at 6:59 AM >>> To: Daniela Butano <[hidden email]> >>> Cc: InterMine Devs <[hidden email]> >>> Subject: Re: [InterMine Dev] S&P URIs: we need your input!! >>> >>>> I like that. We do have user stories that might not involve always >>>> getting redirected to BlueGenes though. >>>> >>>> I am thinking of user pathways where the user is browsing on a >>>> non-bluegenes app (e.g. a mobile app, cross intermine search, etc) >>>> and ends up clicking one of these URIs - they might not *wish* to be >>>> directed out of the application they are using, but instead simply >>>> go to the report page as presented by their mobile application or >>>> the cross intermine search. Maybe this can be masked entirely by >>>> internal application logic, so they never see the URIs and hence are >>>> never accidentally redirected to bluegenes when that's not what >>>> they're looking for? >>>> >>>> https://xkcd.com/869/ sort of points out how strict redirects can >>>> lose a user's pathway completely. >>>> >>>> I think what I am trying to say is that a bluegenes registered >>>> instance is great but we ought to optionally allow other pathways >>>> (maybe just via an optional post param or something) to navigate our >>>> data, because BlueGenes is not one UI to rule them all. >>>> >>>> On 20 April 2018 at 11:42, <[hidden email]> wrote: >>>> It would be nice to register the BlueGenes UI (if exists) and >>>> assign it to relative InterMine server. >>>> If a mine instance is served by the new BlueGenes interface the >>>> request flymine.org/gene/FBgn0000606 [1] should be redirected to the >>>> corresponding bluegenes instance, for example >>>> >>> <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868">http://bluegenes.apps.intermine.org/##/reportpage/flymine/Gene/1073868 >>>> [2] >>>> where flymine.org/gene/FBgn0000606 [1] is the Stable and Persistent >>>> URI and >>>> >>> >>> <a href="http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/10738">http://bluegenes.apps.intermine.org/##/reportpage/flymine-beta/Gene/10738 >>> 68 >>>> [3] the access URL >>>> >>>> Dani >>>> >>>> Justin and Dani, >>>> >>>> I've been wondering about the implementation details for this, a >>>> little bit. What are the stable URIs actually pointing to - a jsp >>>> report page? Something else? I'm curious how will it work given that >>>> we are in the process of decoupling the UI from the webapp? I don't >>>> mean only bluegenes, but any UI that pulls data via the API, >>>> including >>>> our mobile apps and any of the many scripts / mini-apps we have >>>> floating about. >>>> >>>> Yo >>>> >>>> On 20 April 2018 at 11:06, Justin Clark-Casey >>>> <[hidden email]> >>>> wrote: >>>> >>>> Just to give some extra context, this is about the presentation [1] >>>> given in yesterday's call about our thinking for implement FAIR >>>> stable and persistent URIs in InterMine, which is the bedrock for a >>>> lot of other FAIR stuff. The presentation itself has a little bit >>>> more background, though otherwise it is the same content as in the >>>> doc. >>>> >>>> Essentially, we're debating two major different approaches and got >>>> some very useful feedback on yesterday's call from people operating >>>> mines as to which is better. But we want to make sure we get as >>>> much input as possible. So if you get time, please read and comment >>>> on the doc or on this list. In any case, this is complex, ongoing >>>> work and we'll be regularly consulting everyone as planning and then >>>> implementation moves forward. >>>> >>>> [1] >>>> >>>> >>> >>> https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8 >>> NYCc >>>> [4] >>>> [1] >>>> >>>> -- >>>> Justin Clark-Casey, http://justincc.org [5] >>>> Research Software Engineer, InterMine, Cambridge >>>> ELIXIR-UK technical coordinator >>>> >>>> On 20/04/18 08:58, [hidden email] wrote: >>>> Hi all! >>>> >>>> I have transferred the content of the FAIR presentation in a google >>>> doc: >>>> >>>> >>> >>> https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs >>> 0u6TJc/edit?usp=sharing >>>> [6] >>>> [2] to facilitate an open discussion :) >>>> We really need your tech input and experience in different >>>> scenarios. >>>> Please add your comments and suggestions!! >>>> >>>> Thanks! >>>> Daniela >>>> >>>> Hello all, >>>> >>>> We have a call tomorrow, here's the agenda and call in information: >>>> >>>> >>> >>> https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGK >>> H5KKgM/edit >>>> [7] >>>> [3] >>>> >>>> We'll be talking about our FAIR project, and unique URIs for >>>> InterMine. We'd like your input! >>>> >>>> Cheers >>>> Julie >>>> >>>> TIMES: >>>> 09:00 PDT >>>> 11:00 CDT >>>> 12:00 EDT >>>> 17:00 BST >>>> _______________________________________________ >>>> dev mailing list >>>> [hidden email] >>>> https://lists.intermine.org/mailman/listinfo/dev [8] [4] >>>> _______________________________________________ >>>> dev mailing list >>>> [hidden email] >>>> https://lists.intermine.org/mailman/listinfo/dev [8] [4] >>>> >>>> Links: >>>> ------ >>>> [1] >>>> >>> >>> https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8 >>> NYCc >>>> [4] >>>> [2] >>>> >>> >>> https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs >>> 0u6TJc/edit?usp=sharing >>>> [6] >>>> [3] >>>> >>> >>> https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGK >>> H5KKgM/edit >>>> [7] >>>> [4] https://lists.intermine.org/mailman/listinfo/dev [8] >>> >>> --- >>> >>> The information in this email, including attachments, may be >>> confidential and is intended solely for the addressee(s). If you >>> believe you received this email by mistake, please notify the sender >>> by return email as soon as possible. >>> >>> Links: >>> ------ >>> [1] http://flymine.org/gene/FBgn0000606 >>> [2] >>> http://bluegenes.apps.intermine.org/#%23/reportpage/flymine/Gene/1073868 >>> [3] >>> >>> http://bluegenes.apps.intermine.org/#%23/reportpage/flymine-beta/Gene/107 >>> 3868 >>> [4] >>> >>> https://drive.google.com/open?id=1KD_na_vvBzVHpikMkB0Q7A-00GNDpcp0ps7vqi8 >>> NYCc >>> [5] http://justincc.org >>> [6] >>> >>> https://docs.google.com/document/d/1qyMVH45FeIqT59qDBP33LmCiFCTEkv_HKM_Fs >>> 0u6TJc/edit?usp=sharing >>> [7] >>> >>> https://docs.google.com/document/d/1msTaMF0bd79hHORwxHAmdTvdUqMAeIUAaDiGK >>> H5KKgM/edit >>> [8] https://lists.intermine.org/mailman/listinfo/dev >> > > --- > > The information in this email, including attachments, may be > confidential and is intended solely for the addressee(s). If you > believe you received this email by mistake, please notify the sender > by return email as soon as possible. > > _______________________________________________ > dev mailing list > [hidden email] > https://lists.intermine.org/mailman/listinfo/dev _______________________________________________ dev mailing list [hidden email] https://lists.intermine.org/mailman/listinfo/dev |
«
Return to InterMine
|
1 view|%1 views
| Free forum by Nabble | Edit this page |