search

thechiselgroup / biomixer

BioMixer
http://bio-mixer.appspot.com/
16 stars 13 forks source link

Incorrect Ontology on Single Node Import? #500

Closed everbeek closed 9 years ago

everbeek commented 9 years ago

I found a concept attached to "artery" in UBERON, that when imported via URI, shows up as a different ontology. Use the following Url and concept URI:

http://127.0.0.1:8888/conceptPathToRoot.html?initial_vis=term_neighborhood&ontology_acronym=UBERON&full_concept_id=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FUBERON_0006591

http://purl.obolibrary.org/obo/UBERON_0008311

everbeek commented 9 years ago

Asked Cassie's opinion between adding all ontology instances, versus adding the "best" instance given context, and she thought completeness was better than failing at mind-reading the user.

Actually, this is also a more general bug. If a node appears in two ontologies, and both should be loaded, they will not. Their ids will conflict, and the latter one(s) to be added will not manifest. Arcs will be drawn to the one from all "related" ones, but those are not explicit arcs, and therefore are invalid.

This discovery and the goal of completeness will require that I change how concept ids are used internally, with the requirement that they are tracked by both id and ontology they were brought in with. There is a good chance this will be trivial.

I also need to re-enable node cap for this use case, in case there are concepts that occur in, say, one hundred ontologies.

everbeek commented 9 years ago

I seem to have things working, except for revision of the node ids. Sorting that out before committing.

I am hitting a troublesome spot regarding the edges and the edge registry. This system is necessary to keep all the asynchronously loading data in check, but I'm having trouble deciding how to adapt it to the new ids...I see pitfalls in both directions...

everbeek commented 9 years ago

The changes to node id made things a bit messier, but I think I can clean it up by composing the simple uri and acronym into an object, rather than concatenating them into a string like I did. I will look into this.

No, it doesn't look particularly helpful to do this. The number of string conversions required anyway, combined with access to properties, would make things messier.