talk@lists.collectionspace.org

WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org

View all threads

Preferred and non-preferred authority terms

CH
Chris Hoffman
Tue, Feb 28, 2012 4:10 AM

Hello CSpace colleagues,

On the version 2.4 roadmap there is identified work related to handling preferred and non-preferred terms in authorities.
http://wiki.collectionspace.org/display/collectionspace/Release+2.4

In talking with Patrick Schmitz and Jan Eklund, we want to propose some refactoring to authorities to make it easier to support preferred and non-preferred terms.  Some of these decisions would shape how we start work on  the Concept authority that is being developed by UCB as a contribution to the core.  For the following authorities this will involve modifying some of the fields and adding others to the repeating term block.  Deployments migrating data will need to consider the effects of changed field names.

  • Organization
  • Place
  • Concept

For some other authorities however we would need to change the non-repeating term block to a repeating one.  Deployments migrating data will need to consider how to change their scripts to move names into a nested schema.

  • Person
  • Storage Location
  • Taxonomy

Each of these would then share a common repeatable term block made up of the following fields

  • displayName
  • shortDisplayName
  • source
  • sourceTermID
  • sourcePage
  • termLanguage
  • preferred
  • preferredForLang
  • termType
  • qualifier
    Note that these fields will also help with localization.

These would then support specifying preferred and non-preferred terms on a single term record.  The behaviors permitted in the UI are still to be defined, but the driving use case here was that in some cases we need to allow non-preferred terms to be able to type in a non-preferred term and have the term-completion widget show us the preferred term.  Right now, only the primary name on a term are included in the authority-tied fields.

Implementers: What do you think about this approach?  It will create some work for those of us who have already written database migration scripts, and it might create work for people who have done some customizations to these authorities.  We'll send out more information as the potential impacts become more clear.

Thanks for your help,
Chris

Hello CSpace colleagues, On the version 2.4 roadmap there is identified work related to handling preferred and non-preferred terms in authorities. http://wiki.collectionspace.org/display/collectionspace/Release+2.4 In talking with Patrick Schmitz and Jan Eklund, we want to propose some refactoring to authorities to make it easier to support preferred and non-preferred terms. Some of these decisions would shape how we start work on the Concept authority that is being developed by UCB as a contribution to the core. For the following authorities this will involve modifying some of the fields and adding others to the repeating term block. Deployments migrating data will need to consider the effects of changed field names. - Organization - Place - Concept For some other authorities however we would need to change the non-repeating term block to a repeating one. Deployments migrating data will need to consider how to change their scripts to move names into a nested schema. - Person - Storage Location - Taxonomy Each of these would then share a common repeatable term block made up of the following fields - displayName - shortDisplayName - source - sourceTermID - sourcePage - termLanguage - preferred - preferredForLang - termType - qualifier Note that these fields will also help with localization. These would then support specifying preferred and non-preferred terms on a single term record. The behaviors permitted in the UI are still to be defined, but the driving use case here was that in some cases we need to allow non-preferred terms to be able to type in a non-preferred term and have the term-completion widget show us the preferred term. Right now, only the primary name on a term are included in the authority-tied fields. Implementers: What do you think about this approach? It will create some work for those of us who have already written database migration scripts, and it might create work for people who have done some customizations to these authorities. We'll send out more information as the potential impacts become more clear. Thanks for your help, Chris