circulation data in TEI catalogues

[holfordm]

This is a suggestion for how the TEI catalogues could add availability and other information that will be required by any circulation system. Can we discuss the adequacy of these suggestions and whether they integrate with any existing encoding, for instance of the availability element. (E.g., Fihrist already says that availability of all manuscripts is restricted, I think!).

• barcodes. To be placed inside the msIdentifier element, inside altIdentifier, inside idno type="barcode". This may be msIdentifier as child of msDesc or as child of msPart.
• select / conservation reserve items. The availability element (inside adminInfo) to have @status=restricted. Relevant text to be supplied inside a p element.
  <availability status="restricted"><p>To ensure its availability to future readers, access to this item is restricted, and readers are asked to work from reproductions and published descriptions as far as possible. To apply to see the original, please send a message to [email protected], outlining the subject of your research, the importance of this item to that research, and the resources you have already consulted.</p></availability>
• offsite items. The availability element (inside adminInfo) to have @status=offsite. Relevant text to be supplied inside a p element. <availability status="offsite"><p>This item is stored offsite and requires 24 hours notice to be produced.</p></availability>
• items not held in the Bodleian. For catalogues which include items not held in the Bodleian, integration with the circulation system will need to parse the institution or repository element of msIdentifier to determine if the item can be ordered. It may be useful to @key or @ref on these elements to ensure they are machine readable.

[andrew-morrison]

The trouble with attributes likes @restricted is they end up in templates, which get passed around, and people focus on filling in the text, ignoring the attributes, even when they contradict each other. I think that might have been the case with Fihrist.

[ahankinson]

For barcodes: I suggest that we don't store barcodes in the TEI, but that barcodes are stored in an external system, and they are linked to a more appropriate identifier for the object (e.g., an ARK). We would need to work with any system to ensure this is feasible, but it means that an update to a barcode doesn't mean that it's also an update to the record.

[ahankinson]

What happens when an object is both restricted and offsite?

[holfordm]

That situation does not occur; all the restricted items are onsite.
To allow for the future possibility that it might occur, we would need to allow the status attribute to contain multiple whitespace separated values (which would be an ODD modification).
incidentally, 'offsite' isn't currently an accepted value for the attribute (TEI allows only 'free', 'restricted', 'unknown'), so this would require an ODD modification.

[andrew-morrison]

I believe it has been decided to include barcodes in TEI files.

Perhaps an alternative place to put them would be in additional/adminInfo, as events in the manuscript's (or part's) custodial history, something like this:

<custodialHist>
    <custEvent when="2021-05-25">Allocated barcode <idno type="barcode">1234567890</idno></custEvent>
</custodialHist>

The advantages would be keeping the barcode (an ID of the container) separate from IDs of the item itself. And, as barcodes can change, it would allow a record of old ones to be kept (I don't know if that's important.) The current barcode would the one with the most recent date.