10.1 Direct-to-Profile Requirements
Introduction
Direct-to-Profile processing involves more I/O activity
than other ILL Direct Request processing options. Therefore, requests using
Direct-to-Profile take longer to process. This option may not be suitable for
systems that allow patron-initiated ILL, since the system may keep patrons waiting
for a response.
To be sent to a lender, an ISO-10161 ILL-Request for Direct-to-Profile must:
- Satisfy ILL Direct Request requirements for acceptance
- Match a WorldCat bibliographic record
- Match a profile defined by the borrowing library
- Have enough lenders
- Satisfy other OCLC ILL requirements
Requirements for acceptance
The requirements for acceptance are:
- All fields required by ISO-10161must be present
-
transactionId must be universally unique
-
protocolVersionNum must have the value version-1(1) or version-2(2)
- The OCLC institution symbol of the borrowing library must be included in the request.
(See initialRequesterId and requesterId in "Table: Specifications and
Mapping" in chapter 9.)
- One of the values of illServiceType must be loan(1) or copyNonReturnable(2)
-
title must be present in itemId
- The first request of a connection must contain an OCLC ILL authorization number and
password. (See illrequestExtensions in "Table:
Specifications and Mapping" in chapter 9.)
Match a WorldCat bibliographic record
In order to match a WorldCat bibliographic record, the request must
contain an ISBN, ISSN, or OCLC number.
Match a profile
ILL Direct Request matches profiles based on attributes of the request
and attributes of the matching bibliographic record. The request attributes are:
- request source
- ILL service type
- patron status
- patron department
- patron max cost
- need before date
A request must meet the following requirements to match a profile:
- If your library has profiles based on the attributes listed above, the request must
include the attributes
- The ILL service type must be loan(1) or copyNonReturnable(2)
- The scheme used for request source, patron status, and patron
department must be the same as used in the profiles
- Any of the attributes entered by the patron must be validated
Have enough lenders
The request may contain lenders or it may rely on ILL Direct Request to
find lenders based on the matching bibliographic record and the custom holdings path named
in the matching profile. (Custom holding paths are records of preferred lenders based on
custom groups defined in the OCLC ILL service by your library. Your ILL staff assign a
unique name to each custom holdings path they define.)
The valid lenders in the request and the lenders found by ILL Direct Request must
satisfy the minimum number of lenders specified in the matching profile. If they do not,
ILL Direct Request puts the request in your librarys Review File.
PermissionToChange
SendToList
If the request does not contain lenders, then ILL Direct Request
automatically tries to find lenders. If the request contains lenders, then ILL Direct
Request does not try to find more unless permissionToChangeSendToList (part of thirdPartyInfoType)
is set to true.
preference
If preference (part of thirdPartyInfoType) is set to ordered,
ILL Direct Request does not change the order of lenders in the request. If an invalid
lender is found before the minimum number of lenders is satisfied, ILL Direct Request puts
the request in the Review File.
See section 3.1 for details about preference
and permissionToChangeSendToList.
Satisfy other OCLC ILL requirements
To be sent to the first potential lender, the request must meet these
additional requirements:
- If present, needBeforeDate (under searchType) must contain a valid date
that is today's date or later
- If present, copyrightCompliance must have the value ccg or ccl (not
case-sensitive)
- If paymentMethod (in OCLCILLRequestExtension) is present and set to ifm
(not case-sensitive), the request must contain maximumCost (under costInfoType).
The monetaryValue must be valid for IFM. The currencyCode, if present, must
be usd (not case-sensitive)
- Contain postalAddress under deliveryAddress or match a profile that
contains the name of a constant data record
that includes a :SHIP TO: field
Failed Requests
If the request fails to meet any of the requirements for acceptance, it
is rejected. ILL Direct Request sends a message to your system identifying the rejected
request. If the request is accepted, but fails one of the other requirements, ILL Direct
Request puts it in your librarys OCLC ILL Review File with an appropriate error
message in the field :DIRECT NOTES:.
Incomplete requests
If an ISO-10161 ILL-Request is incomplete and the request matches a
profile that contains the name of a constant data record, then data from the constant data
record is applied when ILL Direct Request creates an OCLC ILL request.
Constant data considerations
Constant data records are templates of often-used data defined by your
library that can be automatically transferred to a workform in OCLC ILL. ILL staff assign
a unique name to each constant data record they define. Data from the ISO-10161
ILL-Request takes precedence over data from the constant data record. For example, if the
ISO-10161 ILL-Request contains :MAXCOST:, then :MAXCOST: is not applied from constant
data. Your library must decide which data should be supplied in the ISO-10161 ILL-Request
and which data should be omitted so it can be supplied by a constant data record.
The following fields in an OCLC ILL record may be supplied by a constant data record if
they are not furnished in the ISO-10161 ILL-Request.
| :NeedBefore: |
:AFFILIATION: |
| :EDITION: |
:PATRON: |
| :SHIP TO: |
:PDEPT: |
| :BILL TO: |
:PSTATUS: |
| :SHIP VIA: |
:PATRON ID: |
| :MAXCOST: |
:PATRON ADDR: |
| :COPYRT COMPLIANCE: |
:PATRON PHONE: |
| :FAX: |
:PATRON E-MAIL: |
| :E-MAIL: |
:PATRON FAX: |
| :BILLING NOTES: |
:PATRON NOTES: |
| :BORROWING NOTES: |
|
Serials
Direct-to-Profile processing requires the element titleOfArticle
to Produce serial requests. If omitted, these requests are sent to the Review
File.
Testing
Direct-to-Profile processing uses several types of OCLC records defined
by your library:
- Direct Request profiles
- Custom Holdings groups and paths
- Constant data records
To fully test Direct-to-Profile, you must have these types of records in the test
database. You may create them in the test environment, or, if your library has these
records in production, ask OCLC to copy them to the test database. Once in the test
database you can edit them. Records created or modified in the test environment have no
effect on the production system or production database.
A good title for testing
A good bibliographic title for testing has a lot of locations attached
to it. A good one to use is In Search of Excellence: Lessons from Americas
Best-run Companies (ISBN:0446378445; OCLC:9684530). You may want to use this title in
your Direct-to-Profile test request because it is likely to be held by some of the
institutions in your librarys custom holdings path.
Testing in the production system
You may choose to test Direct-to-Profile in production. There are
advantages and disadvantages to testing in production:
The advantages are:
- Access to WorldCat instead of a small subset of bibliographic records in the test
environment
- Production is always available; the test environment may sometimes be down
- Your library may have custom holdings paths and constant data records in production so
changes made for ILL Direct Request only need to be made once
The disadvantages are:
- Your library incurs a charge when Direct-to-Profile finds lenders
- If your library uses one of the OCLC services that puts requests in the Review File,
then you must be able to distinguish your test requests from the real ones
- Fewer diagnostics running in production environment
If you choose to test Direct-to-Profile in production, set the Produce? option
in your profiles to no until you are ready for requests to be sent to lenders.
Note: You cannot test in the production environment
until OCLC has reviewed your request in the test environment.