OBO-Edit: Proposals for Designing a New Filtering Interface

From GO Wiki
Revision as of 09:40, 26 June 2007 by Jrichter (talk | contribs) (New page: I think we all can agree that the existing OBO-Edit filtering interface has its problems. Compound filter editing is too complex for most users, but not powerful enough for the most advanc...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

I think we all can agree that the existing OBO-Edit filtering interface has its problems. Compound filter editing is too complex for most users, but not powerful enough for the most advanced users. This page will go over some possible different approaches. I hope that users group members will comment on this article with their opinions about which approach would work best...

Technical/Theory Changes

Changes to "Aspect"

Right now, the "Aspect" field allows you to search ancestors or descendants of a term, rather than the term itself. Unfortunately, this searches EVERY ancestor or descendant, and there's no way to constrain this by relationship type. I propose we add a modifier to Aspect that allows the user to specify a relationship type (or union of relationship types) to traverse when calculating the descendants and ancestors. If the reasoner is enabled, the filtering system will use the reasoner to do this calculation, which will be MUCH faster than the current method, and will give more intuitive results.

Script Filtering

Occasionally, a user wants to design a filter that just can't be expressed in the limited language of per-term boolean matches (which is basically how the existing filtering specifications work, with the Aspect feature tacked on as a useful extension). I suggest that we allow script-based searches for hard-core power users. The script-based searches would be specified in the OSL scripting language. So, for example, imagine someone wanted to find terms whose names contain the word "development", and that have a part_of relationship to a parent term whose name DOESN'T contain the word "development". They could write a search this way...

 function filter(term) {
    if (term.getName().indexOfIgnoreCase("development") == -1)
        return false;
    for link in term.getParents() {
        if (link.getType().getID().equals("part_of") &&
            link.getParent().indexOfIgnoreCase("development" == -1) {
           return true;
        }
    }
    return false;
 }

This kind of scripting is too complex for most users to bother with, but if a user DID write something like that, they could share their script with other users. Further, some of the schemes below allow simple searches to be combined to create more complex searches; in these cases, script-based searches could be dropped in as one of the simple searches, alongside the more conventional searches familiar to current OBO-Edit users.

Interface Proposals

Changes to the Basic Query Designer

At its core, any query design system is going to need a component that is used to create simple searches (although these simple searches may later be used as building blocks for complex searches). In OBO-Edit, that simple component looks like this: