Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mine filters - refactor to use pathquery #7

Closed
yochannah opened this issue Aug 1, 2018 · 5 comments

Comments

@yochannah
Copy link
Member

commented Aug 1, 2018

We would like to create a webservice to allow mine admins to explicitly state which filters will be available in the tool for their mine. Right now our filters are hard-coded to certain functions. This won't scale well for other InterMines - instead, we should consider something like this:

{
  mineUrl: "http://www.kittenmine.com/kittenmine" //I think URL is probably the safest way to uniquely identify a mine
  customFilters: [{
      filterQuery: {
        "constraintLogic": "A and B",
        "from": "Gene",
        "select": [
          "alleles.clinicalSignificance"
        ],
        "orderBy": [{
          "path": "alleles.clinicalSignificance",
          "direction": "ASC"
        }],
        "where": [{
            "path": "alleles.type",
            "op": "=",
            "value": "XXX",
            "code": "A"
          },
          {
            "path": "alleles.clinicalSignificance",
            "op": "=",
            "value": "YYY",
            "code": "B"
          }
        ]
      },
      filterName: "CLINVAR"
    },
    {
      filterQuery: {
        "constraintLogic": "A and B",
        "from": "Gene",
        "select": [
          "alleles.clinicalSignificance"
        ],
        "orderBy": [{
          "path": "alleles.clinicalSignificance",
          "direction": "ASC"
        }],
        "where": [{
            "path": "alleles.type",
            "op": "=",
            "value": "XXX",
            "code": "A"
          },
          {
            "path": "alleles.clinicalSignificance",
            "op": "=",
            "value": "YYY",
            "code": "B"
          }
        ]
      },
      filterName: "ClinVar"
    }, {
      filterQuery: {
        "from": "Gene",
        "select": [
          "diseases.name"
        ],
        "orderBy": [{
          "path": "diseases.name",
          "direction": "ASC"
        }]
      },
  "where": [
    {
      "path": "diseases.name",
      "op": "=",
      "value": "ZZZ",
      "code": "A"
    }
  ]
    },
    filterName: "Diseases"
  ]
}

@yochannah yochannah added this to the Version 1.1 milestone Aug 1, 2018

@yochannah

This comment has been minimized.

Copy link
Member Author

commented Aug 1, 2018

Tagging @AdrianBZG and @julie-sullivan for comments as I may have missed something

@yochannah

This comment has been minimized.

Copy link
Member Author

commented Aug 1, 2018

We also need to consider whether different classes need different filters configured. I think they probably do.

@AdrianBZG

This comment has been minimized.

Copy link
Member

commented Aug 24, 2018

@yochannah @julie-sullivan I was thinking about an idea relating this issue with #8 :

What if on the example JSON with the pathquery for each filter, we use the ""from": "Gene"," keys (from keys) to create dinamically the views buttons on the top, allowing the person configuring the service to add or remove classes just by creating an specific filter for such class. So it will work like this:

  • By default, the same thing, we have 2 classes (Genes and Proteins) + the 4 default filters. This always like that.
  • The user can add for instance a filter applied to Gene view in the Json, so the tool will just add that filter to the sidebar when the user is in that particular view.
  • The user also can add a filter applied to Substitution (from: Substitution) in the Json, the tool will add to the top a Substitution view button, and when the user goes to that view, the 4 default filters plus this other filter will be shown.

What do you think?

@yochannah

This comment has been minimized.

Copy link
Member Author

commented Aug 28, 2018

@AdrianBZG I think this sounds good (dynamically configured from json sounds about right lol) but I'm not entirely sure I understand. could you elaborate or provide another example? (sorry!)

@AdrianBZG

This comment was marked as outdated.

Copy link
Member

commented Aug 29, 2018

@yochannah Let's take for instance the example json you provided for HumanMine (https://gist.github.com/AdrianBZG/124b7ec72ad762ffd11315f63cb9cbe2), the tool, when reading this json, should take care of, after the 4 default filters (Organism short name, Pathway Name, GO Annotation, Dataset Name), adding the following ones in the Gene view, since according to the json there are custom filters on Gene view (from: Gene):

  1. ClinVar
  2. Diseases

If we ellaborate another example where there can be more views than Gene and Proteins, we have for instance BeanMine, see model here: https://gist.github.com/AdrianBZG/bfbaec0b602e5a2c77b4b95c460e259d

Where there are, among others, the following views: QTL, Gene. We want a way to add QTL dinamically as a new view to the tool (top button), to do so, what I'm suggesting is to allow the user to configure the json like this: https://gist.github.com/AdrianBZG/4936a9cbe423737ee40ed24b00e70435

As you can see, the tool should realize that there are 2 things to do according to that json when searching on BeanMine:

  1. There is an extra filter on view/class Gene, called Organism Variety, and since the Gene view is already there because is one of the 2 defaults, this is only a matter of adding the Organism Variety filter to the left.

  2. There is an extra filter on view/class QTL, called Experiment Trait Name. Here two things should happen, the tool should add a new top button to change to the QTL view, and inside this view, a extra filter for Experiment Trait Name should appear.

@yochannah Please tell me if I'm not explaining correctly and I will ellaborate further.

The next point is, when adding this extra filters, we need to somehow parse them to add the correct number and type of input fields to the filter, what I mean is the following:

  • In the example above for BeanMine, a new Organism Variety filter is added in the json, so we need to detect that there is only 1 input field (organism variety), so the tool adds: (1) a text input field and (2) the filter button. This shouldn't be a problem since we can just count the number of elements in the "where" array from the json, but to do this in a general way for any filter to work, we need to agree in how the layout of each filter will be created in order to avoid design issue. What I mean is:

  • Are we ok by having the input fields one below the other, just like the ClinVar filter:

image

Getting rid of a layout where the fields are not in that way, see for example Start and End from Location:

image

Which by using the suggested approach, the Start and End fields will no longer be "in the same row", but one below the other: each field, one row. The reason is that we want the tool to create this automatically just by reading the json.

Sorry for long text, but I think that those are relevant things to think a bit.

😉

AdrianBZG added a commit to AdrianBZG/InterMine-Data-Browser-Tool that referenced this issue Nov 19, 2018

@AdrianBZG AdrianBZG closed this Nov 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.