search

geneontology / go-graphstore

Gene Ontology RDF GraphStore
3 stars 4 forks source link

Create goose-gannet equivalent #9

Open cmungall opened 7 years ago

cmungall commented 7 years ago

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

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

cmungall commented 6 years ago

@dougli1sqrd will investigate extending yasgui framework.

cmungall commented 6 years ago

Could also explore using a hosted Jupyter notebook, e..g https://notebooks.azure.com/ with https://github.com/paulovn/sparql-kernel

kltm commented 6 years ago

I believe that we should align the needs and reusability between these two: https://github.com/geneontology/noctua/issues/465#issuecomment-328244894

kltm commented 6 years ago

Also: https://github.com/geneontology/noctua/issues/465#issuecomment-328882200

kltm commented 6 years ago

Talking to @hchiba1 of SPANG (http://mbgd.genome.ad.jp/spang/) a little at BH17, and he had some other pointers for people exploring in this direction:

https://lists.w3.org/Archives/Public/semantic-web/2012Jul/0172.html https://lists.w3.org/Archives/Public/semantic-web/2015Jan/0150.html https://github.com/ldodds/sparql-doc

The last one seems to be closest to what we'd want, but unfortunately doesn't mention templating, so maybe a combination, if following these suggestions. One thing that I don't like, versus a straight YAML and template solution, is that we'd end up with Yet Another Format that would have to be parsed across various languages and implementations, rather than PotS. I understand the desire to have Everything SPARQL, but there may be practical limitations to that approach. Always interested in more feedback.

cmungall commented 6 years ago

The nice thing about embedding metadata or docs in the comments (sparql-doc) is that the content/file can be immediately passed straight to the endpoint, e.g. using curl. Even though extracting from yaml is trivial, it adds an extra step that could be an annoyance.

Nothing that says this would not be composable with a template approach.

kltm commented 6 years ago

Totally agree here, but we run into the issue of having to deal with custom parsers for the information that we'll need to do what we (I) want. As well, the sparql-doc doesn't quite cover the templating uses. I'm a bit on the fence about this, and I'm not married to any one solution yet. It will be good to go over this in meeting when I can cover live examples.

cmungall commented 6 years ago

I'm going to crowdsource this from the wider semweb community here: https://docs.google.com/document/d/1bH7L6iPUsZJdkbjJZySoGHAfXyLif3Bas7Q4D66y0GA/edit