Harvard mapping revisions [6/10]

Description

Hi, Scott,

I apologize – you must be very tired of tweaking this. I’m sure you want to be done with it, and we agree.

Of the issues below, I think Relation is the single most important in terms of the discoverability and intelligibility of the records in the DPLA context. The next priority for me would be adding other missing metadata (See Format and Alternative Title, below). Wendy and Vanessa are both out this week, but I know they are concerned about the collection titles that are either not ready or not helpful in DPLA.

Alternative title

This is not being picked up in dpla Alternative Title (W298374_urn-3:FHCL:825608)

The source contains

<mods:titleInfo type="alternative">

<mods:title>Hongmengshi mo ke</mods:title>

</mods:titleInfo>

Collection

I’m not sure where we ended up with this, but setNames that aren’t on the list are being mapped:

Demo Collection (90)

Chinese Rare Books (5)

DPLA-Review-cna-20190101-20190630 (2)

Ideally, only values on the harvest list would be included.

Description

I remember you did not want funding notes (//mods:note[@type="funding"]), and I agree, but it looks like they are being mapped. See div00575c07754.

Format

Here’s an example of //cdwalite:termMaterialsTech not being picked up in dpla Format (W298374_urn-3:FHCL:825608)

The source contains

<mods:extension>

<cdwalite:indexingMaterialsTechSet

xmlns:cdwalite="http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite">

<cdwalite:termMaterialsTech>intaglio</cdwalite:termMaterialsTech>

</cdwalite:indexingMaterialsTechSet>

</mods:extension>

Relation

Now that Colonial North America records are being harvested, it would be enormously helpful if the //relatedItem[@type="host"]/titleInfo/title were mapped. They could be mapped to Relation, appended to the Title, or – do you have another idea that would be a better location in DPLA?

If mapping titles from each //relatedItem[@type="host"] segment is too much, mapping just the single //mods:relatedItem[@type="host"][@displayLabel="collection"] would provide the most important bit of context. Please see div00575c02099 as a very typical example.

Type

I was wrong about all of our records having //librarycloud:digitalFormat. All will contain it, but not all contain it now. About 12K records lack it; long story. As of today, both //librarycloud:digitalFormat and //mods:typeOfResource have incomplete coverage.

For the documentation, can you confirm where you are deriving your Type value from now?

I hope those are clear and sensible. Please let me know If you want to talk about any aspect of this, or send questions/comments/thoughts via email.

Thanks for your work and your patience!

Robin

Status

Assignee

Scott Williams

Reporter

Scott Williams

Labels

None

Epic Link

None

Sprint

None

Priority

Medium
Configure