Displaying Units

From CollectiveAccess Documentation
Revision as of 14:17, 8 November 2013 by Julia (talk | contribs) (Hierarchical relationships)
Jump to: navigation, search

Repeating containers

Hierarchical relationships

The <unit> tag allows users to organize and display metadata for hierarchically related records. For example, you might have a hierarchy within the Collections table, wherein one parent collection houses smaller child collections. Without the <unit> tag, you would only be able to display the preferred label of each child, and you wouldn't be able to specify delimiters such as line breaks. With the <unit> tag, however, you can break the child records up into discrete chunks, and you can include additional metadata about each. If you want to display child records along with their idno's, for example, you could do this:

<unit relativeTo="ca_collections.children">^ca_collections.preferred_labels, ^ca_collections.idno</unit>

In which "relativeTo" specifies the table in question and asks the display to find child records. Once the "relativeTo" frame has been set, however, you can simply put your paths in terms of the collections table, wherein the child records live. If you were to continue including "children," (i.e. ca_collections.children.preferred_labels) you would essentially be looking for child records within child records. To use this template in the opposite direction, to display the immediate parent of the record at hand, you would simply format it as <unit relativeTo="ca_collections.parent">. To display all parents, you can format the template with respect to the entire hierarchy: <unit relativeTo="ca_collections.hierarchy">. If you are dealing with multiple records, either as children or as "hierarchy," you'll want to enclose the entire template within a <unit>, so that each record's metadata can be displayed in an organized manner. For example,

<unit><unit relativeTo="ca_collections.children" delimiter="</br>">^ca_collections.preferred_labels, ^ca_collections.idno</unit></unit> 

would display records like this:

Mini Collection X, 100.1

Mini Collection Y, 100.2

instead of this:

Mini Collection X, Mini Collection Y, 100.1, 100.2

You can also nest additional layers of <unit> tags within the syntax discussed above by following the directions in the following section.

Indirect relationships

One use of the <unit> tag is to allow cataloguers to display metadata with some relative distance to the chosen record. We could call this the Six Degrees of Kevin Bacon for CollectiveAccess.

Let's say you're creating a Collection summary and you'd like to display metadata about Entities, but Entities aren't related directly to Collections. Perhaps they are related to Objects related to the Collection. Never fear! Just as Bruce Willis is 2 degrees away from Kevin Bacon (thanks to Brad Pitt, "The Hamster Factor" and the movie "8"), Entities are also 2 degrees away from Collections thanks to their relativity to Objects.

How does this look in practice? Here's a display template that is used on the object bundle (through the GUI) or object placement (in a profile). It pulls statement metadata from a container on each Entity record related to each Object.

<em><strong>^ca_objects.preferred_labels</strong></em><br>
^ca_entities.preferred_labels
<br><unit relativeTo="ca_entities" delimiter="<br><br/>">
^ca_entities.statement.statement_text<br/>^ca_entities.statement.statement_date<br/>^ca_entities.statement.statement_source
</unit>

The result is a list of artwork titles, artist names and their statements for the works in the collection. Note that in the Falling Water example entity John Smith has two repeats of the statements container:

RelativityDisplay.png

In addition to pulling the metadata (that has a "Bacon number" of 2) into the display, the unit tag is also the reason each container is correctly formatted. Without <unit> tags repeating containers would look like this:

Address Line 1 A; Address Line 1 B
Address Line 2 A; Address Line 2 B
Address Line 3 A; Address Line 3 B

rather than this:

Address Line 1 A
Address Line 2 A
Address Line 3 A

Address Line 1 B
Address Line 2 B
Address Line 3 B

Namespaces

Variants
Actions
Navigation
Tools
User
Personal tools