Difference between revisions of "RDA 1.4"
(→RDA 1.4: Records to Deliver) |
|||
| Line 1: | Line 1: | ||
==RDA 1.4: Records to Deliver== | ==RDA 1.4: Records to Deliver== | ||
| − | + | [[Image:rda1-4.png]]<br><br> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | < | + | |
| − | + | ||
===All bib records=== | ===All bib records=== | ||
When converting AACR2 records to RDA, all records will have some changes | When converting AACR2 records to RDA, all records will have some changes | ||
Revision as of 08:22, 25 March 2013
Contents
RDA 1.4: Records to Deliver
All bib records
When converting AACR2 records to RDA, all records will have some changes made (even if the only change is updating the Leader and adding 040 $e rda). If you are choosing to do the full crosswalk from AACR2 to RDA, you would need every bib record returned to replace your existing record in your ILS.
Changed bibs only
This option encompasses all changes made during the RDA processing. If you would like the RDA processing to only take place when upgrading and validating existing RDA bib records, then you could choose to have only changed bib records returned.
Bibliographic file segmentation
ILS limitations or requirements for loading and indexing updated records are a consideration in determining maximum bibliographic output size.
The response time in some local systems is sometimes degraded during prolonged loads. In other ILS, essential online system tasks cannot be performed during a load.
While Backstage can handle files in excess of 1,000,000 records, we can also distribute files broken up into more appropriate chunks to facilitate the loading and indexing processes at your side.
links
1.0 - 2.0 - 3.0 - 4.0 - 5.0 - 6.0
