talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsBehavior 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?
Patrick,
If a nonpreferred term is replaced in the authority record so that the
term used in Person no longer exists in the authority record, is this a
problem for searching, reporting, etc.?
It seems that it should be replaced because otherwise why wouldn't you
just add a new nonpreferred term and keep the old as well? But I see how
this might be a problem with former storage locations in particular.
What happens if a nonpreferred term is made the preferred term, and the
formerly preferred term becomes nonpreferred: It seems that the preferred
ones should be changed to the new preferred term and the nonpreferred
should stay as is. Is that the case? What about preferred for lang? Does
it have any effect?
Susan
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?
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Hi Patrick,
I've sent a note to UCJEPS asking for their input, but I know they want taxonomic names to change (Opinion 1) automatically and expect to do that frequently. Configuration per authority would be great. I agree with Susan that users should add a new non-preferred term if they don't want existing display names to change.
Thanks,
Chris
On Jun 12, 2012, at 9:44 AM, Patrick Schmitz wrote:
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?
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
It is still tricky to know what to do with a preferred term that becomes
nonpreferred. Did the person mean to select the preferred term whatever it
is or did they want that specific term? That might be configurable by
museum.
Susan
Hi Patrick,
I've sent a note to UCJEPS asking for their input, but I know they want
taxonomic names to change (Opinion 1) automatically and expect to do that
frequently. Configuration per authority would be great. I agree with
Susan that users should add a new non-preferred term if they don't want
existing display names to change.
Thanks,
Chris
On Jun 12, 2012, at 9:44 AM, Patrick Schmitz wrote:
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?
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org