Implementation Ideas: Model closure parser

[tmushayahama]

Any ideas for an implementation/algorithm for a simple model graph parser to check if each model's node has a valid isa_closure/regulates_closure. isItAClosure(a, b) is working fine, but it is a server call.

So since it is an asynchronous call, current algorithm is to just wait until the isItAClosure() server call returns with an answer. However this is problematic when I am traversing the graph.

Is there any info on the node (meta data) to pre-parse so that I cannot call the server or limit the isItAClosure() call?

Reason for checking besides error messages is to see if a model is a simple model, macromolecular complex, CC Only, BB Only, CC Only but macromolecular etc.

[kltm]

@tmushayahama Would you mind stepping back a bit and describing what you are trying to accomplish with this? As well, when you say a server call, it this something that you've implemented elsewhere, or are you going against the GOlr/Solr backend?

[tmushayahama]

In brief, given any node in the graph, I want to see what type it is. Is it MF, BP, GP, CC, MacromolecularComplex (the autocomplete constraints used).

The server call goes to the GOlr/Solr backend. (a subset to the autocomplete call)

[cmungall]

cc @balhoff @dougli1sqrd this kind of testing nodes for their high level type is going to be a common use case. It's trivial to do this with a SPARQL query, but at the moment we can't do arbitrary SPARQL. While it's also possible to do this querying against isa closure in Solr, I'm not sure this is the best approach long term (though it would probably work for @tmushayahama's use case here)

One option is to include these every time in the payload from minerva

[balhoff]

This can certainly come from the reasoner. Maybe we are moving to a point where the reasoner is not optional... but it still may add a fraction of a second hit if applied to every change. Maybe a service for asking for these high level types would not necessarily run constantly?

[kltm]

@tmushayahama For the time being, you would use the isa_closure that we added. As well, some information about gps and ontology "aspect" are already built into the annotation document category. I would use the former approach for now.

That said, while fine for smaller models, something like this might not scale for larger models.

[cmungall]

@tmushayahama Is there a way to restate this ticket so that it is actionable?

I'm not sure I follow the context of the original question, but it seems like something that should be folded into a more general validation framework. This would not be SAE-specific?