Inventory (UXPROD-785)

[UXPROD-2667] Inventory. Result list Refined display rules MCL. Sort on primary contributor Created: 18/Sep/20  Updated: 15/Oct/23

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: PNG File Skärmavbild 2020-07-24 kl. 12.09.08.png     PNG File Skärmavbild 2020-09-24 kl. 11.04.26.png     PNG File Skærmbillede 2020-11-17 kl. 14.01.49.png    
Issue links:
Relates
relates to UX-449 UX: Sort by values for updated invent... Open
relates to FOLIO-1281 define sorting semantics for titles a... Closed
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:
MM SMEs have expressed a desire, that is, to focus on the longer-term goals rather than interim goals if they can't be built on directly. The lack, for instance, of call number in the search results display of the holdings segment, would not be addressed by the improvements in the JIRA features listed below. So I agree with you, @charlotte, that putting resources toward the hierarchical display instead ( UXPROD-491 Analysis Complete ), if at all possible, is in our best interest.
Charlotte Whitt: See more comments added 2/23/2020 in UXPROD-491 Analysis Complete .

  • - - - - - - - - - - - - - - - - - - - - - - 

 

This feature is split out of UXPROD-1634 Closed - the library ranking is kept from the original feature, which previously included all relevant refinements of the result list for the MVP.

The cap.plan team has asked for getting the different improvements split into their own feature:

  1. UXPROD-1634 Closed (index title/title)
  2. UXPROD-2667 (sort on contributor, when more than one contributor is listed)
  3. UXPROD-2668 Open (Adding instance HRID)
  4. UXPROD-2669 Open (Adding resource type)
  5. UXPROD-2670 Draft (Adding format)
  6. UXPROD-2671 Open (Adding edition)
  7. UXPROD-2703 Draft (Adding publication date)

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:

  1. Display the primary contributor
  2. If no primary contributor is displayed, then list the first three mentioned contributors, and sort on the fist listed one
  3. If no contributors, the result will only be the Index title/Resource title, and publisher, etc.

Notes:
This is critical for the results list display to be useful for any searches, displaying the title data of the instance record.

Usecase:
As a librarian who is searching in Inventory.
I want the search results to display the primary contributor
If no primary contributor is displayed, then list the first three mentioned contributors, and sort on the fist listed one
If no contributors, the result will only be the Index title/Resource title, and publisher, etc.

Out of scope:
Future need: customizable results lists (tenant level and user level)

Documentation:

  1. Slide deck reviewed by MM-SIG 10/1/2020 and 10/8/2020 - https://docs.google.com/presentation/d/1kDumWwhNfP7Mq9hZ5q4O1cnbg_BY4ILgKbjBWOO4Xso/edit#slide=id.p
  2. Survey send out on the #metadata-management channel 10/7/2020 - https://docs.google.com/presentation/d/13Dt-Tkr_nzgU2Oxb044J4d3RSxxk4R-0lq-AlKXIItg/edit#slide=id.g9998cb799b_2_0


 Comments   
Comment by Marc Johnson [ 21/Sep/20 ]

Charlotte Whitt Cate Boerema

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.

If no primary contributor is displayed, then list the first three mentioned contributors, and sort on the first listed one

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.
And what data to look at would vary for resource types - e.g. different if it's a monograph (her the editions for e.g. a given work by Franz Kafka would be very important, and for e.g. a journal then the HRID etc. etc.

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:

That implies, that if there is a primary contributor, then sorting by contributors should sort on the primary contributor?

Unknown macro: {qoute}

That's correct.

What do folks expect when sorting by a contributor, is this based upon the name?

Yes, that's the expectation.

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?

Yes, that's the expectation.
When a bibliographic record is being catalogued by a cataloger, then use of the correct form of the name is being controlled/checked up against a name authority file.


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:

  1. Van Harmelen, Frank is defined as the primary contributor. Van Harmelen, Frank is to be listed as the first mentioned contributor in the result list, and his name is to be sorted
  2. Antoniou, Grigoris is the first contributor in the instance, but because he's not the primary contributor, he will be displayed in the result list as the second contributor. No sorting on this contributor
  3. Test, John, is displayed as the third contributor in the result list. No sorting on this contributor.
Comment by Marc Johnson [ 24/Sep/20 ]

Charlotte Whitt Thank you for your answers

When a bibliographic record is being catalogued by a cataloger, then use of the correct form of the name is being controlled/checked up against a name authority file.

Does this mean that the system should sort on the name in the form it was entered by the cataloguer, without any modification?

Let's look at this (made up example, which could be real). Also keep in mind, there can only be one primary contributor

Thank you for the example.

because he's not the primary contributor, he will be displayed in the result list as the second contributor

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:

  • Antoniou, Grigoris
  • Van Harmelen, Frank
  • Test, John
  • Secondtest, Joe

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.

Zak Burke

Comment by Charlotte Whitt [ 24/Sep/20 ]

Marc Johnson


Does this mean that the system should sort on the name in the form it was entered by the cataloguer, without any modification?

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:

  1. Antoniou, Grigoris
  2. Van Harmelen, Frank
  3. Test, John
  4. Secondtest, Joe (the fourth listed contributor in the instance record, is not to be displayed in the Result list.

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?

Comment by Zak Burke [ 24/Sep/20 ]

at the moment, the system makes no guarantee about preserving the order of the contributors.

That's quite surprising news, Marc Johnson, given that contributors is defined as an array.

Comment by Marc Johnson [ 24/Sep/20 ]

Zak Burke

That's quite surprising news, given that contributors is defined as an array.

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 ]

Maybe the use of an array does state that order must be preserved.

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 ]

Zak Burke

An array is an ordered list. If the backend does not preserve the order, this is a bug.

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 ]

if ordering is important in the domain, then it might be worth expressing that explicitly in the model

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 ]

Zak Burke

The front-end work is already done here, unless the back-end expects something other than providing "sort=contributors" in queries.

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?

Generated at Fri Feb 09 00:25:52 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.