- work in progress -

Skip to end of metadata
Go to start of metadata

This page provides a step-by-step introduction to the syntax of the iteraQL query language. In the forthcoming sections the syntax is presented with examples, covering the different operators and language features.

Selection Queries

Selection queries are the simplest ones available in iteraQL. A selection query does not employ operators and only uses the elements of the iteraplan meta-model. There are two kinds of selection queries, for building blocks and relations, respectively. A simple building block selection query is

 InformationSystem ;

which simply retrieves the list of all instances of the Information System building block. Instead of 'InformationSystem' the name of any building block or association can be used. A selection query can also select a relation, in which case a binding set is returned. A simple relation query is

 informationSystem / projectAssociations / project ;

which retrieves all pairs of related instances of the Information System and Infrastructure Element building blocks. In general, a query always specifies an initial building block or association, optionally followed by operators. A query may further contain one or more relations or relation operators and terminates with a semicolon (';').

Querying with Operators

Having presented the simplest kind of queries, the selection queries, we can now continue with the introduction of a first operator.

The Join Operator

The join operator is the simplest and one of the most relevant operators available in iteraQL. Furthermore, what distinguishes the join from the other operators is the fact that it requires no keyword. This operator takes two relations and produces a new relation by 'gluing' them to each other. For example

 InformationSystem /businessMappings /businessProcess ;

is a query which retrieves all pairs of instances of Information System and Business Process, which are connected over a Business Mapping instance. Also, the join operator is recursive, which means that it can be applied to an arbitrary number of relations. For instance, the query

 InformationSystem /businessMappings / businessProcess / businessDomainAssociations / businessDomain ;

evaluates just as the previous one does, but further extends the result to all Business Domain instances reachable from any Business Process instance which was in the result of the last query.


The second most relevant operator is the filter operator. This operator can be applied to any building block or association, as well as after each relation in a join operator. The filter operator allows the definition of some criteria, which is used to reduce the set of selected instances to only those entities, which satisfy the criteria. When applied after a relation, the operator filters the set of elements reachable over this relation. Syntactically, filters are given denoted with square brackets ('[' and ']'), which enclose the filter criteria. The condition itself can contain any property of the current meta-model element, or any property obtained through a property operator, or a complex combination of several properties (see below). An example for a simple filter is

 InformationSystem [ @Costs > 100 ] ;

which reduces the set of Information System instances to only those, whose value of the 'Costs' attribute exceeds one hundred. The '@' character denotes the name of an attribute of the context building block or association (here Information System). There are several more comparison operators for properties, all of which are listed in the Predicates and Predicate-Defining Operators. Currently, you can only specify the dependency between a property and a value, not between two properties. 

Complex criteria

Except for the simple criteria based on the value of one attribute, iteraQL also supports the definition of complex criteria through the three boolean operators AND, OR and NOT. The AND boolean operator is given through the ampersand character '&' given between the two sub-criteria. For example

  InformationSystem [ @Costs > 100 & @Accountability = "Bob Beckett (bob)" ] ;

will select all instances of Information System with costs greater than one hundred which also are accounted for by tom. Further, one might also want to select all Information Systems with costs over hundred which are accounted for by either tom or alice. This can be formulated as

 InformationSystem [ @Costs > 100 & (@Accountability = "Tom Javas (tom) " | @Accountability = "Alice Miller (allice)" ) ] ;

where the '|' character denotes the boolean OR. Note also that the two alternatives for the Accountability attribute are enclosed in brackets. This guarantees the unambiguous order of application of the sub-criteria. The third boolean operator in iteraQL is the negation (NOT), which is denoted with an exclamation mark ('!'). For example, the query

 InformationSystem [ (!@Costs > 100) & (@Accountability = "Tom Javas (tom) " | @Accountability = "Alice Miller (allice)" ) ] ;

will select all instances of Information System with costs no more than hundred and which are also accounted for by tom or alice. Note that while it is possible to include an arbitrary number of sub-criteria by combining them with the AND and OR operators, one should take the possible ambiguousness of the resulting expression into account and enclose in brackets accordingly.

Property Operators

Property operators extend the set of attributes available for a given building block or association by allowing the user to construct further, synthetic, attributes. The following property operators of iteraQL are covered: view, count and foldLevel.

The view operator creates a new property in the context building block or association type by 'copying' the property from a related building block or association. For example the query

 InformationSystem [view(/infrastructureElementAssociations/infrastructureElement@name).contains("server")] ;

will create a synthetic attribute for the Information System building block and will obtain all instances, for which this property has a value containing the string 'server'. Note that the resulting instances are exactly the instances of Information System connected to an Infrastructure Element instance whose name satisfies the given condition.

The count operator can be applied to an attribute or to a relation and retrieves the number of values or related instances, respectively. Consider the query

 InformationSystem [count(/businessMappings/businessUnit) > 2];

Here, the count operator creates a new attribute in the Information System building block and for each instance the value of the new attribute is the number of Business Unit instances, related over any instance of the Business Mapping association.

The third property operator is the foldLevel operator. This operator requires either a self-referencing relation (like the 'parent' direction of a hierarchy relation), or a cyclic relation, obtained for example through the join of two or more relations. For each instance of the context building block or association, the value of the new foldLevel attribute will be the number of steps over the given relation, until no further instances can be reached. To illustrate this, let us consider the query

 BusinessProcess [foldLevel(/parent) = 1];

The result of this query will contain all instances of Business Process whose parent instance is the root of the hierarchy of Business Processes, i.e. all first level Business Processes.

Further Operators

There are several further operators available in the iteraQL query language.


The objectify operator can be used both for building blocks and associations, and for relations. The operator is provided with an attribute of the context building block or association (in the case of a relation this is the destination type of building block or association) and derives a new building block from the selected attribute. The values of this new building block are exactly the values of the attribute for the context type. Furthermore, every instance of the context building block or association is provided with a relation to the instance(s) of the new building block which represent the value(s) of the attribute of the original instance. An example for an objectified building block is the following:

 InformationSystem .objectify(@Accountability) /isValueOf;

The query will retrieve the relation between the new building block and Information Systems. Every instance of the new building block will be related (over the isValueOf relation) to exactly those instances of Information System which have the value represented by the corresponding instance of the new building block set for their objectified attribute.


The expand operator is also available for both kinds of query - building blocks or associations, and relations. This operator requires a self-referencing relation or a cyclic path and produces a new building block or association which enriches the base one with all instances reachable through the provided self-referencing relation or cyclic path. When applied in the context of a relation, the context type of the expand operator is the one the relation leads to. The expand operator can, for example, be used to answer the question 'Which Information Systems depend on the same Technical Components as the CRM Information Systems?'

InformationSystem[@name.contains("CRM")] .expand( /technicalComponentAssociations/technicalComponent/informationSystemAssociations/informationSystem);

First, a new building block type which represents all Inforamtion System instances with 'CRM' in their name is created. Then this new type becomes part of a further building block type - the expanded type - which also includes all Information System instances which share a Technical Component instance with any instance from the first type. Thus, the instances of the expanded type are both the Information Systems with 'CRM' in their name and all instances related over a Technical Component instance.


The nullify operator can be used both for building blocks and associations and for relations, although there is a slight difference in its application. When applied to a building block, the nullify operator requires no argument. For example, the query

 InformationSystem .nullify();

will create a new building block type, the Nullified Information System type, which extends the Information System type with one feature - the new type has one further instance, the null instance. The null instance has the property that it relates everything which is not related to any other instance of the Information System building block type. This can be useful, for example, when querying for Information Systems together with their related Technical Components, while also including those instances of Technical Component which are not related to any instance of Information System. The result set of the query

 InformationSystem .nullify() /technicalComponentAssociations/technicalComponent;

will contain bindings from the null instance to all instances of Technical Component which are related to no Information System instance.

When applied in a relation context, the nullify operator requires a further relation, which is given as argument. In this case, the relations are not from, but rather to the null instance. For example, the query

  InformationSystem [@name.contains("Mgmt") | @name.contains("SAP")]  /children .nullify( / technicalComponentAssociations / technicalComponent ) ; 

will have bindings to the Technical Component null instance whenever an Information System instance from the children of the 'SAP' and 'Mgmt' Information Systems has no other Technical Component instance related.


The power operator can only be applied to building blocks and creates a new building block type, the power type. The type has only one instance, which is related to all instance of the original building block type over the 'isContainer' relation. An example query is

 InformationSystem[@name.contains("CRM")] .power() /isContainer;

which maps the power instance to all instance of Information System whose name contains 'CRM'.


The unfold operator can be used only in a relation context. The operator requires a self-referencing relation or a cyclic composition of relations, and produces a new relation itself. The instances of the new relation are all instances reachable over the argument relation, after an arbitrary number of hops, until no new elements can be added. For example the query

 BusinessProcess[@name.contains("Management")] .unfold(/children);

will return the 'Management' Business Process with bindings to all its hierarchical children, direct and indirect.

  • No labels