Magda
I would like to start with a few questions that were reoccurring. Several responses to the question about call number display in the preview and confirmation screen indicated a preference to see each call number prefixes and suffixes elements in separate columns. And I would like to understand what the use cases are. Why do you think it should be separate? I just want to make sure I understand.
Jackie
Well, one thing is that that's how you can see if, for example, somebody put the prefix in the call number field instead of a prefix field. And if you have them all together, you can't actually see
Magda
Yeah, it makes sense.
Erin
That's an excellent example.
Magda
This is a good point. If you combine everything, you will never know what is the part of the call number and what is the part of the prefix.
Sara
I think the examples are exactly right. If I need to do a cleanup job, then the call number prefix, etc., need to be separated.
Bob
So are we talking about just this preview screen of 10 records? Or are we talking about the download file?
Magda
The download file will have everything and it will be structured like the record is structured. So you will have everything separately, the . The prefix call number and suffix will be done separately. But we are talking about preview, we are talking about the are you sure form, and we are we are talking about their confirmation , and all those places when those records are being displayed.
Magda
The other question about the preview, are you sure form and the configuration screen is someone mentioned (it was Duke) the need to see the holding statements and holdings notes.
Leeda
So I checked in with my leader, who helped me fill out this survey. And she said both types of data would be useful for analyzing the scope, ensuring accuracy, and troubleshooting when needed. But again, since we're just talking about a 10 to 20-item preview screen. I think We're fine as long as we can get to it on that CSV, we're fine.
Magda
My concern is that if we are add holding statements and notes, I don't know how lengthy those notes can be.
Leeda
It was alright for concatenating the summary statement, and then for the holding notes, I think just the presence or absence of a note would be fine. Again, it's just a case of when we get ready to run a bulk edit, inevitably, there can be records in there that we didn't really mean to hit.
Magda
Leeda, do you want those to be columns in the preview?
Leeda
The feedback I got was yes, but I'm not sure certain that the that they understand that you can capture that in the CSV. I will get back to you on that one. If I had to make an executive decision, I would say it's not absolutely necessary. But I do like the idea if we can have a presence or absence. Kind of like a yes, no, and then download the whole thing to find out what's there.
Magda
What about electronic access? This was also mentioned. Electronic access has several fields and are is long. It would make the display pretty difficult. So how do we concatenate, or do we leave them out?
Leeda
I could see again that it would be more for ensuring that you're touching the right records. Because I know at Duke, we have a lot of titles where we hold the print and the electronic. And we don't want to touch the wrong title in that case.
Sara
I would not rely on the Preview or 10 records. I would have to download them to make sure ensure that I wasn't changing something that I did not intend to change. If I 'm understanding understand you correctly, everything will be the download file. Am Do I understanding understand that correctly?
Unknown Speaker 14Magda 14:12
That's correct, that all . All the data from the Holdings Record will be in the CSV file.
Sara
So, in this case of only being able to see 10, it's unclear how this will help. Maybe then it's not worth putting so much time and effort into getting all these fields exactly right or including too many or too few.
Magda
And my thinking runs along the same lines as well as Sarah's. To make you feel a little bit better, we plan to change the preview to allow pagination to of the results, etc. But this is not happening in the Nolana. It will be coming later once we start building the query tool. Because when you submit the list of identifiers, we can assume that those identifiers were based on a query or you have the items in front of you , and you scanned the barcode. So, you know what dataset you are acting on. Once we get to running queries, then the top 10 is not going to do anything for you because you will need to see the query results of the query. . This is when we will be making changes to the preview. But this is not in Nolana. We may start talking about this in Orchid and then follow up in Poppy. So if it is something in our pipeline, it . It is just not available here. So going back, do I understand what you're saying is that since the preview is only an abbreviated preview, you will need to go to CSV anyway. So we can be a little bit less verbose in defining what fields need the need in the preview screen. Is this correct?
Leeda
Yeah, I think so.
Sara
I just wanted to follow up briefly on something that you just I think it's worth noting. Just because I have a stack of 20 books , and I can scan their barcodes into a file , does not necessarily mean that I know what is in their records. I think this is worth noting because this happens to me all the time. For example, I get a list of barcodes that need to go on display. I'm changing the temporary location. A pop-up note for the circulation people is supposed to be added. But sometimes it turns out there's already information there. And so then, if I do a bulk edit without checking first whether or not that field already has information, which I cannot tell from just having the physical book in my hand, I will override that information. So we should not assume that I know what is in the records just because we have a stack of physical items that I know what is in the records. efforts.
Magda
That's a very good point because I didn't think about that.
Magda
So, if I still would like to take a look at the specific questions that I have from the responses to the survey. So again, we are talking about identifiers here. My question is about the OCLC number. Is there an OCLC number on the holdings or just on the instance.?
Sara
No, it is only the instance level from the MARC source.
Magda
Okay. So I think someone who suggested OCLC understood that when we submit the list of OCLC numbers to identify instances and then from instances go to holdings, this is something that we will be addressing through the query. So I will table this for now, as well.
Magda
The next question was about the columns. I see that we need to put a call number with all the elements in separate columns, including their call number type. So we already talked about the holding statement , and electronic access. My concern is if we add electronic access to the preview, the rendering will be difficult at this point. And then the following questions are similar. One of the respondents suggested let letting the user manipulate the order. This is the long-term goal, but it will not be happening happen for Nolana. So, for now, we need to have a predefined list of columns.
Magda
And the last question was about the columns in the action menu that are not selected.
Unknown Speaker 23:18
For How should statistical codes - how they should be separate separated because this is a multiple-entry field? Should we use a commas comma-separated list or a new line? I
Jennifer
It looks like, for notes, they're using pipes. So that's probably fine for that two.
Magda
And call numbers we actually covered. We also have a response suggesting staff suppress. There is no staff suppress suppression on the holdings. So I do believe the user or the respondent meant at was referring to the instance level and this , which will again be drilling down to the housings holdings record that will be covered by the query. Electronic access, as I mentioned, worries me about its rendering of in terms of rendering it. Is the URL the only valid field, or do you need the type of electronic access as well?
Christie
I think that in our use case, we would want to see everything but the URL because the URL is unique. And maybe the CSV is enough for this. We frequently put our platform names as the link text in the URL. And we're frequently normalizing the material specified statements. So for us, it would be materials specified statements, link text, the notes, and the type.
Unknown Speaker 25Magda 25:53
And I understand that you may want to change that. In Nolana, we will only only support changes to be located holdings location, temporary and permanent holdings locations. The other fields will come later. But do you want to see this information rendered in the column on the preview screen?
Christie
I don't remember if whether we asked for this or not in the survey. I don't know that this is a high priority for us. I do know that we have a use case for changing that, which is why I spoke up.
Magda
And I understand that these fields that will be supported in the in-app approach for Holdings Record edits, but I'm not sure we need to display this data in the columns.
Sara
If this is just about the confirmation screen, I think it was Leeda who earlier said that it would be worthwhile having just kind of something indicating if it is present or not present just to have that added knowledge that you didn't get the ebook rather than the print book. Otherwise, I don't think the confirmation screen needs all this detail. In the CSV, it does need to be there, including the URL string, which I have had to do bulk changes too frequently. There are definitely use cases for needing to change the URL in batch, but that can be in the CSV, obviously.
Magda
There was one mention of including associated order and purchase order lines. Is there any feedback on that?
Magda
That would be something more at the query level. I think the usefulness of the preview screen would be more to preview the columns that I was actually taking an action on. I'm starting to think about it more in that respect.
Magda
In chat, I see Christie is asking about the ability to change part of a string. Yes, in Nolana, this is available to cover common use cases, for example, changes in the email domain. Find and replace functionality will be added. It will be available for other fields down the road. Some fields, like location and date, will not be supported in Find/Replace like location and date , as it is not applicable. Is that a limitation?
Christie
That is a limitation, but there is a process.
Magda
We are at the top of the hour. See you all next time.
