Woodruff - JSTOR DDA
As of 11/2017, the JSTOR profile in the PDA module is deprecated, and replaced by 3 "regular" repository import profiles:
Repository Import Profile #1 - UNIV JSTOR PDA Candidate load
Automatically loads candidate records (whether a match based on 035 or not) and adds a portfolio into the JSTOR eBooks collection.
Normalization deletes standard junk MARC tags and adds:
- 940 // $$a JSTOR DDA CANDIDATE
- 590 // $$a Available to current Emory University students, faculty and staff.
- 856 // $$z Online resource from JSTOR
Profile Details tab
Records are picked up from WSCM - collection is Books at JSTOR Demand Driven Acquisitions (candidate records). We're only retrieving new records right now - the deletes were deleting purchased records because upon purchase, they are removed from this WSCM collection and added to Books at JSTOR ALL Purchased.
Normalization & Validation tab
Process - EMORY-UNIV JSTOR DDA CANDIDATE
Task List tab
Task Parameters tab
Match Profile tab
Set Management Tags tab
Inventory Information tab
Repository Import Profile #2 - UNIV JSTOR PDA Purchases Overlay
Automatically oads purchased records only (overlays the candidate record) and does not add a portfolio.
Records match on 035 (number + prefix have to match exactly).
Normalization deletes standard junk MARC tags and adds:
- 940 // $$a JSTOR DDA PURCHASE
- 590 // $$a Available to current Emory University students, faculty and staff.
- 856 // $$z Online resource from JSTOR
New purchased record completely overlays old candidate record.
Profile Details tab
Records are picked up from WSCM by Turing - collection is Books at JSTOR ALL Purchased.
Regular firm JSTOR eBook orders from Gobi had to be turned off in order to automate the DDA Purchase process (or else they would have gone in the same WSCM folder - they could not be separated).
Normalization & Validation tab
Same as EMORY-UNIV JSTOR DDA Candidate norm rule, but replace CANDIDATE with PURCHASE in first stanza.
Process - EMORY-UNIV JSTOR DDA Purchase
Same as EMORY-UNIV JSTOR DDA Candidate process, but replace Candidate with Purchase norm rule in Task Parameters tab.
Match Profile tab
Set Management Tags tab
Inventory Information
Repository Import Profile #3 - UNIV JSTOR PDA Purchases Overlay Force Add
This manual profile is to force purchases to load that didn't match on 035 in the JSTOR PDA Purchases Overlay import profile. Records that didn't load from that import profile should be manually downloaded from Job History and manually imported using this file.
Records match on any one of the following fields:
- 020 (subfields a and z, which are indexed to ISBN)
- 776 (subfield z, which is indexed to ISBN)
- 024
- 035
- If a field contains several values, any one of the values is used to match.
Matching
- If there is no match, the incoming record is added and a portfolio is added in the JSTOR eBooks collection.
- If there is a match with an IZ record, the incoming record is merged with the existing record and a portfolio is added in the JSTOR eBooks collection.
- If there is a match with a CZ record, no changes to the CZ record are made, and a portfolio is added in the JSTOR eBooks collection.
Normalization deletes standard junk MARC tags and adds:
- 940 // $$a JSTOR DDA PURCHASE
- 590 // $$a Available to current Emory University students, faculty and staff.
- 856 // $$z Online resource from JSTOR
Merging with an existing IZ record (most likely a vendor record):
- 035, 856 JSTOR link and note, and 940 JSTOR DDA PURCHASE are added from the incoming record to the existing record
- 490, 830, 505, 520, and 776 are added from the incoming record to the existing record if those fields are not already present in the existing record
- All the 650 fields of the existing record are replaced with the 650s from the incoming record
Profile Details tab
Normalization & Validation tab
Match Profile tab
Theoretically, we should be getting the same OCLC purchased record as the candidate record, but this frequently doesn't happen in the UNIV JSTOR PDA Purchases Overlay import profile, so 035 (Other System Identifier) was not always working as a match method. We also can't use Unique OCLC Identifier match method because our OCLC index was never reindexed after it had been broken. ISBN (exact subfield match)/ 024 / 035 also didn't work because of the same situation with our ISBN index.
So we're using ISBN / 024 / 035 match method. Records match and are merged based on any one of the following fields:
- 020 (subfields a and z, which are indexed to ISBN)
- 776 (subfield z, which is indexed to ISBN)
- 024
- 035
- If a field contains several values, any one of the values is used to match.
Merge method - EMORY-UNIV JSTOR PDA purchase overlay
Set Management Tags tab
Inventory Information tab
0 Comments
Add your comment