There are two types of search interfaces in the DAAP. A keyword search interface, which you can interact with via the input box in the top right corner of the database interface. And a second advanced search interface, which uses the linked data structure of Wikibase to search for more complex data relations. This latter interface uses a query language called SPARQL (pronounced “sparkle”). The tutorial below outlines a sample workflow with this interface which does not require coding skills.
Start by accessing the search query interface to the DAAP here.
This interface is based on the public query interface provided by Wikidata. Our instance is called DockerWikibaseQueryService, because it is an access point to the DAAP’s private Wikibase instead of the public Wikidata database. This tutorial will guide you through using the “Query Helper” interface (highlighted in the image below), which is a graphic user interface. If you don’t see the “Query Helper” interface immediately, click the “info” icon in the top left corner below the wiki logo image.
There are further tutorials suggested in the end of this page, which you can follow for instructions on more advanced use including writing your own SPARQL queries from scratch.
Next step is to select what to query for. To be able to work with the query service efficiently, you need to be moderately well acquainted with the way data is structured in the DAAP. To do this you can always refer to the main data model spreadsheet here, or just look at some example items in the database. For this tutorial we will use the case study of artworks by artist Carolee Schneemann already added to the DAAP. You can read more about the case study here.
Let’s examine an artwork record for one of these works, e.g. Earth Ship.
We can see that the artwork is linked to the artist via the property “creators/ contributors”. So we’ll start our search in the query service by looking for all works which are linked to artist Carolee Schneeman via property “creators/ contributors”.
The Query Helper interface works like a filter. If you click on the Filter button and start typing the artist name, in this case – Carolee Schneeman, it should pop up as an auto-suggestion while you’re typing.
The query helper will even suggest an appropriate property to use with this item. In this case, the property “creators/ contributors” is exactly the one we want to use, so we can leave it as is.
Sometimes the autosuggestion may be wrong, in which case you need to start typing into the property field and choose the correct property.
Once you have created at least one filter, you can “run” your query to see the results. Some results may appear even while you’re typing in the filter values, but you won’t get complete results until you’ve hit the big blue “play” button on the left side of the Helper interface.
Once you click the button, you will get the complete set of results in the space below the Helper interface. At this point in time, there appear to be 6 artworks associated with this artist in the DAAP.
Next you may want to “show” some additional attributes for these artworks. You can do that by using the “show” button in the helper interface. For this particular query let’s use publication locations and other contributors. You will note that the way the “show” button operates is not to filter down, but rather to add optional attributes to the artworks. This means the total number of artworks in the query remains 6, but for some of these you start to see additional data where applicable.
To see the additional attributes, you need to choose the correct properties from the “Show” option. You can consult an example artwork page or the general data model sheet once again to get the property titles if you need to. In this case, the properties are: “place of publication” and “creators/ contributors”.
Once again you need to press the “run” button to see your updated query results.
You may also notice that the query returns 12 results now. This is because works which have more than one additional contributor (besides the artist Carolee Schneemann) appear as separate results in the table view.
This is not a problem from a data management perspective, but if you don’t find the table view very useful, you can experiment with alternative ways of visualising the data results. For example in this case, you can also try the “graph view” accessible via a drop-down menu.
Once you select the alternate view, the results are automatically reloaded in the correct view. Different views suit different cases and different types of “query questions”. The more you use the query tools and experiment, the more you’ll discover what types of data are best displayed via specific visualisations.
Finally if you want to share this query with someone else, or save it for your own research, there are two options of getting links to the results. The link button in the Query helper interface creates a link to the editable query interface.
Whereas the link in the results part of the screen, will give you a link that opens to a full-screen visualisation of the query results and can be embedded elsewhere on the web, too. This is how we produced the link to the visualisation accessible from the case study page for Schneeman’s works.
You can also download your results in a number of different formats to suit your needs. A CSV file is a convenient way to get data in a standard spreadsheet format.
There are many different types of queries you can run and discover new data in the database. Here are some examples that can give you an idea of what types of materials you can query for.
Feel free to experiment by amending the filter or show values in these and see what alternative results you can get:
There are many more sophisticated ways of using the Query interface, particularly if you know how to edit the SPARQL code manually.
See some of these more advanced tutorial materials prepared by Wikidata:
We will aim to add more complex SPARQL tutorials to the DAAP site as well, as the database develops further as a community resource.