User story
A special collections staff member I would like to have 773 data available (particularly subfield g) so that it can be passed over to Aeon when someone requests the item.
Acceptance criteria
Possible Data Structure for 773 data in constituent records.
Each group 773 fields assigned to a constituent could be stored in as a key in an array of hash structures in the solr JSON using the host record bib ID of the holding the request button is attached as the look-up key for the constituent data.
Example 773 Data from: https://catalog.princeton.edu/catalog/9917554523506421 (this is has two 773 that each point to a different host MMS ID).
773 0 3| Derrida copy 1 w| 99125489801606421 g| folder 9 o| 2.4.2.3 (M)
773 0 3| Derrida copy 2 w| 99125489791106421 g| folder 4 o| E39
Proposed structure
constituent_data: {
99125489801606421: { materials_specified: "Derrida copy 1", related_parts: "folder 9", other_id: "2.4.2.3 (M)" },
"99125489791106421": { materials_specified: "Derrida copy 2", related_parts: "folder 4", other_id: "E39" }
}
We can use this data to enhance the reading room request button that is created with the needed Aeon parameters to request the constituent. If a user selects the first holding in our example we can know that holding is associated with host MMS ID: 99125489801606421. We can than look in constituent_details and see that the the "related_parts" key (subfield g) in the 773 for that item is "folder" 9 and include that data as "ItemInfo3=folder 9" in what is passed to Aeon.
Implementation notes, if any
See this note added to this closed ticket for details and examples of complex constituent records that have multiple 773 values. We currently process 773 data but only to persist the MMS IDs of host records into the "contained_in_s" key.
A report prepared of SC constituent records is available.
@regineheberlein and I talked through the details of this and confirmed based on current data stored in the Aeon database for the "itemInfo3" data that adding subfield g is appropriate.
User story
A special collections staff member I would like to have 773 data available (particularly subfield g) so that it can be passed over to Aeon when someone requests the item.
Acceptance criteria
Possible Data Structure for 773 data in constituent records.
Each group 773 fields assigned to a constituent could be stored in as a key in an array of hash structures in the solr JSON using the host record bib ID of the holding the request button is attached as the look-up key for the constituent data.
Example 773 Data from: https://catalog.princeton.edu/catalog/9917554523506421 (this is has two 773 that each point to a different host MMS ID).
Proposed structure
We can use this data to enhance the reading room request button that is created with the needed Aeon parameters to request the constituent. If a user selects the first holding in our example we can know that holding is associated with host MMS ID: 99125489801606421. We can than look in constituent_details and see that the the "related_parts" key (subfield g) in the 773 for that item is "folder" 9 and include that data as "ItemInfo3=folder 9" in what is passed to Aeon.
Implementation notes, if any
See this note added to this closed ticket for details and examples of complex constituent records that have multiple 773 values. We currently process 773 data but only to persist the MMS IDs of host records into the "contained_in_s" key.
A report prepared of SC constituent records is available.
@regineheberlein and I talked through the details of this and confirmed based on current data stored in the Aeon database for the "itemInfo3" data that adding subfield g is appropriate.