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.

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.

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.

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/1073868where 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

Re: 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?

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.

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.

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.

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?

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.

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.

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.

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

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

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.

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

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.

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.

Re: S&P URIs: we need your input!!

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.

Re: S&P URIs: we need your input!!

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.

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

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