Inventory
(UXPROD-785)
|
|
| Status: | Open |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Inventory |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Charlotte Whitt | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | delete_record_functionality, metadatamanagement, po-mvp, round_iv, search_result, short_term_solution | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue links: |
|
||||||||||||
| Epic Link: | Inventory | ||||||||||||
| Analysis Estimator: | Charlotte Whitt | ||||||||||||
| Front End Estimator: | Zak Burke | ||||||||||||
| Back End Estimate: | Large < 10 days | ||||||||||||
| Back End Estimator: | Marc Johnson | ||||||||||||
| Estimation Notes and Assumptions: | The front-end work is already done here, unless the back-end expects something other than providing "sort=contributors" in queries.
Assumes that ordering of contributors is preserved and the solution involves introducing a new custom index for sortable contributors. |
||||||||||||
| Development Team: | Spitfire | ||||||||||||
| Kiwi Planning Points (DO NOT CHANGE): | 1 | ||||||||||||
| PO Rank: | 132 | ||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R4 | ||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||
| Rank: Cornell (Full Sum 2021): | R4 | ||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||||
| Rank: FLO (MVP Sum 2020): | R1 | ||||||||||||
| Rank: GBV (MVP Sum 2020): | R4 | ||||||||||||
| Rank: Grand Valley (Full Sum 2021): | R1 | ||||||||||||
| Rank: hbz (TBD): | R1 | ||||||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||
| Rank: MO State (MVP June 2020): | R2 | ||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||
| Rank: U of AL (MVP Oct 2020): | R1 | ||||||||||||
| Description |
|
Laura Daniels:
This feature is split out of
The cap.plan team has asked for getting the different improvements split into their own feature:
Overview: The result list has for the basic alpha implementation been: Resource title, and all listed contributors. With the refined use of elements implemented for beta, we need to configure the results in the Result list based on:
Notes: Usecase: Out of scope: Documentation:
|
| Comments |
| Comment by Marc Johnson [ 21/Sep/20 ] |
|
The title of this feature refers to sorting by primary contributor. Yet the description itself does not mention sorting by primary contributor, only what to do if there is no primary contributor.
That implies, that if there is a primary contributor, then sorting by contributors should sort on the primary contributor? Assuming this is likely the intent, I have some questions. What do folks expect when sorting by a contributor, is this based upon the name? Is the name always entered in a consistent way, meaning the system does not need to interpret it, e.g. is there an expectation that for people, the sorting would be surname then first name? How does the system know which contributor is the first / first three contributors? Is it the order in which they are entered into the system (meaning that has to be maintained)? |
| Comment by Cate Boerema (Inactive) [ 21/Sep/20 ] |
|
Charlotte Whitt, did you carry over the rankings on this? We have been asked by the PC not to carry over rankings when we do splits. The scope is different and so the ranking is likely to be different. |
| Comment by Charlotte Whitt [ 21/Sep/20 ] |
|
Yes, I did intentionally carry over the rankings. To determine if a given title is the correct one, then you need the combination of data in the result list. So it makes little sense to ask the libraries IMHO to ranke each feature. But if you disagree - I can delete, and we ask the libraries for more ranking ... |
| Comment by Cate Boerema (Inactive) [ 24/Sep/20 ] |
|
Charlotte Whitt, not sure if you saw Marc's question above? It would be great if you could answer so we could get some estimates on this feature. Thanks! |
| Comment by Charlotte Whitt [ 24/Sep/20 ] |
|
Marc Johnson - Re. your questions above:
What do folks expect when sorting by a contributor, is this based upon the name? Is the name always entered in a consistent way, meaning the system does not need to interpret it, e.g. is there an expectation that for people, the sorting would be surname then first name?
How does the system know which contributor is the first / first three contributors? Is it the order in which they are entered into the system (meaning that has to be maintained)? Let's look at this (made up example, which could be real). Also keep in mind, there can only be one primary contributor: In this example the order will be:
|
| Comment by Marc Johnson [ 24/Sep/20 ] |
|
Charlotte Whitt Thank you for your answers
Does this mean that the system should sort on the name in the form it was entered by the cataloguer, without any modification?
Thank you for the example.
Does that mean that irrespective of the order in which the contributors are entered, the primary is always considered the first contributor? If Van Harmelen, Frank was not the primary contributor, and no primary contributor was selected, would the order be:
How does the system know this is the correct order, is it because that is the order that the contributors were entered by the cataloguer? I know these questions may seem pedantic, what I'm trying to understand is how important the ordering is, how the system knows that order and whether that order must be preserved. This is important because at the moment, the system makes no guarantee about preserving the order of the contributors. |
| Comment by Charlotte Whitt [ 24/Sep/20 ] |
|
| Comment by Zak Burke [ 24/Sep/20 ] |
That's quite surprising news, Marc Johnson, given that contributors is defined as an array. |
| Comment by Marc Johnson [ 24/Sep/20 ] |
Maybe the use of an array does state that order must be preserved. I'm not sure that is actually guaranteed by the modules (most transform the JSON to an object and back again, some likely also map it to relational structures. I don't know if either of those mappings guarantee order, especially not the latter). As JSON has no other construct for lists, sets etc that would suggest that none of our APIs can have unordered collections. |
| Comment by Zak Burke [ 25/Sep/20 ] |
An array is an ordered list. If the backend does not preserve the order, this is a bug. |
| Comment by Marc Johnson [ 25/Sep/20 ] |
I think it's a shame that the only option we have is an ordered array. I very much doubt that the ordering is guaranteed in all places, especially given the various mappings that occur. For the purposes of this work, I think the feature should include validating that the order is preserved. (In general, I think that if ordering is important in the domain, then it might be worth expressing that explicitly in the model) |
| Comment by Zak Burke [ 25/Sep/20 ] |
But it already is expressed explicitly in the model: the type of contributors is "array" and an array in JavaScript is an ordered list. |
| Comment by Cate Boerema (Inactive) [ 09/Oct/20 ] |
|
Zak Burke and Marc Johnson do you have enough information now to provide estimates? If so, please do! Thanks! |
| Comment by Marc Johnson [ 12/Oct/20 ] |
I agree this would the most stable and semantic thing to do. I think that is unlikely. At the moment, the back end tooling (RAML Module Builder) tends to match queries to either properties in the JSON or to dedicated indexes that are defined. For the client to ask for sorting by contributors there would need to be a way to configure the back end tooling to behave differently for this particular query. I don't know what would happen if we defined a custom index (e.g. date of publication with the same name as a property in the JSON. Particularly in this case, where the property is an array and has configuration for the custom array searching CQL modifiers. Jakub Skoczen Julian Ladisch Do you know what would happen? Would the custom index take precedence? Can that be the case only for sorting or would it apply for searching as well? |