Thanks Perian - It sounds like you are arguing for configured behavior per authority type. In your use-case for Storage-Location I assume you are talking about references to StorageLocation authority items in a Movement/Location record. This is an interesting counter-example to option 2 behavior, especially if the Movement record is locked. Am copying the talk list for further discussion. There is currently no notification, but there users can see the records that use an item. So when you are editing the StorageLocation item, the list of records that reference it is shown in the "Used-By" list on the right. This is a cue to what will happen if you change the terms. Patrick _____ From: Perian Sully [mailto:psully@bpoc.org] Sent: Tuesday, June 12, 2012 10:04 AM To: Patrick Schmitz Subject: RE: [Talk] Behavior when changing authority terms Hi Patrick: Personally, it seems to me as if the behavior should depend on the type of list. For Persons, Orgs, and Storage-Locations, the preferred term should always update automatically (Option 2), but for less-strict lists (say, transliterations, folksonomies, materials, etc.) and those that change over time (Place), it would follow Option 1. Per your question: if the Option 2 items are changed, especially with regards to Storage-Locations, using a "preferred term" won't suffice, since the Location should be static. Shouldn't there be a notification displaying where the existing terms currently exist and to the correct term such items should be assigned? ~ Perian Sully | Project Manager: Digital Asset Management & Online Access BALBOA PARK ONLINE COLLABORATIVE From: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Patrick Schmitz Sent: Tuesday, June 12, 2012 9:45 AM To: 'CollectionSpace Talk List' Subject: [Talk] Behavior when changing authority terms I have heard some divergent opinions of how one aspect of CollectionSpace should work, and am soliciting additional input on how the system should behave when a user edits the terms defined for an Authority item (a Person, Place, Organization, Taxon, etc.). Please let me know how your organization expects this to work. We need to get sufficient consensus to address this in v2.7. Thanks - Patrick _____ Scenario: You have defined a Person "Joe Schmoe" (or some other Authority item). You have used this by reference in various records (e.g., as Depositor on an Intake, etc.). One of your users now edits the Person, making a change to the displayName for one or more terms (preferred and/or non-preferred). E.g., the record representing "Joe Schmoe" was edited, changing the displayName from "Joe Schmoe" to "Joseph Schmo". Background: The system stores a copy of term displayName with the record that references it, to optimize various functions. So Intakes where Joe was the depositor include the displayName string "Joe Schmoe". Previous behavior (i.e., before 2.4, so before we added support for non-preferred terms): System finds all references to the term, and updates the displayName in the records, so that the references reflect the changed displayName. Since there was only one possible displayName for each Person/Org/Place/etc., the logic was straight-forward.. Current behavior (as of 2.4 when we added support for non-preferred terms): If (and only if) the preferred term has changed, system finds all references to the preferred term, and updates the displayName in the records. If a non-preferred term changed, the system does not update the reference. Some consider this behavior correct, and some consider it a bug. Question: What should the desired behavior be? Opinion 1 (respect-des-fonds position): The references represent metadata associated with original data in the records, and should not be changed. Appropriate usage (end-user practice) would be never to change or delete a term, but rather only to add new (possibly non-preferred) terms that correct misspellings, etc. Thus, no reference can ever be "out-of-date", and the system need do nothing. Opinion 2 (normalized model position): The references in the records are just efficiency mechanisms, and the authority items define the proper displayNames for the items. If the authority items change, the system should do what ever is needed to reflect a properly normalized model. Which model sounds right your museum? * How would you like this to work? * We've been assuming a largely automatic sequence, without user-intervention, since this happens on the back end. Do we really need some UI to work through the cases? * (Or,) Can we just add some configuration to specify the behavior for each museum? * Do you want different authority types to work differently? E.g., Person, Org, and Place follow option 1, but Storage-Location and Taxonomy follow option 2? If you choose Option 2, we have an additional question: There is an issue with Option 2: If the user deletes a non-preferred term (NPT) for which there are existing references, the system has to assume that the right thing to do is to update existing references to that NPT, to be references to the associated preferred term. Similarly, if the user changes one term in a list of preferred and non-preferred terms, the general case of determining the user's intent is difficult; CSpace would take a simple approach: any reference that is no longer valid (i.e., for which the displayName is not found in the updated list of terms), will be set to the current preferred term for that authority item. Our question: Is this approach sufficient?