Hi all, Patrick Schmitz told me there's a design discussion about some of the 2.4 work related to implementing preferred/non-preferred terms in authorities. Because some of the design was done in discussions here at Berkeley with Patrick and Jan Eklund, I wanted to contribute some thinking. I'm increasingly worried about how invasive some of the recent refactoring has been, and I would ask the project to reduce scope and complexity on this task. Jan and I sat down and thought about some of the areas where this work could be simplified, and I'm pasting that in below. Also, the UCB deployment team can help with some of the UI wireframes on this if that is helpful. Thanks, Chris > Hi, we really want to simplify scope on this a) to make it doable, b) to reduce risk, and c) to make room for equally or more important things such as complex object relationships. Jan and I looked at several areas for ideas and questions. I wanted to get your take on what would actually make a significant difference before taking these ideas to whomever (Talk, Angela, Carly …) > > Authorities to be refactored > > We could do this on one or two concepts instead of all of them. For HAVRC, the importance is a) concept, b) place, c) person. This sounds good but might complicate generalized search and term-completion, etc. > > Authority record editors > > Change seems to be simple at the UI level at least. We know how to develop Jan's mockup though as you say, we'd use radio button for preferred. > > Term completion > > Options: > 1) Only allow selection of preferred term though display others > 2) Display non-preferred terms but don't display other info (NPT, Lang, etc) > 3) Don't display alt-terms at all (i.e., facilitate search only) > What would help the project? > > Data import > > We don't necessarily need to support data with alternate names specified using the new model. We can import the preferred name. > > Keyword/Find and Edit search authority records > > Option: Don't display alternate terms (i.e., in indented form similar to Jan's term completion widget UI); just display the preferred display name. (If you search for a term that is an alternate name, you would get back the preferred name and could click on that to see what was in it.) > > Advanced search authority records > > UI for term completion presumably is same as Term completion above. Results of search could presumably follow same model as Keyword search of authority records above. > > Keyword search of records that use an authority with P/NP terms > > It seems like it is probably very hard to do the following two things: > 1) If user searches for a preferred-term, show also the records that use the non-preferred term > 2) If user searches for a non-preferred term, show records that use the preferred term and other non-preferred terms > We would recommend leaving that out of the first version of this stuff. > > We can already of course do this one: > 3) If user searches for preferred term, show the records that use the preferred term. > > The following seems easy if we've decided to allow people to select and/or import non-preferred terms, but we might decide not to allow that > 4) If user searches on non-preferred term, return records that use the non-preferred term > > Advanced search of records that use an authority with P/NP terms > > Again this depends on some of the option selections above (e.g., whether we allow people to select and/or import non-preferred terms), but here's some analysis that assumes we allow people to select/import non-preferred terms. > > 1) If user selects a preferred term, it's easy to display records that use that preferred term > 2) If user selects a non-preferred term, it's easy to display records that use that non-preferred term > > 3) If user selects a preferred term, display records that use any non-preferred term as well. We would like this to happen, but it is not a must-have for this version. If reworking search to use a subset of the refname is risky and hard, this could be left for a later version. > > 4) If user selects a non-preferred term, display records that use the preferred term and other non-preferred terms. We would not want to do that! > > One UI idea that might not make sense only in one combination of the above: > Only allow user on advanced search to select the preferred term, but have a checkbox that says "find alternative terms too", and adjust search accordingly (whole refname when unselected; shortID or whatever if checked). > > Internationalization > > We think the record editor allows SMK and others to input their data in the required format. Web sites and other apps that consume this information could just query as needed (e.g., create the Italian version of my web site by getting the term that is Lang=Ital and Preferred for Lang is Yes) > > We hope this helps. Either of us can sit down and go through these ideas. I know time is of the essence. > > Chris

A couple of responses to Chris. If completion doesn't offer nonpreferred terms, can they still be entered? If the point is to allow the use of nonpreferred terms, then the UI needs to give the user enough information to know what they are and that they are not preferred. In the current model, if the user tries to use a nonpreferred term and it is not matched, the system will want to add it to the authority (as a preferred term?). This I don't understand: [under advanced search] 4) If user selects a non-preferred term, display records that use the preferred term and other non-preferred terms. We would not want to do that! Why not? The checkbox idea below makes sense (find exact term vs. find term and its alternates) but since a nonpreferred term is lead-in vocabulary, it needs to return records that use the preferred term. There may also need to be an option to return or not return child terms in the hierarchy. Checkbox idea: "One UI idea that might not make sense only in one combination of the above: Only allow user on advanced search to select the preferred term, but have a checkbox that says "find alternative terms too", and adjust search accordingly (whole refname when unselected; shortID or whatever if checked)." I find it more invasive to have countless iterations where the data to be migrated need to be remodeled over and over then to implement something well the first time. This is pretty complex, so it really should be modeled well before it is implemented. Susan > Hi all, > Patrick Schmitz told me there's a design discussion about some of the 2.4 > work related to implementing preferred/non-preferred terms in authorities. > Because some of the design was done in discussions here at Berkeley with > Patrick and Jan Eklund, I wanted to contribute some thinking. I'm > increasingly worried about how invasive some of the recent refactoring has > been, and I would ask the project to reduce scope and complexity on this > task. Jan and I sat down and thought about some of the areas where this > work could be simplified, and I'm pasting that in below. Also, the UCB > deployment team can help with some of the UI wireframes on this if that is > helpful. > Thanks, > Chris > >> Hi, we really want to simplify scope on this a) to make it doable, b) to >> reduce risk, and c) to make room for equally or more important things >> such as complex object relationships. Jan and I looked at several areas >> for ideas and questions. I wanted to get your take on what would >> actually make a significant difference before taking these ideas to >> whomever (Talk, Angela, Carly …) >> >> Authorities to be refactored >> >> We could do this on one or two concepts instead of all of them. For >> HAVRC, the importance is a) concept, b) place, c) person. This sounds >> good but might complicate generalized search and term-completion, etc. >> >> Authority record editors >> >> Change seems to be simple at the UI level at least. We know how to >> develop Jan's mockup though as you say, we'd use radio button for >> preferred. >> >> Term completion >> >> Options: >> 1) Only allow selection of preferred term though display others >> 2) Display non-preferred terms but don't display other info (NPT, Lang, >> etc) >> 3) Don't display alt-terms at all (i.e., facilitate search only) >> What would help the project? >> >> Data import >> >> We don't necessarily need to support data with alternate names specified >> using the new model. We can import the preferred name. >> >> Keyword/Find and Edit search authority records >> >> Option: Don't display alternate terms (i.e., in indented form similar to >> Jan's term completion widget UI); just display the preferred display >> name. (If you search for a term that is an alternate name, you would get >> back the preferred name and could click on that to see what was in it.) >> >> Advanced search authority records >> >> UI for term completion presumably is same as Term completion above. >> Results of search could presumably follow same model as Keyword search >> of authority records above. >> >> Keyword search of records that use an authority with P/NP terms >> >> It seems like it is probably very hard to do the following two things: >> 1) If user searches for a preferred-term, show also the records that use >> the non-preferred term >> 2) If user searches for a non-preferred term, show records that use the >> preferred term and other non-preferred terms >> We would recommend leaving that out of the first version of this stuff. >> >> We can already of course do this one: >> 3) If user searches for preferred term, show the records that use the >> preferred term. >> >> The following seems easy if we've decided to allow people to select >> and/or import non-preferred terms, but we might decide not to allow that >> 4) If user searches on non-preferred term, return records that use the >> non-preferred term >> >> Advanced search of records that use an authority with P/NP terms >> >> Again this depends on some of the option selections above (e.g., whether >> we allow people to select and/or import non-preferred terms), but here's >> some analysis that assumes we allow people to select/import >> non-preferred terms. >> >> 1) If user selects a preferred term, it's easy to display records that >> use that preferred term >> 2) If user selects a non-preferred term, it's easy to display records >> that use that non-preferred term >> >> 3) If user selects a preferred term, display records that use any >> non-preferred term as well. We would like this to happen, but it is not >> a must-have for this version. If reworking search to use a subset of >> the refname is risky and hard, this could be left for a later version. >> >> 4) If user selects a non-preferred term, display records that use the >> preferred term and other non-preferred terms. We would not want to do >> that! >> >> One UI idea that might not make sense only in one combination of the >> above: >> Only allow user on advanced search to select the preferred term, but >> have a checkbox that says "find alternative terms too", and adjust >> search accordingly (whole refname when unselected; shortID or whatever >> if checked). >> >> Internationalization >> >> We think the record editor allows SMK and others to input their data in >> the required format. Web sites and other apps that consume this >> information could just query as needed (e.g., create the Italian version >> of my web site by getting the term that is Lang=Ital and Preferred for >> Lang is Yes) >> >> We hope this helps. Either of us can sit down and go through these >> ideas. I know time is of the essence. >> >> Chris > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >