New translator for State Library of Victoria - #3604
Conversation
AbeJellinek
left a comment
There was a problem hiding this comment.
Thank you! Some suggestions
| "items": [ | ||
| { | ||
| "itemType": "artwork", | ||
| "title": "Penguin [picture].", |
There was a problem hiding this comment.
Probably want to strip this format info from titles (and the call number info in the next item?)
There was a problem hiding this comment.
I'm reluctant to do this the square bracket stuff often includes important additional info for original and pictorial collections, and it's not always going to match the format anyway. In this case the format value is "Photographs" not "Picture".
In the second case, the call number value is actually added to the title by the translator:
let [attachment, label] = prepareAttachment(digitalData, url);
// Some images are grouped under a single title,
// so add the image label to the title for clarity where necessary
if (label) {
item.title = `${item.title} (${label})`;
}As the notes indicate, this is to try and distinguish between items grouped under the one title. The label value is actually drawn from the label field in the METS metadata that distinguishes between the different items. In most cases I've seen this is a more human friendly label like 'Image 1' or 'Page 1' rather than an accession or call number. And this label value is not usually elsewhere in the metadata. So basically this gives the user an important way of telling grouped items apart.
There was a problem hiding this comment.
There is always some tension between creating good items for non-citation use cases and creating good citations, but putting a call number in the title is just too much IMO. Fine to add the label value, just not the call number. If you have a lot of items with the same title and no labels, you can enable the Call Number column in Zotero.
There was a problem hiding this comment.
Ok, I've added a check so the label is only added if it doesn't include the call number.
| item.tags = getMetadataValues(metadata, "subject"); | ||
| // Construct persistent(ish) url | ||
| let almaId = jsonUrl.match(/alma\d+/)[0]; | ||
| item.url = `https://find.slv.vic.gov.au/discovery/fulldisplay?vid=61SLV_INST:SLV&docid=${almaId}`; |
There was a problem hiding this comment.
Ideally we only want to add url if the item is actually available online at that location.
There was a problem hiding this comment.
These urls are reliable. The reason I don't use the urls from the browser is that the system urls are stupidly long and full of parameters that don't really do anything. There is a system generated 'permalink', but that requires an additional API call to retrieve, and while it's shorter, it's still not very 'perma', and the only thing it does is to encode info about the current view, which you don't need if all you want is the default view. I experimented with all the different parameters until I found a version that was short, reliable, and could be easily constructed from the system identifier. I even wrote a blog post about this if you want to read it! :-)
There was a problem hiding this comment.
What I mean is that we don't put URLs in citations (and hence in the item's url field) unless there's full-text content at that URL. So a URL for an image that's available online, yes, but a URL for a book in the catalog that needs to be checked out physically, no.
There was a problem hiding this comment.
Really? I've always thought it was important for translators to maintain the link between the metadata and its source. In any case, this catalogue includes a lot of undigitised, original material (manuscripts, photos etc), with additional metadata such as finding aids and hierarchical relationships. It's really quite crucial to have the url to the original record.
There was a problem hiding this comment.
Can add a web link attachment ({ url, mimeType: 'text/html', snapshot: false }) to maintain a link even if it's not appropriate to put in a citation.
There was a problem hiding this comment.
But no, we don't want to fill in the url field for undigitized resources, because that would produce misleading citations.
This new translator works in both the SLV's main catalogue and its digital item viewer. In the main catalogue it's now getting some metadata that wasn't being captured by the generic 'Primo 2018' translator. In the digital file viewer, the translator captures both metadata and digital files (PDFs and images). In both cases the translator is getting data from an internal JSON API.