Bug #4321
closed
Semantic types on workflows saved into library not searchable
Added by Sean Riddle over 15 years ago.
Updated about 15 years ago.
Description
Assigning semantic types to a workflow is recommended when saving it into a KAR file (where it is then visible in the workflow section of the library panel). Unfortunately the workflow is not returned in response to a search on that semantic type, but only on searches matching components within the workflow. Matching on semantic types is desirable, especially as semantic types take on more importance with the advent of the new tagging functionality.
This problem is a regression from previous functioning behavior, likely related to changes in how the library indices are built. Need to re-establish the link to the semantic search so that it works as it did in 1.0.0.
I have looked into this bug a little. After downloading Kepler 1.0.0 I was able to match all the components in an Ontology or class by entering exactly the name of the class. For example, in Kepler 1.0.0 type in "Remote Input" into the component library search. You will get the "Remote Input" class as a result and everything underneath it gets included automatically. Examining the search algorithm there is no matching of semantic types on the individual actors, it assumes that the actors are in the right folder and therefore only matches the folder name. This is supported by the result count at the bottom which for this example is "1 results found". If matching was being done on every actor's semantic types I would expect the result count to be much higher.
Another example of this is typing in "Components". You will now find 2 results are returned. One is the Components ontology that gets everything underneath it added to the search result. And the other is "Principal Components Analysis" which is under the Statistics ontology.
After fixing bug 4421 (which was a problem only with displaying the results in the component library) these same examples show the same results in the HEAD version of Kepler as they do for Kepler 1.0.0.
The search(String) method of SimpleLibrarySearcher is where the component library search happens. Within this method there is a call to OntLibrarySearcher.search(String) method which I imagine is supposed to scan an index of semantic types and return results. However by analyzing the number of search results before and after the OntLibrarySearcher.search(String) method I have found that no results are ever returned for any search that I have tried. This leads me to believe that this functionality was also not working in Kepler 1.0.0, since the test examples I have mentioned return the same number of results in both versions.
My first thought on how to fix this is to include semantic type matching directly in the findval method of SimpleLibrarySearcher and remove any calls to the OntLibrarySearcher since it does not seem to do anything.
If you type the name of an actor in, I would expect the behavior that you described. However, the semantic search comes into play mainly when you search for terms that do not match the names of actors. Instead, if they match the names of ontology classes, then all actors tagged with that ontology class will be returned. Please discuss these issues with both Shawn Bowers and Chad Berkley before dismantling anything, as several other semantic system components are interelated (such as semantic workflow validation) and might break if you start removing things.
Looking forward to any comments from Shawn or Chad
OK, so the search is now implemented as I believe we want it to be implemented. It is currently a very slow way to do it, but the results that are returned are I believe what we want them to be. If someone could take a look and verify that the results are good I can work on speeding up the search and recombining the results into a single tree. I will work on something else for a while until I hear back. Perhaps we could get together sometime to discuss it.
semantic types on workflows are now searchable in the component library, closing this bug, see bug 4362 for further tasks on component searching
Original Bugzilla ID was 4321
Also available in: Atom
PDF