This query accepts a place URI and returns events that took place there. The goal is both to do something that Arches currently cannot, and also to provide users with some guidance about how events relate to locations in the data model.

Introduction #

There are certain limits to Arches, as currently presented. One of them is in relating places and events—at least in certain ways. In this entry, we do so, focusing on a query that begins with a place, returning all auction events that took place there. The query also returns a more exact location (street address, etc.), if it exists.

This ought to be helpful to anyone who ever wondered, for example, what auction events took place in London (or Paris, or New York City)? A major reason this is hard, as the data is currently constructed on GPI’s side, is because very few events are explicitly tagged as taking place in London (or the relevant metropolis in question). Rather, events are connected to more specific resources representing auction houses, addresses, and social establishments. These sub-locations themselves have further information on their own location, connecting them to cities through the P89_falls_within path. This is how we get from super-location (for lack of a better word, meaning in this case “city”) to provenance event. You can see how this works in Line 4 (see below).

Query #

1. Locations to Events #

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT * WHERE {
  ?location crm:P89_falls_within <https://data.getty.edu/provenance/328a2a56-2ccb-3ab1-96ea-28c25e07afe8> .
  ?location rdfs:label ?location_label .
  ?activity crm:P7_took_place_at ?location .
  ?activity rdfs:label ?activity_label .
  ?activity a crm:E7_Activity .
  ?activity crm:P2_has_type <http://vocab.getty.edu/aat/300054751> .
} LIMIT 1000

2. Reverse: Events to Locations #

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT * WHERE {
  ?provenance_activity a crm:E7_Activity .
  ?provenance_activity crm:P2_has_type <http://vocab.getty.edu/aat/300054751> .
  ?provenance_activity crm:P2_has_type ?type .
  ?provenance_activity crm:P7_took_place_at ?location  .
  ?location crm:P89_falls_within ?super_location   .
  OPTIONAL { ?super_location crm:P168_place_is_defined_by ?super_geoloc_object } .
  ?type rdfs:label ?type_label .
  ?provenance_activity rdfs:label ?provenance_activity_label .
  ?location rdfs:label ?location_label .
} LIMIT 1000

Commentary #

• Line 4: We have to begin by using the wobble method to get from a Place A resource (the “super location,” as we termed it, above)—in this case London—to Place B, a more specific sub-location, which is geographically contained within Place A. The reason for this is that events, as they were digitized, relate to hyper-specific places (e.g., auction houses, specific buildings, street addresses—often quite heterogeneous). This is an artifact of how the GPI coded these events originally, with this link between geographic information and provenance activity surviving the ETL process (i.e., the move from STAR to Arches/LOD). During ETL, those sub-places were then themselves reconciled with more general (and generally, more useful) geographic information—e.g., cities. For this reason, the user must jump across graphs to get to the information they want. The user can insert their own city resource here.
• Line 6: Having gone from a super-location (i.e., London) to a provenance activity, we are now able to link that location to a more specific sub-location