Overview

We will first determine the Wikidata identifiers for all the subject and object nodes that we wish to retrieve. It is straightforward to do that using the traversal illustrated in 2.9(a). Through the same process, we will identify the property identifiers. We will formulate a query to match the exact edges we are interested in. Finally, we will enhance the query to print the results in a user friendly manner with the labels of each identifier in the result.

Determine the Wikidata identifiers for each subject node

Let us first determine the identifiers for each node we are interested in retrieving. The table below lists the identifiers for the four nodes used in this query. The Wikidata node identifiers are referred to as QIDs.

Determine the Wikidata identifiers for each property

Let us next determine the Wikidata identifiers for each property we are interested in retrieving. As with nodes, we can locate a property's identifier as we were traversing the graph in 2.9(a). Unlike node identifiers, which begin with the letter Q, property identifiers begin with the letter P. These identifiers are commonly referred to as Property IDs (PIDs).

The table below lists the three properties used in the query and their corresponding Wikidata Property IDs.

Determine the Wikidata identifiers for each object node

To retrieve exactly the subgraph shown in the figure, we must determine the Wikidata identifiers (QIDs) for each object node that appears in the figure. The table below lists these identifiers.

Formulate the query to retrieve the edges of interest

Before starting to write the query in SPARQL, it is helpful to review the documentation on Wikidata Query Service.

We are now ready to formulate the SPARQL query. The query uses the Wikidata identifiers collected in the previous steps to retrieve exactly the edges shown in Figure 2 of Chapter 1. The three VALUES clauses specify the candidate subject nodes, properties, and object nodes, respectively. The triple pattern ?s ?p ?o then matches only those triples in the Wikidata graph that satisfy all three constraints.

SELECT ?s ?p ?o
WHERE {
  {
    VALUES (?s ?p ?o) {
      (wd:Q30      wdt:P361 wd:Q49)
      (wd:Q9125    wdt:P190 wd:Q488134)
      (wd:Q9125    wdt:P361 wd:Q690149)
      (wd:Q488134  wdt:P17  wd:Q30)
    }

    ?s ?p ?o .
  }
UNION
{
  VALUES (?s ?p ?o) {
    (wd:Q690149 wdt:P361 wd:Q39)
  }

  ?s wdt:P361+ ?o .
    }
    }

Explanation

This query retrieves the five relationships shown in Figure 2. The query consists of two branches combined using the UNION operator.

The first branch retrieves four relationships that are stored explicitly in Wikidata. The VALUES clause specifies the desired subject, property, and object combinations, and the triple pattern ?s ?p ?o . matches those triples directly.

The second branch retrieves the relationship between the Zurich metropolitan area and Switzerland. Unlike the other four relationships, this relationship is not stored as a direct triple in Wikidata. Instead, the query follows one or more part of relationships using the property path wdt:P361+. The + operator means "one or more occurrences of the part of property." Consequently, the query succeeds even though there is no direct triple connecting the Zurich metropolitan area to Switzerland.

The VALUES clause in the second branch binds ?p to wdt:P361 so that both branches return the same variables (?s, ?p, and ?o).

Finally, the UNION operator combines the results from the two branches into a single result set containing all five relationships shown in Figure 2.

The query returns the following triples. Notice that the results are displayed using Wikidata identifiers rather than human-readable names. In the next step, we will revise the query so that it returns labels instead of identifiers.

The query returns the Wikidata identifiers of the matching subjects, properties, and objects. In the next step, we will enhance the query so that it displays human-readable labels instead of identifiers.

Revise the query to return human-readable labels

Although the query in the previous step retrieved the desired edges, the results are difficult to interpret because they are displayed using Wikidata identifiers. We can make the results more readable by modifying the query to return the English labels associated with each subject, property, and object.

The revised query introduces the SERVICE wikibase:label block, which retrieves the English labels corresponding to the Wikidata identifiers. The query also introduces the variable ?pEntity, which binds each direct property (for example, wdt:P17) to its corresponding Wikidata property entity (wd:P17). This allows the query to retrieve the label of each property in the same way that it retrieves the labels of subjects and objects.

SELECT ?s ?sLabel ?pLabel ?o ?oLabel
WHERE {
  {
    VALUES (?s ?p ?pEntity ?o) {
      (wd:Q30      wdt:P361 wd:P361 wd:Q49)
      (wd:Q9125    wdt:P190 wd:P190 wd:Q488134)
      (wd:Q9125    wdt:P361 wd:P361 wd:Q690149)
      (wd:Q488134  wdt:P17  wd:P17  wd:Q30)
    }

    ?s ?p ?o .
  }

  UNION

  {
    VALUES (?s ?p ?pEntity ?o) {
      (wd:Q690149 wdt:P361 wd:P361 wd:Q39)
    }

    ?s wdt:P361+ ?o .
  }

  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en".
  }
}

The wikibase:label service automatically binds a variable named ?xLabel to the human-readable label of the entity stored in ?x. For example, ?sLabel, ?pEntityLabel, and ?oLabel contain the labels of the entities bound to ?s, ?pEntity, and ?o, respectively. The names ?sLabel and ?oLabel are therefore not declared explicitly in the query.

Executing the revised query produces the same six triples as before, but the results are now displayed using human-readable labels instead of Wikidata identifiers, making them much easier to understand.

The revised query returns the same six triples as before, but it also retrieves the English labels for each subject, property, and object. The results are now much easier to interpret.

The first query retrieved the correct graph structure but displayed the results using Wikidata identifiers. The revised query retrieves the same graph while also obtaining English labels for each identifier, making the output much easier for people to read. This separation between querying the graph and presenting the results is a common pattern in SPARQL applications.