Data mapping loose ends

[saverkamp]

@saverkamp, @nonword, @thisismattmiller, and @beefoo met to review beta data mappings and tie up loose serialization ends. This is a list of outstanding issues and things to double-check:

• Serials item call numbers should go in skos:prefLabel (@saverkamp to check mapping, @nonword to serialize) -- updated: see comment below ✅
• Update Electronic Location/Supplementary Content default (if blank or not found, default to Supplementary Content -- @nonword ) ✅
• Add Creator literal (@nonword) ✅
• Check Alternative title is mapping from all 5 fields (@nonword) ✅
• Take call number from bib as well as item (@nonword) ✅
• Media type/Carrier type serialization logic (see separate tab in mapping -- @nonword ) ✅
• Just use dcterms:created for literal (+ dbo range, already mapped) -- fix interface labels (only use Date Created label -- @beefoo)
• Check dimensions and extent are serialized correctly (@nonword) and display in one line in interface (@beefoo) ✅
• Make sure admin notes aren't getting sent to index (@saverkamp to find field number and flag) -- updated: see comment below ✅
• OCLC # logic (@thisismattmiller)

Feel free to break any of these out into separate issues.

[saverkamp]

re: prefLabel for serial volumes, here are two options. 1) call number (852 $h) + fieldtag v (what we talked about doing): MQA (Industrial architecture) v. 3 (1960)

2) Bib title + fieldtag v (maybe a little nicer looking, but probably unnecessary: Industrial architecture. v. 3 (1960)

Developers' choice! I don't have a preference. It's quite possible option 2 could get quite lengthy and make for ugly display, so sticking with option 1 may be the way to go.

[saverkamp]

re: Private note fields, Abdul says we should suppress 541 and 561 if first indicator (ind1) is 0. I've added this info to the mapping documentation.

[nonword]

Given how the front-end is using this data, I think it best to go with option 1 for serial item prefLabel:

call number (852 $h) + fieldtag v

Is there a different set of rules for other catalogitemtypes? For now I'll just copy shelfMark to prefLabel for all.

[nonword]

oclc and dcterms:created are covered elsewhere, so closing this.

[saverkamp]

Sorry, I missed your comment. I don't think we'll have different rules for different catalogitemtypes. Based on feedback from the demo, we might have another MARC field we need to check for, but I still need to look into that.