Configure paths for anatomy queries

[cmungall]

Typically when we populate the closure field, we traverse the closure over SubClassOf only

If the category is Anatomy, then the closure should be over SubClassOf|BFO:0000050.

This can be tested when this is implemented:
monarch-initiative/dipper#147 (bgee gene expression loads)

Side note: really this should not need the addition of procedural code. We should have a generic configuration for this. This will be a separate ticket, for now see geneontology/amigo#210 (comment)

[cmungall]

This is the query: https://github.com/monarch-initiative/monarch-cypher-queries/blob/master/src/main/cypher/golr-loader/gene-anatomy.yaml

I suggest adding an additional tag to the yaml to indicate what paths should be used for subject and object closure, what do you think @kshefchek?

[cmungall]

E.g.

query: |
        MATCH path=(subject:gene)-[relation:RO:0002206]->(object:`anatomical entity`)
        RETURN DISTINCT path,
        subject, object, relation,
        'gene' AS subject_category,
        'anatomy' AS object_category,
        'direct' AS qualifier
object_closure: "SubClassOf|BFO:0000050"

(with equivalence being implicit)

[cmungall]

I have a test case for this, should I go ahead and put it in src/test/resources?

[benwbooth]

If I'm understanding this right, there should be optional keys for subject_closure, object_closure, relation_closure, and evidence_closure. Each value should be a pipe-delimited list of curies which will be converted into IRIs.

Right now the default closure types and directions are defined as:

• subclass, outgoing
• type, outgoing
• subproperty, outgoing
• equivalent_class, both
• same_as, both

If equivalence is implicit, does that mean equivalent_class and same_as should be implicitly added to the list of custom closure relationships? What about type and subproperty?

The CypherUtil module also defines a ! entailment operator. I'm not sure if that is relevant in this context or not.

Also, if the values are pipe-delimited curies, should the example object_closure value be "rdfs:subClassOf|BFO:0000050" instead of "SubClassOf|BFO:0000050"?

[cmungall]

On 26 May 2017, at 15:14, Ben Booth wrote: If I'm understanding this right, there should be optional keys for `subject_closure`, `object_closure`, `relation_closure`, and `evidence_closure`.

Correct.

Each value should be a pipe-delimited list of curies which will be converted into IRIs.

Yes - perhaps an explicit list would be cleaner (I went with pipe as this is already cypher syntax)

Right now the default closure types and directions are defined as: - `subclass`, outgoing - `type`, outgoing - `subproperty`, outgoing - `equivalent_class`, both - `same_as`, both

Yes, this last 2 are symmetric, hence the both

If equivalence is implicit, does that mean `equivalent_class` and `same_as` should be implicitly added to the list of custom closure relationships?

Yes. Hmm, I wonder if it makes sense to always have the 5 defaults be present, and have the new field only declare extra relations?

What about `type` and `subproperty`?

subproperty only holds between two relations, and subclass never holds between two relations. However, it's fine to have the list of default relations include both.

The `CypherUtil` module also defines a `!` entailment operator. I'm not sure if that is relevant in this context or not.

Ah good point! Yes, we should also include this.

Also, if the values are pipe-delimited curies, should the example `object_closure` value be `"rdfs:subClassOf|BFO:0000050"` instead of `"SubClassOf|BFO:0000050"`?

To be honest I forget what scigraph uses for SubClassOf, offline at the moment..

…

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #17 (comment)

[benwbooth]

What should the default DirectedRelationship be? OUTGOING? or BOTH? Or should I define matching keys subject_closure_symmetric, object_closure_symmetric for adding closure relationships with both directions?

[cmungall]

OUTGOING. No use case for BOTH/INCOMING

[benwbooth]

@cmungall Do you have that test case you mentioned? If not I can try and write a test case for this.

[benwbooth]

@cmungall How can I use the .ttl file to test this out? From what I've been able to figure out, golr-loader takes a neo4j graph configuration and a directory of queries and produces a directory of .json files to be loaded by solr. Is there a way to create a neo4j graph database and configuration file from the .ttl file?

[kshefchek]

@benwbooth I can create a small test file for bgee.ttl, which contains the gene-anatomy data, some test files are automatically generated during the pipeline: https://data.monarchinitiative.org/ttl/

Over the next week or so I was planning on updating the golr loader to batch insert documents into solr, instead of the intermediate json step, and also fix #30 (which I think may be more a neo4j/scigraph issue)

[cmungall]

Use @kshefchek's rather than mine.

The docs for loading a ttl file into scigraph are here: https://github.com/SciGraph/SciGraph

However for an automated test you want to do this programmatically directly within the junit test.

[kshefchek]

Here is a test file for bgee:
https://data.monarchinitiative.org/dev/bgee_test.ttl

There also a number of small test files in https://data.monarchinitiative.org/dev/, and https://data.monarchinitiative.org/ttl/ that could be of use. We previously had integration tests set up but these are stalled:
https://github.com/monarch-initiative/dipper-integration-test

https://github.com/monarch-initiative/dipper-integration-test/blob/master/src/test/resources/test-load.yaml

[kshefchek]

Will this allow us to implement #26 ?

If equivalence is implicit, what would configuring these closures look like? I assume we need some sort of way to say that a field is a closure.

[cmungall]

@kshefchek yes it would and good point. I guess relying on conventions in the string not so good

[cmungall]

Use @kshefchek's example data file, but you will also need to load in uberon

so the yaml config will have:

 - bgee_test.ttl
 - http://purl.obolibrary.org/obo/uberon.owl

For the prefixes, just use the prefixes in bgee_test.ttl, but you will also need

  BFO: http://purl.obolibrary.org/obo/BFO_

[benwbooth]

Hi @cmungall,

I loaded hippocampus.ttl using SciGraph. I do see a single relationship with type "RO_0002206", but I don't see any nodes with label "gene". I also tried bgee_test.ttl and didn't see any nodes with the "gene" label either. Does the query need to be modified?

[cmungall]

I think I know the issue, we need to add a rdfs:subClassOf edge between the gene URI in the ttl and the SO class for gene

…

On 12 Jun 2017, at 15:30, Ben Booth wrote: Hi @cmungall, I loaded hippocampus.ttl using SciGraph. I do see a single relationship with type "RO_0002206", but I don't see any nodes with label "gene". I also tried bgee_test.ttl and didn't see any nodes with the "gene" label either. Does the query need to be modified? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #17 (comment)

[benwbooth]

I wrote a pull request for this (see #34), please review and let me know what you think.