Simulates a fight between two randomly selected Pokémon. Who wins is based on the properties of the respective Pokémon, such a health points, attack, and defense abilities. The Pokémon that wins emits its victory cry.

This query uses the following features:

• GeoSPARQL vocabulary
• WKT serializations
• Federation (service clause)
• Property path notation (forward slash, /)

Used datasets:

• The key registry of Dutch buildings (BAG), published by the Cadastre.

Like geosparql-dutch-building-bracketed, but using square bracket notation to skip unused subject terms.

This is a very simple select query. But it already contains all three main select query components:

Projection

The columns that are returned (select ?s ?p ?o)

Triple Pattern

How the cells will be filled based on graph matching (?s ?p ?o.)

Result set modifiers

Adaptations to the result table (limit)

A simple select query that returns Pokémon (bindings for the variable ?pokemon) and their colors (bindings for the variable ?color), in that order.

Notice how the predicate term (i.e., the middle term) is bound to a specific IRI (<https://triplydb.com/academy/pokemon/vocab/colour>) that denotes the relationship between things and their depiction.

Identical to this query, but the lengthy predicate term that was used there is now abbreviated using alias (vocab). This requires that the alias and IRI prefix are declared at the top of the query (keyword prefix).

The part of the query that appears before the projection, and that contains prefix declarations, is called the Prologue.

Notice that another IRI prefix pokémon is also declared. This prefix is not used in the query itself, but is used to abbreviate the values that appear the first column of the result set table. (This is a Triply-specific feature.)

Like this query, but with the order of the columns inverted: the projection specifies which columns are included in the result set, and also specifies the order in which they appear.

This query only returns one column. This one column contains the colors of Pokémon (bindings for variable ?color).

The ?pokemon variable is used in the graph pattern, but its bindings are not returned in the projection. Variables like ?pokemon that are internal to the pattern component and are not exposed in the projection are called hidden variables.

Result sets must contain of at least one column. The same column may be included more than once.

The generic projection (select *) is used to include one column for every visible variable in the pattern component.

The order in which the columns are returned is not specified in the SPARQL standard and is implementation-specific. Often, columns are returned in the order in which the corresponding variables appear for the first time inside the pattern component, but this is not guaranteed. If the order of the columns is important, it is more robust to specify the variables explicitly.

Binding a variable

The bind keyword allows variables to be introduced that do not appear in a graph pattern.

HTML templating

Use {{variable}} notation in order to include string representations of bindings into HTML strings. This allows human-readable HTML content to be generated from within a SPARQL query. (This is a Triple-specific feature.)

Notice that the HTML string is itself semantically described as a literal with datatype IRI rdf:HTML.

You can press the "Gallery" result set view in order to display a gallery view of the returned HTML widgets. The gallery widget requires that the HTML strings are bound to variable ?widget.

The number of rows that is returned can be changed with the limit result set modifier. In this query it is set to 250 results; in this case: 250 Pokémon widgets.

Result set modifiers: offset

It is possible to skip a specific number of rows in the result set table. This is done with the offset keyword.

In this query the first 250 rows are skipped, so rows 26 through 275 are displayed.

A graph pattern consists of one or more consecutive Triple Patterns.

This select query consists of one Triple Pattern.

This query has a Graph Pattern that consists of 2 Triple Patterns.

Notice how the Triple Patterns are connect by a shared variable (?pokemon).

This query contains a Graph Pattern that consists of four Triple Patterns.

Notice how all Triple Patterns share the same subject term (?pokemon) and how the last two Triple Patterns share the same predicate term (rdfs:label).

This query is similar to query 2-3, but the subject term is not repeated.

When consecutive Triple Patterns have the same subject term, the subject term of the next Triple Pattern can be skipped if the previous Triple Pattern ends in a semi-colon (;) instead of a dot (.).

Some properties can have multiple values for the same subject. For example, one Pokémon (?pokemon) has multiple values for the name property (pokemon:name) in different languages.

Notice that when a Triple Pattern ends with the comma character (,) the next Triple Pattern implicitly has the same subject and predicate terms as the previous Triple Pattern. (If the number of object terms is small we are used to placing them on the same physical line, as in this query.)

The filter expression puts additional constraints on which results are returned. In the query, the filter states that the two names must be different. Difference/non-identity is specified with the != operator.

Notice that use of != means that for every pair 〈A,B〉 the pair 〈B,A〉 is also included. Use the smaller than (<) or larger than (>) operator instead in order to exclude such symmetric name pairs in the result set.

This query uses the lang(…) function in order to return only those result rows in which one name is in Japanese (ja-ja) and one name is in US English (en-us).

The fact that both constraints must be satisfied is expressed by the Boolean conjunction operator (&&).

This query has a Graph Pattern that consists of five Triple Patterns.

This query is similar to query 2-7, but uses Property Path notation (forward slash, /) in order to skip a node that is not used in the result set.

It is common practice to hide such hidden variables using Property Path notation.

Every variable in a SPARQL query can be replaced by an RDF name (an IRI or literal). Replacing a variable with an RDF name makes the query more specific, i.e., results in a smaller result set.

This query is similar to query 2-8, but the ?typeName variable is replaced by the literal "Dragon Type" so that only dragon type Pokémon are returned.

This query returns the 25 Pokémon with the lowest happiness value.

This query is similar to query 2-10, but inverts the sort with the descending (desc) keyword, resulting in the 25 most happy Pokémon.

The result set of this query consists of 'blocks' of values (names in this case) that appear with the same Pokémon.

Aggregation allows functions to be applied to these 'blocks' of values, resulting in one single value per grouping element.

The grouping element can consist of one or more variables.

Aggregation: count

This query applies the count function to the blocks of names that appear with Pokémon.

This query applies the string concatenation function to the blocks of aggregated values.

Notice that the projection variables are calculated in sequence, so that later projection variables can make use of earlier ones.

This query retrieved one geometric shape and label. Click on the point geometry in order to bring up the label.

The query uses a service clause to query the endpoint of the Dutch Cadastre (Kadaster).