Closed lpalbou closed 3 years ago
Comment 1: I think the examples are wrong here ?
Example 1 : sequence specific DNA binding should be part_of DNA binding transcription factor activity, shouldn't it ?
Example 2: the DNA binding transcription factor should he linked to the downstram activities by 'positively regulates'
Right @vanaukenk @thomaspd ? Thanks, Pascale
Comment 2:
Are we set on using Hsap and Cele etc to describe species ? Again this is a non-standard, non-intuitive representation.
Comment 3:
In the Table describing the relations, you could simplify by removing the 'Description' link and making the relations themselves clickable ?
Comment 4:
'part_of' is a BFO term but is also present in RO - maybe 'occurs' in can also be added to RO, and in this case we may be able to claim we are using a single ontology ?
(that's it for now)
Thanks, Pascale
@vanaukenk @ukemi
Thanks for the feedback.
sequence specific DNA binding should be part_of DNA binding transcription factor activity, shouldn't it ?
I don't think that's right. First, I am not sure we allow an activity (sequence specific DNA binding) to be part of another activity (DNA binding transcription factor activity): go-cam-shapes. The usual pattern is more activity part of BP. Second, the specific binding to DNA indeed triggers the transcription factor activity; without it, there is no transcription, so I do see this as a causal relationship and part_of is not a causal. As a note, my thesis with Dino was on nuclear receptors such as RXR, RAR, VDR, GCR & co..
Are we set on using Hsap and Cele etc to describe species ? Again this is a non-standard, non-intuitive representation.
I would prefer the standard uniprot convention too, I think we discussed it once. But it's a larger issue independent of this page as this comes from noctua graph and our triplestore (and probably affects quite a lot of other resources). Maybe create a separate project or at least a ticket on minerva repo ?
In the Table describing the relations, you could simplify by removing the 'Description' link and making the relations themselves clickable ?
I don't have a strong opinion on this, if you think that's more readable, I can change it. My intent was to make the description explicitly visible/accessible. Just note that not all IRIs resolve to a web page (here those do), they are just identifiers.
'part_of' is a BFO term but is also present in RO - maybe 'occurs' in can also be added to RO, and in this case we may be able to claim we are using a single ontology ?
Currently, all the part_of in GO-CAMs refers to BFO, not RO, so this documentation has to reflect that so that users can create valid queries. In the ontology world, I don't know if that's better to state that we are using a single ontology ? part_of should probably never be in 2 ontologies in the first place, unless we mean something different.
@kltm I pushed the sparql.html standalone page to this repo: https://github.com/geneontology/geneontology.github.io/commit/66d66751ac9c79f8c79f2705bb374414d91dfa71
If you have difficulties deploying it on sparql.geneontology.org, please refer to the steps I took for S3/Route53 here: https://github.com/geneontology/geneontology.github.io/issues/267#issue-778497918 and which give us this page & route: http://sparql.geneontology.xyz
Thanks
regarding the specific content to go on the static documentation page, let's set up another ticket for this page, as @lpalbou says:
This ticket is to deploy in production the new UI page for the GO SPARQL endpoint:
There is a little mix indeed, so let's be clear, there are two pages:
I suggest a modification to the 2nd item in the checklist
As a general principle, I vastly prefer minimizing the number of moving pieces. I would rather not add an extra bucket just for deploying a static html file. While it is trivial, it adds to the overall complexity of configuration of the system, add introduces additional things that need synchronized.
My preference would be that all static html served to the public is done from a single source, which is this repo. We would simply check the html into this repo, and it would be deployed automatically. There is no need to set up an additional job to sync content from github to a new bucket. We would still need to have http://sparql.geneontology.org point at this page (3rd item in checklist).
Right. As it is, the page is already on GH and also accessible through: http://geneontology.org/sparql. So if you prefer without S3 bucket, I will replace step 2 by @kltm creating a proxy from sparql.geneontology.org to http://geneontology.org/sparql.
Okay, playing around a little with this, it seems like I have found settings for both forwarding and full proxying. Given what I think the uses are right now, I'm a little more comfortable with having the forward in place (less mechanism, less likely to get weird later). The forward is currently applied. @cmungall Do you have an opinion which way to go here?
Proxy seems to be working.
Other issues / recommendations can be added as separate tickets, deployment done.
The documentation page http://geneontology.org/docs/sparql/ has been completed but is not yet referenced (https://github.com/geneontology/geneontology.github.io/issues/269).
The SPARQL entry point described in the GO article is http://sparql.geneontology.org. Currently, this redirects to a generic blazegraph workbench page with no mention of GO or example.
This ticket is to deploy in production the new UI page for the GO SPARQL endpoint:
Steps:
@kltm to store that page on a GO S3 bucket "sparql.geneontology.org" and activate the "Static website hosting"@kltm to change the routing of http://sparql.geneontology.org from http://rdf.geneontology.org/blazegraph/ to that newly S3 bucket:The following is just for reference as @cmungall would prefer a proxy to a GH page. If it was to be done with CF/S3/Route53, it could be done that way:
Result on my test architecture (http://sparql.geneontology.xyz/):![Screen Shot 2021-01-04 at 5 31 43 PM](https://user-images.githubusercontent.com/24249870/103596401-b99ab080-4eb2-11eb-9147-42abc09dc214.png)
It's important to use the correct bucket name, or you won't see that option for the routing. If you have additional difficulties, you could otherwise just create a CF distribution to that bucket and route the subdomain to that CF distribution.