View in #metadata-management on Slack
@clthomas: My first question is about the Instance Status element. This element is designed to indicate where an instance record is its life cycle in a way that is useful within your institution: is it fully cataloged or not? Batch loaded? are there sharing restrictions? This is a non-repeatable element. Should this element be required or not required? (See row 15 on the Gaps - Instance tab.)
@ann-marie: Hi @clthomas I vote required for the Instance Status element. Seems like every instance should have a status, even if it’s just Active/Inactive, or then getting into more degrees, ones like Fully Cataloged, In Process, Temporary, Flagged for follow-up, etc. Figuring out the categories, especially if they may need to be the same across all libraries in the early days, may be the hard part.
@clthomas: I am inclined to agree with you. In my current system the equivalent element is not required and when we end up with long held records that all of a sudden are missing a status it is not always easy to determine what the status should have been. (In many of these cases the only context was the status itself.) We could refer to a copy of the database, but that can be too much work for such a small issue.
In terms of functionality, I would prefer that the institution have local control over the terms that are used. I, too, think that coming to a consensus on a shared terminology would be difficult.
@laura.wright: If instance status is required (which would be fine with me), a library could always choose a default value like “unevaluated” to mean that no meaningful status had yet been assigned. Even that information would be helpful.
But I’m not sure I agree with it being not repeatable. What if it is batch loaded and also considered fully cataloged?
@ann-marie: Yes, exactly, @laura.wright - if it’s not a field you care to use, set them all to “not applicable” and be done with it. Leaving it as optional seems to carry more risk than making it required and forcing a library to assign at least one status to all records.
@ann-marie: As for repeatable or not, I guess it depends on what the status field is supposed to be indicating. Batch loaded might influence the last updated date and user (user = FOLIO or BATCH instead of a user ID), but the instance status would still be fully cataloged or needs review or something like that, right?
@clthomas: I am leaning towards an instance only having a single status. If we need a secondary status maybe statistical search code or tags would work? Ultimately each institution should be able to determine what the meaningful statuses are for their local workflows.
It may be that batch loaded is an important designation for one institution but not for another.
@laura.wright: I think this might be a case where tags could be used for the other data we might be tempted to shoehorn into “status.” We have locally often conflated multiple types of information into one field because we don’t have enough place to put coded information.
@ann-marie: Interesting implication for batch loader: we talked about the MARC record load updating the stored MARC record, which in turn updates any related MARCcat bib record or FOLIO Instance. But there may be non-MARC elements in the instance record that need to be updated (like last update date/person, instance status, or tags). We’ll need to think that through for the batch loader rules.
@laura.wright: For example, our “former location” code in item records is in the same fields as the item suppression code.
Good point @ann-marie – I have sometimes needed to just update something like the cataloging date, though would that be done through the loader or through a batch editor?
I currently use re-loading often as a work-around for functionality I think should be done within my catalog (such as attaching items to a group of instances).
@ann-marie: As for batch editor or batch loader, I guess it depends on whether you’re trying to update the cat date by loading a file or not. Still TBD, and could potentially be accomplished via re-loads like you mention here, though that seems cumbersome.
@laura.wright: It is cumbersome. But another scenario might be batch-loading full records that are merging with “stub” records created for orders, and wanting the cataloging date to be added at the same time. That would require the batch loader to act on non-MARC elements in the instance records.
@clthomas: @ann-marie We would definitely want to be able allow the import profile to configure a status to be set or changed by an import process. I can also see other related data elements needing to be similarly impacted, e.g., tags and the statistical code.
@laura.wright I wonder if the status updated date would work for that? Or, do we need an element that explicitly captures the date that a record was first considered full cataloging?
There are two questions about gap elements in the holdings record. One is Holdings Type ( row 12 on the GAPS-Holdings tab). Is there a fixed list of values for this element? I am assuming, also, that it is not repeatable and not required. Is this actually the case?
@laura.wright: We currently have a date cataloged field, and it is useful in many ways. I recently provided this date as evidence for a legal case that a specific book was publicly available at a certain time…
@clthomas: @laura.wright Should we add this as a gap at the Instance record? Is this a date that would be set by a cataloger or via a batch import profile? Or would it be set by the system, for instance when an Instance Status was first changed to Fully catalgoed (or something similar)?
@laura.wright: In our system it can be set via a batch import profile or entered manually. Among other things it’s used to determine when a record is ready to be sent out for authority control.
Re: holdings type I agree that it should be not repeatable, not required. The out of the box values could be “print, electronic, microform”?
@clthomas: Laura: Can you add the cataloged date to the Gaps tab for Instances?