search

geneontology / noctua

Graph-based modeling environment for biology, including prototype editor and services
http://noctua.geneontology.org/
BSD 3-Clause "New" or "Revised" License
36 stars 13 forks source link

Transition to NEO for autocomplete services #220

Closed kltm closed 8 years ago

kltm commented 8 years ago

This will be necessary to complete #214 #213. NEO was completed in #215 , so now we need to start consuming it.

They way forward is fairly clear. We'll start by adding NEO to the load (https://build.berkeleybop.org/job/build-noctua-entity-ontology/lastSuccessfulBuild/artifact/neo.obo), then change over the different autocompletes. Once the transition is complete, the GAFs can be removed from the load.

Will need to figure out the root.

@cmungall @hdietze

cmungall commented 8 years ago

Current root is CHEBI:23367 ! molecular entity

That is somewhat liberal, and includes things like small molecules. I would argue this is a valid use of enabled_by (useful for drug modeling) but folks will probably complain; when they do we can introduce a more specific intermediate class

On 19 Nov 2015, at 16:53, kltm wrote:

This will be necessary to complete #214 #213. NEO was completed in

215 , so now we need to start consuming it.

They way forward is fairly clear. We'll start by adding NEO to the load (https://build.berkeleybop.org/job/build-noctua-entity-ontology/lastSuccessfulBuild/artifact/neo.obo), then change over the different autocompletes. Once the transition is complete, the GAFs can be removed from the load.

Will need to figure out the root.

@cmungall @hdietze

Reply to this email directly or view it on GitHub: https://github.com/geneontology/noctua/issues/220

kltm commented 8 years ago

Making copy of data in data.20151119 before trial run.

kltm commented 8 years ago

@hdietze and @cmungall It looks like the NEO file cannot be parsed, probably needs a unit test. https://build.berkeleybop.org/job/build-noctua-entity-ontology/lastSuccessfulBuild/artifact/neo.obo

2015-11-19 18:07:21,877 INFO  (ParserWrapper:74) Finished loading ontology: null from: https://build.berkeleybop.org/job/build-noctua-entity-ontology/lastSuccessfulBuild/artifact/neo.obo
2015-11-19 18:07:21,878 ERROR (CommandRunner:3973) could not parse:https://build.berkeleybop.org/job/build-noctua-entity-ontology/lastSuccessfulBuild/artifact/neo.obo
org.semanticweb.owlapi.io.OWLOntologyCreationIOException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:220)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:867)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:778)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:735)
    at owltools.io.ParserWrapper.parseOWL(ParserWrapper.java:172)
    at owltools.io.ParserWrapper.parseOWL(ParserWrapper.java:159)
    at owltools.io.ParserWrapper.parseOBO(ParserWrapper.java:145)
    at owltools.cli.CommandRunner.runSingleIteration(CommandRunner.java:3959)
    at owltools.cli.CommandRunnerBase.run(CommandRunnerBase.java:76)
    at owltools.cli.CommandRunnerBase.run(CommandRunnerBase.java:68)
    at owltools.cli.CommandLineInterface.main(CommandLineInterface.java:12)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1916)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:279)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:273)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1472)
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:213)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:913)
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:849)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1035)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
    at org.semanticweb.owlapi.io.AbstractOWLParser.getInputStream(AbstractOWLParser.java:140)
    at org.semanticweb.owlapi.io.AbstractOWLParser.getInputSource(AbstractOWLParser.java:261)
    at org.coode.owlapi.rdfxml.parser.RDFXMLParser.parse(RDFXMLParser.java:123)
    at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:212)
    ... 10 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
    at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
    at sun.security.validator.Validator.validate(Validator.java:260)
    at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1454)
    ... 24 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196)
    at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
    ... 30 more
[18:07:22] 'check-ontology-data' errored after 4.97 min
hdietze commented 8 years ago

This looks like an SSH/SSL issue. Can you try a load with http: instead of https:?

kltm commented 8 years ago

A little embarrassing--I noticed the ssh error, and was idly wondering how a parser error would end up throwing that, didn't occur to me to look at the URL. :crying_cat_face: The load now seems to be going forward just fine.

kltm commented 8 years ago

It seems to have loaded just fine; a cursory look seems to be pretty positive: http://noctua-amigo.berkeleybop.org/amigo/search/ontology?q=*:*&fq=regulates_closure_label:%22chemical%20entity%22&sfq=document_category:%22ontology_class%22

cmungall commented 8 years ago

Not showstoppers but just some oddities to note:

Landing on page for an entity class yields an error http://noctua-amigo.berkeleybop.org/amigo/term/ZFIN:ZDB-GENE-980526-41

Autocompleting on Shh Mmus lands us here: http://noctua-amigo.berkeleybop.org/amigo/term/http://www.informatics.jax.org/accession/MGI:98297

This is exactly as expected given yesterday's conversation about CURIEs, just noting it here

kltm commented 8 years ago

For the first one (ZFIN:ZDB-GENE-980526-41), it would seem that no proper graph is being generated for it? Does that sound correct, or should I dig deeper?

For the second one (http://www.informatics.jax.org/accession/MGI:98297), bleh. However, in my understanding, this is just a transitional problem, right?

cmungall commented 8 years ago

On Friday, November 20, 2015, kltm notifications@github.com wrote:

For the first one (ZFIN:ZDB-GENE-980526-41), it would seem that no proper graph is being generated for it? Does that sound correct, or should I dig deeper?

I'll check the ontology later to see if there's obvious issues

For the second one (http://www.informatics.jax.org/accession/MGI:98297), bleh. However, in my understanding, this is just a transitional problem, right?

Yep

—

Reply to this email directly or view it on GitHub https://github.com/geneontology/noctua/issues/220#issuecomment-158568379 .

kltm commented 8 years ago

Likely, the ZFIN:ZDB-GENE-980526-41 issue is caused by the bioentity from the GAF clobbering the term by its ID. To get around this, we'll drop the GAFs from the load, but still allow Minerva to get access to the information it needs at a separate "seeding" URL (see #225).

kltm commented 8 years ago

Reloading with no GAFs now (and using new flag for Minerva)--should load a lot quicker.

kltm commented 8 years ago

ZFIN-type issue now cleared, and load down to about an hour.

kltm commented 8 years ago

Need to reload NEO golr instance (noctua-golr.berkeleybop.org) to make sure that the MGI fix from @cmungall works correctly.

kltm commented 8 years ago

Will need further testing, but a cursory run over several several operations (including TAIR and MGI) seems to indicate that having both NEO and standard coordinated with each other works fine.