Hello again Colleagues, UCB would like to contribute an initial version of the Concept Authority for version 2.3 of CollectionSpace. In order to facilitate data migration for several UCB deployments, work has commenced on an initial version of the concept authority structure to be included in CSpace ver. 2.3. This initial version (see Concept Authority Requirements - UCB) will be basic, with support for one term per record, as is now the case in Person, Org, and Storage Location. Singular and plural word forms (e.g. "painting" and "paintings") would need to be added as separate term records, as will their equivalents in other languages (e.g. "peinture", "peintures", "pintura", "pinturas", etc.). Hierarchical relationships between broader and narrower terms will be supported. Basic support for Concepts include support for the default instance of the Concept Authority. It is possible that support for other instances of Concept and other authorities will be available in CSpace 2.3. Note: It is likely that the initial record editor UI for Concept will be very basic and not expose all fields in the schema. Initially we are focused on including Display Name, Short Display Name, Language, Term Type, and Term Qualifier. A Jira ticket for this contribution is available (CODE-3). A Wiki page is at http://wiki.collectionspace.org/display/collectionspace/Develop+initial+version+of+Concept+Authority A more robust version of the concept authority, planned for ver. 2.4, will provide support for the use of both preferred and non-preferred terms, and support for multilingual deployments. More information about this work will be shared soon. Please let us know if you have any questions or comments about this proposed contribution. Thanks, Chris

Hi Everyone, As part of the Concept Authority work for 2.3, we're proposing changing two fields on the Cataloging form to be fed from the new Concept Authority: Object Description Information / Content / Concept Object History and Association Information / Associations / Associated concept / Associated Concept These are currently free text fields, and converting them to be authority-controlled will effectively cause data loss, if you have data in those fields. Existing values would need to be converted to authority items. Implementors, do you currently have data in those fields? If so, we'll need to provide a migration path for your data. This might not get done in time for 2.3, in which case we would hold off on converting those cataloging fields until 2.4. Please respond if you have existing data in those fields! Also, please be aware that in the 2.4 release, we'll want to convert some additional fields to be controlled by the concept authority. These will include fields that refer to materials, activities, objects, concepts, cultures, and styles. I'll provide a complete list later on. Thanks, Ray On Mar 22, 2012, at 9:50 AM, Chris Hoffman wrote: > Hello again Colleagues, > UCB would like to contribute an initial version of the Concept Authority for version 2.3 of CollectionSpace. > > In order to facilitate data migration for several UCB deployments, work has commenced on an initial version of the concept authority structure to be included in CSpace ver. 2.3. This initial version (see Concept Authority Requirements - UCB) will be basic, with support for one term per record, as is now the case in Person, Org, and Storage Location. Singular and plural word forms (e.g. "painting" and "paintings") would need to be added as separate term records, as will their equivalents in other languages (e.g. "peinture", "peintures", "pintura", "pinturas", etc.). Hierarchical relationships between broader and narrower terms will be supported. Basic support for Concepts include support for the default instance of the Concept Authority. It is possible that support for other instances of Concept and other authorities will be available in CSpace 2.3. > > Note: It is likely that the initial record editor UI for Concept will be very basic and not expose all fields in the schema. Initially we are focused on including Display Name, Short Display Name, Language, Term Type, and Term Qualifier. > > A Jira ticket for this contribution is available (CODE-3). > > A Wiki page is at > http://wiki.collectionspace.org/display/collectionspace/Develop+initial+version+of+Concept+Authority > A more robust version of the concept authority, planned for ver. 2.4, will provide support for the use of both preferred and non-preferred terms, and support for multilingual deployments. More information about this work will be shared soon. > > Please let us know if you have any questions or comments about this proposed contribution. > > Thanks, > Chris > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Ray, Can't implementers choose whether these fields will use the concept authority or not? They may use a concept authority by default, but that can be changed in configuration, no? Since some people are talking about using multiple concept authorities (e.g., separate for materials and styles), are you proposing a Default Concept Authority to be attached to these fields by default? Susan > Hi Everyone, > As part of the Concept Authority work for 2.3, we're proposing changing > two fields on the Cataloging form to be fed from the new Concept > Authority: > > Object Description Information / Content / Concept > Object History and Association Information / Associations / Associated > concept / Associated Concept > > These are currently free text fields, and converting them to be > authority-controlled will effectively cause data loss, if you have data in > those fields. Existing values would need to be converted to authority > items. Implementors, do you currently have data in those fields? If so, > we'll need to provide a migration path for your data. This might not get > done in time for 2.3, in which case we would hold off on converting those > cataloging fields until 2.4. Please respond if you have existing data in > those fields! > > Also, please be aware that in the 2.4 release, we'll want to convert some > additional fields to be controlled by the concept authority. These will > include fields that refer to materials, activities, objects, concepts, > cultures, and styles. I'll provide a complete list later on. > > Thanks, > Ray > > > On Mar 22, 2012, at 9:50 AM, Chris Hoffman wrote: > >> Hello again Colleagues, >> UCB would like to contribute an initial version of the Concept Authority >> for version 2.3 of CollectionSpace. >> >> In order to facilitate data migration for several UCB deployments, work >> has commenced on an initial version of the concept authority structure >> to be included in CSpace ver. 2.3. This initial version (see Concept >> Authority Requirements - UCB) will be basic, with support for one term >> per record, as is now the case in Person, Org, and Storage Location. >> Singular and plural word forms (e.g. "painting" and "paintings") would >> need to be added as separate term records, as will their equivalents in >> other languages (e.g. "peinture", "peintures", "pintura", "pinturas", >> etc.). Hierarchical relationships between broader and narrower terms >> will be supported. Basic support for Concepts include support for the >> default instance of the Concept Authority. It is possible that support >> for other instances of Concept and other authorities will be available >> in CSpace 2.3. >> >> Note: It is likely that the initial record editor UI for Concept will be >> very basic and not expose all fields in the schema. Initially we are >> focused on including Display Name, Short Display Name, Language, Term >> Type, and Term Qualifier. >> >> A Jira ticket for this contribution is available (CODE-3). >> >> A Wiki page is at >> http://wiki.collectionspace.org/display/collectionspace/Develop+initial+version+of+Concept+Authority >> A more robust version of the concept authority, planned for ver. 2.4, >> will provide support for the use of both preferred and non-preferred >> terms, and support for multilingual deployments. More information about >> this work will be shared soon. >> >> Please let us know if you have any questions or comments about this >> proposed contribution. >> >> Thanks, >> Chris >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

Yes, implementors can choose if they want a particular field to be authority-controlled or not. I'm proposing changing the default configuration to use the authority, so implementors who want the fields to continue to be text will have to do a little additional configuration. Implementors who want the fields to use the authority, but who have existing text data that must be preserved, will have to do a migration step. For 2.3, I'm proposing attaching a Default Concept Authority to those two fields, by default. For 2.4, I'm proposing having a set of Concept Authority instances configured by default, e.g. Material, Activity, Style, etc., and attaching them to appropriate fields by default. Which instances and fields those are, is still up for discussion. Thanks, Ray On Mar 28, 2012, at 4:12 PM, sstone@socrates.berkeley.edu wrote: > Ray, > > Can't implementers choose whether these fields will use the concept > authority or not? > > They may use a concept authority by default, but that can be changed in > configuration, no? > > Since some people are talking about using multiple concept authorities > (e.g., separate for materials and styles), are you proposing a Default > Concept Authority to be attached to these fields by default? > > Susan > > >> Hi Everyone, >> As part of the Concept Authority work for 2.3, we're proposing changing >> two fields on the Cataloging form to be fed from the new Concept >> Authority: >> >> Object Description Information / Content / Concept >> Object History and Association Information / Associations / Associated >> concept / Associated Concept >> >> These are currently free text fields, and converting them to be >> authority-controlled will effectively cause data loss, if you have data in >> those fields. Existing values would need to be converted to authority >> items. Implementors, do you currently have data in those fields? If so, >> we'll need to provide a migration path for your data. This might not get >> done in time for 2.3, in which case we would hold off on converting those >> cataloging fields until 2.4. Please respond if you have existing data in >> those fields! >> >> Also, please be aware that in the 2.4 release, we'll want to convert some >> additional fields to be controlled by the concept authority. These will >> include fields that refer to materials, activities, objects, concepts, >> cultures, and styles. I'll provide a complete list later on. >> >> Thanks, >> Ray >> >> >> On Mar 22, 2012, at 9:50 AM, Chris Hoffman wrote: >> >>> Hello again Colleagues, >>> UCB would like to contribute an initial version of the Concept Authority >>> for version 2.3 of CollectionSpace. >>> >>> In order to facilitate data migration for several UCB deployments, work >>> has commenced on an initial version of the concept authority structure >>> to be included in CSpace ver. 2.3. This initial version (see Concept >>> Authority Requirements - UCB) will be basic, with support for one term >>> per record, as is now the case in Person, Org, and Storage Location. >>> Singular and plural word forms (e.g. "painting" and "paintings") would >>> need to be added as separate term records, as will their equivalents in >>> other languages (e.g. "peinture", "peintures", "pintura", "pinturas", >>> etc.). Hierarchical relationships between broader and narrower terms >>> will be supported. Basic support for Concepts include support for the >>> default instance of the Concept Authority. It is possible that support >>> for other instances of Concept and other authorities will be available >>> in CSpace 2.3. >>> >>> Note: It is likely that the initial record editor UI for Concept will be >>> very basic and not expose all fields in the schema. Initially we are >>> focused on including Display Name, Short Display Name, Language, Term >>> Type, and Term Qualifier. >>> >>> A Jira ticket for this contribution is available (CODE-3). >>> >>> A Wiki page is at >>> http://wiki.collectionspace.org/display/collectionspace/Develop+initial+version+of+Concept+Authority >>> A more robust version of the concept authority, planned for ver. 2.4, >>> will provide support for the use of both preferred and non-preferred >>> terms, and support for multilingual deployments. More information about >>> this work will be shared soon. >>> >>> Please let us know if you have any questions or comments about this >>> proposed contribution. >>> >>> Thanks, >>> Chris >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> > >

Any data PAHMA has in those fields is just practice data; we haven't yet migrated — and will not migrate — any data into those two fields.

Hi Ray, Any data PAHMA has in those fields is just practice data; we haven't yet migrated — and will not migrate — any data into those two fields. Michael On Mar 28, 2012, at 3:47 PM, Ray Lee wrote: > Hi Everyone, > As part of the Concept Authority work for 2.3, we're proposing changing two fields on the Cataloging form to be fed from the new Concept Authority: > > Object Description Information / Content / Concept > Object History and Association Information / Associations / Associated concept / Associated Concept > > These are currently free text fields, and converting them to be authority-controlled will effectively cause data loss, if you have data in those fields. Existing values would need to be converted to authority items. Implementors, do you currently have data in those fields? If so, we'll need to provide a migration path for your data. This might not get done in time for 2.3, in which case we would hold off on converting those cataloging fields until 2.4. Please respond if you have existing data in those fields! > > Also, please be aware that in the 2.4 release, we'll want to convert some additional fields to be controlled by the concept authority. These will include fields that refer to materials, activities, objects, concepts, cultures, and styles. I'll provide a complete list later on. > > Thanks, > Ray > > > On Mar 22, 2012, at 9:50 AM, Chris Hoffman wrote: > >> Hello again Colleagues, >> UCB would like to contribute an initial version of the Concept Authority for version 2.3 of CollectionSpace. >> >> In order to facilitate data migration for several UCB deployments, work has commenced on an initial version of the concept authority structure to be included in CSpace ver. 2.3. This initial version (see Concept Authority Requirements - UCB) will be basic, with support for one term per record, as is now the case in Person, Org, and Storage Location. Singular and plural word forms (e.g. "painting" and "paintings") would need to be added as separate term records, as will their equivalents in other languages (e.g. "peinture", "peintures", "pintura", "pinturas", etc.). Hierarchical relationships between broader and narrower terms will be supported. Basic support for Concepts include support for the default instance of the Concept Authority. It is possible that support for other instances of Concept and other authorities will be available in CSpace 2.3. >> >> Note: It is likely that the initial record editor UI for Concept will be very basic and not expose all fields in the schema. Initially we are focused on including Display Name, Short Display Name, Language, Term Type, and Term Qualifier. >> >> A Jira ticket for this contribution is available (CODE-3). >> >> A Wiki page is at >> http://wiki.collectionspace.org/display/collectionspace/Develop+initial+version+of+Concept+Authority >> A more robust version of the concept authority, planned for ver. 2.4, will provide support for the use of both preferred and non-preferred terms, and support for multilingual deployments. More information about this work will be shared soon. >> >> Please let us know if you have any questions or comments about this proposed contribution. >> >> Thanks, >> Chris >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Ray, Will we be able to use multiple concept authorities and apply them to other fields ourselves in 2.3? Susan > Yes, implementors can choose if they want a particular field to be > authority-controlled or not. I'm proposing changing the default > configuration to use the authority, so implementors who want the fields to > continue to be text will have to do a little additional configuration. > Implementors who want the fields to use the authority, but who have > existing text data that must be preserved, will have to do a migration > step. > > For 2.3, I'm proposing attaching a Default Concept Authority to those two > fields, by default. > > For 2.4, I'm proposing having a set of Concept Authority instances > configured by default, e.g. Material, Activity, Style, etc., and attaching > them to appropriate fields by default. Which instances and fields those > are, is still up for discussion. > > Thanks, > Ray > > > On Mar 28, 2012, at 4:12 PM, sstone@socrates.berkeley.edu wrote: > >> Ray, >> >> Can't implementers choose whether these fields will use the concept > >> authority or not? >> >> They may use a concept authority by default, but that can be changed in >> configuration, no? >> >> Since some people are talking about using multiple concept authorities >> (e.g., separate for materials and styles), are you proposing a Default >> Concept Authority to be attached to these fields by default? >> >> Susan >> >> >>> Hi Everyone, >>> As part of the Concept Authority work for 2.3, we're proposing changing >>> two fields on the Cataloging form to be fed from the new Concept >>> Authority: >>> >>> Object Description Information / Content / Concept >>> Object History and Association Information / Associations / Associated >>> concept / Associated Concept >>> >>> These are currently free text fields, and converting them to be >>> authority-controlled will effectively cause data loss, if you have data >>> in >>> those fields. Existing values would need to be converted to authority >>> items. Implementors, do you currently have data in those fields? If so, >>> we'll need to provide a migration path for your data. This might not >>> get >>> done in time for 2.3, in which case we would hold off on converting >>> those >>> cataloging fields until 2.4. Please respond if you have existing data >>> in >>> those fields! >>> >>> Also, please be aware that in the 2.4 release, we'll want to convert >>> some >>> additional fields to be controlled by the concept authority. These will >>> include fields that refer to materials, activities, objects, concepts, >>> cultures, and styles. I'll provide a complete list later on. >>> >>> Thanks, >>> Ray >>> >>> >>> On Mar 22, 2012, at 9:50 AM, Chris Hoffman wrote: >>> >>>> Hello again Colleagues, >>>> UCB would like to contribute an initial version of the Concept >>>> Authority >>>> for version 2.3 of CollectionSpace. >>>> >>>> In order to facilitate data migration for several UCB deployments, >>>> work >>>> has commenced on an initial version of the concept authority structure >>>> to be included in CSpace ver. 2.3. This initial version (see Concept >>>> Authority Requirements - UCB) will be basic, with support for one term >>>> per record, as is now the case in Person, Org, and Storage Location. >>>> Singular and plural word forms (e.g. "painting" and "paintings") would >>>> need to be added as separate term records, as will their equivalents >>>> in >>>> other languages (e.g. "peinture", "peintures", "pintura", "pinturas", >>>> etc.). Hierarchical relationships between broader and narrower terms >>>> will be supported. Basic support for Concepts include support for the >>>> default instance of the Concept Authority. It is possible that support >>>> for other instances of Concept and other authorities will be available >>>> in CSpace 2.3. >>>> >>>> Note: It is likely that the initial record editor UI for Concept will >>>> be >>>> very basic and not expose all fields in the schema. Initially we are >>>> focused on including Display Name, Short Display Name, Language, Term >>>> Type, and Term Qualifier. >>>> >>>> A Jira ticket for this contribution is available (CODE-3). >>>> >>>> A Wiki page is at >>>> http://wiki.collectionspace.org/display/collectionspace/Develop+initial+version+of+Concept+Authority >>>> A more robust version of the concept authority, planned for ver. 2.4, >>>> will provide support for the use of both preferred and non-preferred >>>> terms, and support for multilingual deployments. More information >>>> about >>>> this work will be shared soon. >>>> >>>> Please let us know if you have any questions or comments about this >>>> proposed contribution. >>>> >>>> Thanks, >>>> Chris >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >> >> > >

Yes. Implementors will be able to create multiple concept authority instances, and attach them to fields. You'll be able to do autocompletion on those instances, and add items to those instances through the autocomplete widget. You'll be able to import terms into different instances. In 2.3 we're not exposing this by default, because there are some limitations on what you can do with items in non-default instances. For example, you won't be able to edit them in the record editor (the save button won't appear). You won't be able to create items in non-default instances through the Create New screen. You won't be able to do a search within one instance. Hopefully, these issues will be ironed out in 2.4. Ray On Mar 28, 2012, at 4:58 PM, sstone@socrates.berkeley.edu wrote: > Ray, > > Will we be able to use multiple concept authorities and apply them to > other fields ourselves in 2.3? > > Susan > >> Yes, implementors can choose if they want a particular field to be >> authority-controlled or not. I'm proposing changing the default >> configuration to use the authority, so implementors who want the fields to >> continue to be text will have to do a little additional configuration. >> Implementors who want the fields to use the authority, but who have >> existing text data that must be preserved, will have to do a migration >> step. >> >> For 2.3, I'm proposing attaching a Default Concept Authority to those two >> fields, by default. >> >> For 2.4, I'm proposing having a set of Concept Authority instances >> configured by default, e.g. Material, Activity, Style, etc., and attaching >> them to appropriate fields by default. Which instances and fields those >> are, is still up for discussion. >> >> Thanks, >> Ray >> >> >> On Mar 28, 2012, at 4:12 PM, sstone@socrates.berkeley.edu wrote: >> >>> Ray, >>> >>> Can't implementers choose whether these fields will use the concept >> >>> authority or not? >>> >>> They may use a concept authority by default, but that can be changed in >>> configuration, no? >>> >>> Since some people are talking about using multiple concept authorities >>> (e.g., separate for materials and styles), are you proposing a Default >>> Concept Authority to be attached to these fields by default? >>> >>> Susan >>> >>> >>>> Hi Everyone, >>>> As part of the Concept Authority work for 2.3, we're proposing changing >>>> two fields on the Cataloging form to be fed from the new Concept >>>> Authority: >>>> >>>> Object Description Information / Content / Concept >>>> Object History and Association Information / Associations / Associated >>>> concept / Associated Concept >>>> >>>> These are currently free text fields, and converting them to be >>>> authority-controlled will effectively cause data loss, if you have data >>>> in >>>> those fields. Existing values would need to be converted to authority >>>> items. Implementors, do you currently have data in those fields? If so, >>>> we'll need to provide a migration path for your data. This might not >>>> get >>>> done in time for 2.3, in which case we would hold off on converting >>>> those >>>> cataloging fields until 2.4. Please respond if you have existing data >>>> in >>>> those fields! >>>> >>>> Also, please be aware that in the 2.4 release, we'll want to convert >>>> some >>>> additional fields to be controlled by the concept authority. These will >>>> include fields that refer to materials, activities, objects, concepts, >>>> cultures, and styles. I'll provide a complete list later on. >>>> >>>> Thanks, >>>> Ray >>>> >>>> >>>> On Mar 22, 2012, at 9:50 AM, Chris Hoffman wrote: >>>> >>>>> Hello again Colleagues, >>>>> UCB would like to contribute an initial version of the Concept >>>>> Authority >>>>> for version 2.3 of CollectionSpace. >>>>> >>>>> In order to facilitate data migration for several UCB deployments, >>>>> work >>>>> has commenced on an initial version of the concept authority structure >>>>> to be included in CSpace ver. 2.3. This initial version (see Concept >>>>> Authority Requirements - UCB) will be basic, with support for one term >>>>> per record, as is now the case in Person, Org, and Storage Location. >>>>> Singular and plural word forms (e.g. "painting" and "paintings") would >>>>> need to be added as separate term records, as will their equivalents >>>>> in >>>>> other languages (e.g. "peinture", "peintures", "pintura", "pinturas", >>>>> etc.). Hierarchical relationships between broader and narrower terms >>>>> will be supported. Basic support for Concepts include support for the >>>>> default instance of the Concept Authority. It is possible that support >>>>> for other instances of Concept and other authorities will be available >>>>> in CSpace 2.3. >>>>> >>>>> Note: It is likely that the initial record editor UI for Concept will >>>>> be >>>>> very basic and not expose all fields in the schema. Initially we are >>>>> focused on including Display Name, Short Display Name, Language, Term >>>>> Type, and Term Qualifier. >>>>> >>>>> A Jira ticket for this contribution is available (CODE-3). >>>>> >>>>> A Wiki page is at >>>>> http://wiki.collectionspace.org/display/collectionspace/Develop+initial+version+of+Concept+Authority >>>>> A more robust version of the concept authority, planned for ver. 2.4, >>>>> will provide support for the use of both preferred and non-preferred >>>>> terms, and support for multilingual deployments. More information >>>>> about >>>>> this work will be shared soon. >>>>> >>>>> Please let us know if you have any questions or comments about this >>>>> proposed contribution. >>>>> >>>>> Thanks, >>>>> Chris >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>> >>> >>> >> >> > >

Hi Ray, Thanks for your post. We look forward to hearing from implementers about their use of these fields at present and we are in the process of creating QA test plans to test this important contribution. > Also, please be aware that in the 2.4 release, we'll want to convert some additional fields to be controlled by the concept authority. These will include fields that refer to materials, activities, objects, concepts, cultures, and styles. I'll provide a complete list later on. A comment on your statement above about work beyond 2.3... Please note that the key issue at stake now (2.3) is to properly test the code that is being contributed. Provided that the all works as planned (and we expect that it will), any work to 'roll out' the Concept Authority to other fields is subject to our existing release process. Requirements have already been defined and fields identified (for quite some time now), to be associated with the Concept Authority. There are several steps that must be followed in order to plan for and schedule the roll-out including creating the appropriate Jira(a) with the requirements; assigning the work; estimating time/effort; and ultimately scheduling the work within the confines of our current schedule moving forward. Once we clear the 2.3 hurdles, we will address the 'roll-out' of the Concept Authority in a timely and efficient manner based on existing process. We are very excited about this contribution of new functionality and we look forward to its use by many implementers. Thanks for your efforts to-date to make the upcoming test possible. Angela On Mar 28, 2012, at 5:47 PM, Ray Lee wrote: > Hi Everyone, > As part of the Concept Authority work for 2.3, we're proposing changing two fields on the Cataloging form to be fed from the new Concept Authority: > > Object Description Information / Content / Concept > Object History and Association Information / Associations / Associated concept / Associated Concept > > These are currently free text fields, and converting them to be authority-controlled will effectively cause data loss, if you have data in those fields. Existing values would need to be converted to authority items. Implementors, do you currently have data in those fields? If so, we'll need to provide a migration path for your data. This might not get done in time for 2.3, in which case we would hold off on converting those cataloging fields until 2.4. Please respond if you have existing data in those fields! > > Also, please be aware that in the 2.4 release, we'll want to convert some additional fields to be controlled by the concept authority. These will include fields that refer to materials, activities, objects, concepts, cultures, and styles. I'll provide a complete list later on. > > Thanks, > Ray > > > On Mar 22, 2012, at 9:50 AM, Chris Hoffman wrote: > >> Hello again Colleagues, >> UCB would like to contribute an initial version of the Concept Authority for version 2.3 of CollectionSpace. >> >> In order to facilitate data migration for several UCB deployments, work has commenced on an initial version of the concept authority structure to be included in CSpace ver. 2.3. This initial version (see Concept Authority Requirements - UCB) will be basic, with support for one term per record, as is now the case in Person, Org, and Storage Location. Singular and plural word forms (e.g. "painting" and "paintings") would need to be added as separate term records, as will their equivalents in other languages (e.g. "peinture", "peintures", "pintura", "pinturas", etc.). Hierarchical relationships between broader and narrower terms will be supported. Basic support for Concepts include support for the default instance of the Concept Authority. It is possible that support for other instances of Concept and other authorities will be available in CSpace 2.3. >> >> Note: It is likely that the initial record editor UI for Concept will be very basic and not expose all fields in the schema. Initially we are focused on including Display Name, Short Display Name, Language, Term Type, and Term Qualifier. >> >> A Jira ticket for this contribution is available (CODE-3). >> >> A Wiki page is at >> http://wiki.collectionspace.org/display/collectionspace/Develop+initial+version+of+Concept+Authority >> A more robust version of the concept authority, planned for ver. 2.4, will provide support for the use of both preferred and non-preferred terms, and support for multilingual deployments. More information about this work will be shared soon. >> >> Please let us know if you have any questions or comments about this proposed contribution. >> >> Thanks, >> Chris >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org