Repeat Link Target
By Miller Prosser, April 2013
Create alternate views
“In contrast to replication, which creates new database items, you can copy an item by repeating the same item in a different hierarchical location. A given item may thus appear in more than one hierarchy or in more than one location within the same hierarchy. This is a useful feature because it allows the creation of overlapping hierarchies that present alternative views of the same information by organizing the same items in different configurations.” (Schloen and Schloen 2012, 52)
Archaeological Project Example:
There may be many reasons why a project would want to instantiate the same item in multiple hierarchies. In this example, we will instantiate a registered object (an Axe head) in two hierarchies. The first hierarchy will represent the find spot in its grid, square, locus context. The following arrangement indicates that this specific object was discovered in Grid 21, Square 12, Locus 1. Any other objects found here would appear in this context also.
The second hierarchy will represent its context as analyzed by ancient city quarters. So, instead of conceptualizing the archaeological site only according to excavation grids, we can think of the site as an ancient city with meaningful divisions and subdivisions. Notice that the hierarchy called “City quarters” appears in the Locations & objects hierarchy at the same level as the “Excavation contexts” hierarchy. Because the “City quarters” are a different conceptualization of the site, this hierarchy does not belong as a subordinate of the “Excavation contexts” hierarchy.
The Axe head probably starts out as an object in its excavation context. But, we would also like to place it in the context of the ancient city. To do so, we need to copy the object to the second location. To create this copy, we navigate to the destination hierarchy in the navigation pane. Then we navigate to the source in the reference pane. The hierarchy folder of the destination and the source need to be locked. With the destination selected in the navigation pane and the Axe head selected in the reference pane, we click the “Repeat Link Target” button. In the end, the Axe head appears in both contexts.
By viewing the context of the Axe head, one can see a list of all of the contexts where the item occurs.
Philological Project Example:
In this example, we discuss the value of creating an unbound copy of a series of discourse units (in this case a series of words) in multiple hierarchies. In the first Discourse Hierarchy, the words exist as they did when they were imported into the project. This hierarchy serves as a source list of all the words in the project in order without any additional analysis. A second hierarchy could represent a grammatical analysis of the clauses in the text. A third hierarchy could represent an arrangement of the discourse units into epistolographic sections. By taking this approach, the projects avoids the problem of creating new database items for the words when they are arranged in new discourse analyses. The obvious benefit is that any change made to a word in one discourse hierarchy propagates to the other contexts where the word exists.
Resource Project Example:
In this example, we consider the value of instantiating images in various hierarchies. The first instance exists in a hierarchy organized by tablet number. This allows project users to browse the hierarchy by object number and find all photos by object. The second hierarchy represent a hand-picked selection of photographs of important objects, like all ivory, or all cuneiform tablets. This provides the ivory expert with easy access to a subset.
Copies are linked because they are the same item
“…this copy is not a new item but just another manifestation of an existing item that was originally inserted elsewhere. Any changes to the names, description, properties, links, or notes of the item, in any place where it appears, will be shown automatically in every other place where that item has been repeated.”(Schloen and Schloen 2012, 53)
Changing the name of the Axe head in any of the locations automatically changes its name in all the locations. Why? Because the many instances of the Axe head are all views of the same database item. When we created multiple instantiations in the new hierarchies, we did not create new database items. We simply added the same Axe head to other places. So, changing properties of the item in one place—any place—changes them in all places.
By adding “ceremonial” to the name of the Axe head in one context, we are adding it in every context because it is the same data item in all these locations.
The result:
Copying from Other Projects
“Furthermore, you can borrow items from other OCHRE projects by repeating their items within your own project’s categories.”(Schloen and Schloen 2012, 52)
There is a slight nuance to this feature when a project borrows items from another project. In this case, the contexts of the copied item still show in the context slightly greyed out in the project that copied (or “borrowed”) the item. In this case, the project that copied the item cannot change the item at all. They can delete the item, or add other items before and after it, but they cannot change the name, abbreviation, or properties of the borrowed item. The principle is that only the owner of the database item can make changes. This is why a project can create multiple copies of an item in its own project and make changes to any of the copies. They own the item! Beware of borrowing too much from other projects because if the original project decides to change the name of a borrowed item, any project that borrowed the item will see this change automatically. Consider this carefully when you decide what to borrow from another project.
Schloen, J. David, and Sandra R. Schloen. 2012. OCHRE: An Online Cultural and Historical Research Environment. Winona Lake, IN: Eisenbrauns.