Difference between revisions of "History Tracking"

From CollectiveAccess Documentation
Jump to: navigation, search
(Configuration)
(Configuration)
 
Line 73: Line 73:
 
||name||The name for the policy that will appear in the user interface||Custom and defined by the user
 
||name||The name for the policy that will appear in the user interface||Custom and defined by the user
 
|-
 
|-
||table||The database area for which this policy applies. What is being tracked?||A primary table as defined[[Primary_Types|here]].
+
||table||The database area for which this policy applies. What is being tracked?||A primary table as defined [[Primary_Types|here]].
 
|-
 
|-
 
||mode||Defines if the policy is a direct relationship between the table target and one or more other primary tables or if the history includes an indirect relationship through the movements table||workflow or movements
 
||mode||Defines if the policy is a direct relationship between the table target and one or more other primary tables or if the history includes an indirect relationship through the movements table||workflow or movements

Latest revision as of 22:04, 18 March 2019

Updated for v1.76

DOCUMENTATION IN PROGRESS. PLEASE CHECK BACK LATER

History Tracking is Location Tracking 2.0.

We've expanded the Location tracking feature to handle more nuanced policies for managing chronological relationships between an expanded set of record types in the database model.

Overview

Prior to version 1.76 we supported three ways for collection managers to determine the current location and location history of objects.

  1. Direct object-location references. provided a simple history of objects' storage locations over time.
  2. Movement-based location tracking recorded detailed information about how one or more objects are transferred between locations, in addition to the location history. This option was intended for collections where documenting chain of custody, insurance and packing are critical.
  3. Workflow-based location tracking was designed for institutions with a robust notion of location and expanded upon either of the preceding two options. In contrast with other methods, which all record relationships between objects and locations (with or without movements), workflow-based location tracking took into consideration several types of records to determine the current location of an object, for example storage locations, exhibitions, loans, etc.

Over time it became apparent that other records types required a similar type of description that captured a chain of custody or connections over time. For example, many users need to catalog a chronological ownership history between objects and entities, which was not possible through our original location tracking model. In this use case it's not sufficient to simply know who owned the object when. Rather, it's important to be able to search and browse not only the "current" collection in which the object resides but also to retrieve all objects "currently" in collections meeting certain criteria. To support these expanded needs we redesigned Location Tracking, creating a more general History Tracking feature.

The core of the History Tracking configuration are the tracking policies. This allows a record to have multiple chronologies happening in parallel. Here are some examples of simultaneous policies an object record might have:

  1. Provenance and Exhibition History - For a given object an ownership history is recorded. In a separate track a chronology of exhibitions is captured. With the correct metadata configuration it's possible to search for all objects currently on view in exhibitions in Europe and all objects currently owned by public museums.

Configuration

Primary configuration is done in app.conf through the history_tracking_policies directive. Each policy is given a custom name which allows it be defined as default, references in search indexing and display configurations. Several elements of the configuration accept only set values, such as table which accepts a CollectiveAccess primary table and mode which can be set to either workflow or movements. For a full list of requirements, see the table below the example configuration.

# Track two histories: a direct object-storage location chronology and an ownership 
# history that links objects to provenance records cataloged in the occurrence table.

history_tracking_policies = {
    defaults = { 
        ca_objects = current_location
    },
    policies = {
        current_location = {
            name = _(Current location),
            table = ca_objects,
            mode = workflow, 
            elements = {
                ca_storage_locations = {
                    __default__ = {
                        restrictToRelationshipTypes = [related], 
                        setInterstitialElementsOnAdd = [effective_date],
                        template = <l>^ca_storage_locations.hierarchy.preferred_labels.name%delimiter=_➜_</l>,
                        trackingRelationshipType = related
                    }
                }
            }
        },
        provenance = {
            name = _(Provenance),
            table = ca_objects,
            mode = workflow, 
            elements = {
                ca_occurrences = {
                    provenance = { 
                        date = ca_objects_x_occurrences.effective_date,
                        setInterstitialElementsOnAdd = [effective_date],
                        color = F78B8B,
                        template = "<l>^ca_occurrences.preferred_labels</l><ifdef code='ca_occurrences.confidential_provenance'><br>
                        Confidential Name: ^ca_occurrences.confidential_provenance</ifdef>"
                    }
                }
            }
        }
    }
}
Configuration Name Description Options
name The name for the policy that will appear in the user interface Custom and defined by the user
table The database area for which this policy applies. What is being tracked? A primary table as defined here.
mode Defines if the policy is a direct relationship between the table target and one or more other primary tables or if the history includes an indirect relationship through the movements table workflow or movements

DOCUMENTATION IN PROGRESS. PLEASE CHECK BACK LATER

update_sphinx

Namespaces

Variants
Actions
Navigation
Tools
User
Personal tools