everbeek
commented
9 years ago I think that since BioPortal already has fully fleshed search functionality, that this BioMixer feature should instead be the import of a single concept on the basis of it's URI. As long as error handling is good, this is an acceptable, simple way of allowing this ability. Trying to create a complex search functionality with result paging, etc. is not really necessary.
Do we need search? Given a view loaded, the user might desire to load a specific other node, from the same ontology or otherwise. I recall that search results could be verbose, and I am not sure how it is supported in the current API.
This also offers up possibilities such as the case Cassie mentioned, of finding the shortest path between two concepts. That would require loading the two desired, then designating them as endpoints, and running a whole lot of REST calls. This is really expensive on the client side. The user might have a better idea (by being able to interpret the meaning of the nodes) and less expensive expansion operations than would the breadth first search we would have to do otherwise.
This is important in particular for the uc7, analyzing an ontology in order to annotate.
The search should be limited to ontologies present in the graph. Or...perhaps the search could also allow for a search within one specified ontology.