Page History

...

• ADD: Default behavior if the query parameter is not provided. Adds the new value to the annotation. If it already existed, the value will be replaced.
• SET: This action might be really harmful. It will set the annotations provided in the body of the POST operation and will remove any other annotations the annotationSet might have had stored.
• REPLACE: Replace the value of an already existing annotation. Similar to the ADD action but, in this case, If the annotation did not exist, it will not set the new value !!

• REMOVE: Empty the values of some stored annotations. To perform this action, the map of the body will need to contain the key 'remove' and a comma separated list containing the annotations to be removed. Example: {"remove": "member.address,member.age"}

• RESET: Reset the values of the annotations defined to their default values defined in the variables of the variableSet. To perform this actiont, he map of the body will need to contain the key 'reset' and a comma separated list containing the annotations to be reset. Example: {"reset": "member.address"}

Querying by clinical data

...

• Filter by variableSet: Users might want to filter all the entities that have been annotated (have values) using one user-defined variableSet. * Follow Filtering by variableSet and annotationSet section defined below to see the supported operations.
• Filter by annotationSet: Users might want to filter all the entities that have been annotated (have values) for one particular annotationSet. * Follow Filtering by variableSet and annotationSet section defined below to see the supported operations.
• Filterby annotation: Users are also allowed to filter by any of the clinical data values. Example:

...

• The first option to search, though longer, should never fail as long as there exist a variableSet in the study containing the variables that are being queried. Basically, we are telling OpenCGA to look for any Individual matching those values but, at the same time, we are giving OpenCGA information of where the variables the user want to look for have been defined (the variableSet that defines those variables). A general way of seeing this query would have the following format: [[{annotationSetId}@]{variableSetId}:]{variable}{operator}{value}, where operator can be any of =, == or != for any data type, plus >, >=, <, <= for numeric variables.

• However, OpenCGA also allows performing the query using the shorter way as seen in the second line in which users can omit specifying the variableSet where the variables were defined. In this case, OpenCGA will look for all the VariableSets that might have defined these variables and, as long as those variables have only been defined in one VariableSet, the query will be performed. Otherwise, OpenCGA will raise an error because it will not know the real scope of the query.

...

In this case, the operators =, == and != are also supported, though they might give unexpected results to the user. For this reason, we have also added === and !== operators to support any possible query operation. An example containing the results that would be obtained is shown in the table below:

Project the annotation fields to return

...

• Include/exclude specific variableSets: Let's say that for some entries the user have created several annotationSets using the same variableSet and the user wants to fetch only those instead of getting other annotationSets. To do so, users will need to use the prefixes "annotationSets.variableSetvariableSetId" or "variableSet". Example: Let's imagine that we have another Individual that contains 2 annotationSets (a and b) using the template defined in the variableSet X and another annotationSet (c) annotating the variableSet Y. If the user is only interested in getting the annotationSets "a" and "b", we will need to write:

      include: annotationSets.variableSetvariableSetId.X

            or

      include: variableSet.B

Flatten annotations

Additionally, the different /info and /search web services have a new query parameter called flattenAnnotations. That field is a simple boolean to indicate whether the annotations should be returned flattened or not. Let's imagine we have the following annotationSet:

...

The same result with flattenAnnotations set to true would be:

{
  "id": "annotation_set_id",
  "variableSetId": "individual_private_details",
  "annotations": {
    "full_name": "John Smith",
    "age": 60,
    "gender": "MALE",
    "address.city": "United States",

...

    "address.zip": "99501"

...

...

}
}

GroupBy

• We can put something like the following the 'fields' field: annotation:29:pedigreeAnnotation:Population to group by Population

...