Having provided semantics for our languages, we can now write the actual queries that will make use of the underlying solvers. The primary purpose of the query is to indicate to the Back-end how it must handle the model, and, in particular, how it must structure the “answer” to the query. In short, one must construct a JSON that specifies the structure of one’s request leveraging the different services offered by the solvers.

Now, concretely, the definition of the queries is made through the construction of an object that follows the structure defined by these attributes:

“solver”: This defines which of the solver backends is to be used for solving. This can either be “minizinc” or “swi”.

"solver": "minizinc",

“operation”: This defines the solver operation to be carried out. The currently supported operations are “sat” which tests satisfiability, “solve” which asks for a specific solution for the problem, and “nsolve” which asks for the set of solutions.

"operation": "sat",

“operation_n”: This parameter is optional, and defines the number of solutions to look for, which in practice means that one will have as a result at most n solutions. This is a positive integer value.

{
 "solver": "minizinc",
 "operation": "nsolve",
 "operation_n": 10
}

“iterate_over”: this attribute contains a list of objects that each define the elements over which one will perform the iterative solving, i.e., the problem will be modified in some way for each of the elements/relations identified in the iteration specification, and after such a modification it will be solved. By default and for now, the fundamental operation that is supported is that of satisfiability checking. The specification object itself serves as a lookup mechanism to determine the ids of the variables to be modified. For now an assumption is made that the correlation is to be made between the object/relation identifiers and the actual CSP variables to be modified. In addition, the operation that is performed is that of fixing the variables to a specific value which is encoded in the “with_value” attribute.

{
 "solver": "minizinc",
 "operation": "sat",
 "iterate_over": [
   {
     "model_object": "relationship_element",
     "relationship_element": "target",
     "object_type": [
       "Optional"
     ],
     "with_value": 1
   },
   {
     "model_object": "reified",
     "relationship_element": "target",
     "object_type": [
       "Range",
       "Xor",
       "Or"
     ],
     "with_value": 1
   }
 ]
}

The attributes in this object are:
“model_object”: this parameter defines what element is to be looked for in the VariaMos graph. The possible values that can be used are: “element”, referring to particular element in the graph; “relationship”, referring to a relationship that has a CSP variable associated with it; “relationship_element” referring to the source or target of a given relationship when what is of interest is the relationship’s type; and, finally, “reified”, which refers to the elements of a reified relationship wherein what is of interest is the set of targets or sources of this relationship that is reified by an element.
“relationship_element”: this optional parameter defines, when one is referring to a relationship_element or a reified relationship, which of the two sides of the relationship to look at. The two possible values are: “target” and “source”.
“object_type”: this parameter defines the specific types (understood as those types defined as part of the element/relationships properties) that are used to select the elements/relations of interest. It takes a list with all the values of types that one is looking for. In addition, it follows the type lookup rules that are used in the semantics definition, i.e., it respects the property lookup rules for types.
“with_value”: This parameter defines the specific value to which the CSP variable, associated with the given element, is to be bound to.

A set of complete query examples are available under the json folder all beginning with query_.

An additional operation that can be called which is primarily useful for debugging the semantics while one develops the model is "operation":"get_model" which will return the actual model in CLIF notation, so that one can determine whether one’s semantics are correctly protrayed.