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