# Presentation: 265058

## Update

- Janifer Gatenby,
- New Business Development Manager, OCLC PICA

## Update Models

**Catalogue**

**Mirror**
**OPAC**

- Push

**Documents**

**Repository**

- OAI
- Pull

**Catalogue**

**Union **
**catalogue**

- ZING Update
- Push

## Existing update mechanisms

- Proprietary mechanism – suitable for private one off agreements only
- OAI & FTP
- Suited for batch loading
- OAI is used where the data source exposes the metadata to be harvested for discovery purposes
- Where the data source does not expect the data to be changed by the harvesting site or does not care
- Hence one way – no mechanism for response or future synchronisation

## Web update “C.R.U.D.”

**C**reate **R**etrieve **U**pdate** ****D**elete
- REST
- ATOM
- WS-Transfer
- WSRF
- WebDAV

## Why  [ZING] SRU update?

- Requirement for immediate availability of records
- Scalability, no scheduling & batch maintenance
- Two databases are not identical
-  e.g. A union catalogue is not a slave of the contributing catalogues
- Requirement for interactive feedback – alignment, enrichment
- Identifier of the record in the target database
- Inter-record links – name and subject authorities, classification, FRBR work record etc.
- Diagnostics – diffused error resolution
- Warnings
- Errors

## Why not “C.R.U.D.”

- C.R.U.D. – all alternatives designed for document update, not metadata
- All rely on HTTP diagnostics
- Lack precision, not extensible
- No response mechanism apart from diagnostics

- Documents generally remain discrete and are not subject
- to being merged with others or changed by authority records
- or being linked to other database objects (e.g. toc, covert art...)

## Metadata update

**Cover art**

**New record**

**dbase**
**record**

**Table**
**of contents,**
**index**

**OAI harvestable**

**Accessible**

**Author**
**authority**

**Author**
**authority**

**Author**
**authority**

**Via URL**

**Author**
**authority**

**Linked**
**records**

## Synchronisation & Enrichment

- ID:A

**ID:A**
**ID:B**
**ID:C**
**ID:D**
**ID:E**

**ID: D**
**(Author)**

**ID:C**
**(Work)**

## What about Z39.50 update?

- Proved too difficult to implement
- Part of Z39.50 extended services model
- Complex layers – hybrid interactive model – task package
- Addresses batch, background and interactive update
- Addresses single and multiple record update

## Z39.50 update

- Origin

- Target

- Extended Services Request

- Task Package

- Task Package Search Request

**Notes:**
Extended Services model – all purpose model for anything requirening post session processing.  Update “fitted in” to this model.
The update request is sent (may contain multiple records)
The request is split into two parts, records and task.  Records are sent to the database and the task is sent to a task package control logical database
As the server updates the actual database it conveys status changes to the task control logical database
The origin sends an enquiry to the task package database to find out the results of the update (if background or batch – but implementing the task package is a mandatory part of extended services)
The server responds to the request

## [ZING] SRU update

- Like SRW / SRU derived from Z39.50 with “lessons learned”
- Compatible with SRW / SRU
- Base – WSDL, XML
- Definitions, e.g. record, info identifiers
- Explain
- Diagnostic structure
- Extra data mechanism
- _[http://srw.cheshire3.org/docs/update/](http://srw.cheshire3.org/docs/update/)_  (accessible from

## Request / Response

- Version (srw)
- Operation (ucp)
- Record identifier (ucp)
- Record versions (ucp)
- Record (srw)
- Extra  request data (srw)

- Version (srw)
- Operation Status (ucp)
- Record identifier (ucp)
- Record versions (ucp)
- Record (srw)
- Diagnostics (srw)
- Extra Response Data (srw)

## Simplifying Z39.50 Update

- Interactive only
- Single record only
- All who implemented the UCP did so single record
- No task package
- No levels of status
- Operation status (status only within the Z association)
- Statuses that can change within or outside the Z association
- Record status
- Update status (for all records in the batch)
- Task status
- Modernise to include HTTP POST (SRU style), XML, UNICODE

## Diagnostic Messages

- Message identifier
- Message description – in two parts – action taken by server may be present preceded by a colon.
- transaction rejected completely
- component rejected
- warning only
- default value applied
- data corrected by server
- Other information
- Includes information to highlight the location of an error

## Validity Diagnostics - Examples

- Validity diagnostics (currently 29 messages)
*Missing mandatory element ****:**** record rejected  *
*Other Info - component id, invalid data*
*Missing mandatory element ****:**** warning only*
*Other info - component id, invalid data*
*Missing mandatory element ****:**** default value applied*
*Other info - component id, invalid data*

## Update Diagnostics

- Update diagnostics (currently 12 messages)
*Incorrect or invalid version record id ****:**** **c**annot process update, *
*Other info - latest version #, URL for retrieving latest version of record*
*Linked records exist ****:**** cannot delete record*
*Other info - record id*
*Record or component not found ****:**** replacement request processed as an insert*
*Other into - record id of new record*

## SRU and Update

- Independent
- You can implement just SRU or just update
- You can implement them both
- Same technical flavour: Makes it easier to implement both
- XML schemas
- Diagnostics structure
- Explain mechanism

## Current Status

- Standard proposition June 2004
- Draft discussed SRW meeting Washington DC 2004
- Diagnostics added Feb 2005
- OCLC & OCLC PICA implementation Feb 2005 +
- Definitions for
- Bib / auth / holds
- Return of identifiers
- Diagnostics used
- MARCXML (MARC21)
- HTTP POST with SOAP wrapper
- Explain extensions
- WorldCat (server) NCC (client) interoperability Q1 2006
- OCLC PICA CBS server Q1 2006