geneontology / go-graphstore Goto Github PK

The current Travis config doesn't do anything useful. A working config could test that the build procedure is able to run all the way through; however, the build as specified by the Makefile requires a very large amount of memory to run (~100 GB). We could:

1. Make the the inputs entirely configurable and build a similar but much smaller database via Travis.
2. Forget about Travis and automate the build on Jenkins with sufficient resources instead. In this scenario we could run content-specific validations and also deploy the output.
3. Both.

Opinions @cmungall or @kltm?

in particular, traversal from uberon

TBD: do as partial DL query (owlet), sparql property paths, or RDFox tbox-in-abox

This ticket is to evaluate:

#2

Depends on geneontology/go-site#206

Don't hardcode file locations in makefile - make this driven by metadata

Need to decide how to group triples into named graphs. The current approach is simple and easy to use: one graph for asserted triples and one graph for inferred triples. This way inferences can be included or excluded easily, even for specific parts of a query.

One problem with this is that it is difficult or impossible to access metadata associated with particular LEGO models, since this metadata is attached to the LEGO model ontology IRI. There is no link at the RDF level between a LEGO model IRI and any of the nodes within that model. In the Minerva triplestore each LEGO model is stored in a named graph with the IRI of its ontology. But this is a bit hard to use from SPARQL. The only way to query across all models (without naming hundreds of graphs) is to use the default graph, but that prevents you (I think) from excluding inferences when you want to. Blazegraph has a "virtual graph" extension but that would require some extra bookkeeping to insert all the asserted graphs into the virtual graph.

A workaround could be to add rdfs:isDefinedBy links, in Minerva, between model nodes and the model ontology IRI.

I would like to archive this repo. I would close all tickets and be done with it.

Tagging @balhoff @cmungall

@kltm suggests checking in jar, but about mvn/ivy/sbt/gradle instead? http://mvnrepository.com/artifact/com.blazegraph/bigdata-core

Would be nice to have https only IRIs in service clauses at remote endpoints.

Looking at the travis, it looks like oraclejdk8 is being used.

Since all production is done on openjdk, this should be switched to openjdk as well.

We want to make it easy to run canned or templated queries.

@balhoff - what were the results of your evaluation of lodestar?

Grlc is a service that builds APIs based on sparql files in a repository.

Let's utilize this by making a new repo in geneontology, moving some example queries in the repo, and then ultimately setting up some grlc to point at rdf.geneontology.org.

This ticket is for creating the repo and moving examples as separate files into the repo.

The current makefile is incomplete (only a subset of GAFs), and is duplicative with the new go pipeline; see the README

https://github.com/geneontology/go-site/tree/master/pipeline

We should roll in the generation of the ttl files into the main GO release pipeline, so that the ttls are available for download by others.