fragment_downloaded_cb({"url":"tutorial.html#queries-and-variables","fragment":"Queries and variables\nOf course, the deal of a query language is being able to obtain the\nstored data, not just testing whether data exists.\nThe SELECT query syntax is used for that, and variables are denoted with\na ? prefix (or $, although that is less widely used), variables act\nas \"placeholders\" where any data will match and be available to the resultset\nor within the query as that variable name.\nThese variables can be set anywhere as the subject, predicate or object of\na triple. For example, the following query could be considered the opposite\nto the simple boolean testing the that ASK provides:\nWhat does this query do? it provides a triple with 3 variables, that\nevery known triple in the database will match. The * is a shortcut\nfor all queried variables, the query could also be expressed as:\nHowever, querying for all known data is most often hardly useful, this\ngot unwieldly soon! Luckily, that is not necessarily the case, the\nvariables may be used anywhere in the triple definition, with other\ntriple elements consisting of literals you want to match for, e.g.:\nAnd also combinations of them, for example:\nAnd of course, the graph pattern can hold more complex triple\ndefinitions, that will be matched as a whole across the stored\ndata. for example:\nStop a bit to think on the graph pattern expressed in the last query:\n\nThis pattern on one hand consists of specified data (eg. ?song must be\na nmm:MusicPiece, it must have a nmm:musicAlbum and a nie:title,\n?album must have a nie:title, which must all apply for a match\nto happen.\nOn the other hand, the graph pattern contains a number of variables,\nsome only used internally in the graph pattern, as a temporary\nvariable of sorts (?album, in order to express the relation between\n?song and its album title), while other variables are requested in the\nresult set.\n"});