Monday, october 15th, 2007, 1:30 pm
James mauldin, archival mgr, collection mgmt, gpo
History: Oclc developed purls; First gpo purl, march 26, 1998
GPO has decided to adopt cnri’s handles as consistent naming system for fdsys. Handles have been around for 10 years – has been continually modified and updated (while PURLs haven’t, really).
Assigned name to a resource
Cnri registration is mandatory before creating handle system – they assign a prefix (ie, 10-200/url)
Handles is a java-based program (no http); String of numbers followed by slash
Handles must be resolved through a proxy server; cnri does provide a proxy server for systems who don’t want to set up their own. That’s what GPO used for their beta test.
Requires an admin to update url;
Purl software resides on unix servers along with
Purl is free; handles requires subscription fee (ie, you get what you pay for)
handles and the fdsys:
handles … all features required by fdsys
currently beta-testing handles; comments will be sent to fdsys folks
LC has a handles operation – able to give advice, etc.
Full-scale implementation is dependent on fdsys and their timetable
New handles and old purls:
Gpo expects that it will be possible to resolve purls through the handles server (90,000 purls created thus far)
in order for purls to be resolved, they’re going to have to be entered into the handle database
alpha test results:
- handles software more sophisticated than purls
- handles more complicated to create
- handles can be hand-created/named rather than automatically generated
- complexity of software … more difficult to modify handles after creation
- one handle can contain multiple urls –
- doesn’t automatically resolve
- ??
A web page has been created, listing titles with purls and handles - see www.fdlp.gov/handles/index
comments deadline: November 26
anything a handle is created for will have a digital copy on gpo servers
purl server wasn’t built to scale – once they hit 20,000 purls validation of purl db stopped. handles are scalable
Q: will there be an api set-up from purls to handles?
A: during beta test did not use apis, used [something that wasn’t intelligible]
Q: long-term plan for purl system?
A: part of fdsys (release 1C)
Q: will there be any maintenance at the local library catalog level that will occur (ie, changing links in ILS?
A: don’t foresee any
Q: have you tested the scalability of handles?
A: no; beta test was limited
Response: may want to re-assess file-naming conventions for scalability once
Comment: Umich is using handles to deal with their google content
Q: does handle system have any implications for authentication/validation?
A: outside the scope of the beta test; addressed in a future release of fdsys
Q: will handle system be open-url compliant?
A: will have to resolve it through a proxy server
Q: will handle system lend itself to referral stats? (reference to purl referral service)
A: outside the scope of the pilot; there is a metrics component to the product
Reminder that this is open for comments; need feedback from community to determine where to go
Q: how is gpo going to pay for the handle service?
A: annual fee; very nominal. Gpo will pay – won’t be passed on to users
Q: is this more labor-intensive than the purl process?
A: yes and no – depends on the way it’s deployed – system-generated handle vs. naming convention, could mean more work
Q: what happens to the incorrect purl?
A: before migration takes place, purl maintenance will be complete
Q: is there an advantage in handles vis-à-vis serials solutions? what kind?
A: distributed network means greater response time
A: open url standard has a place in it for handles – could be an advantage
Q: how would handles ‘handle’ a serial publication, with multiple files associated with one entity? Any serials in current beta test
A: current beta test (demonstration) doesn’t include serials; decided to keep it as simple as possible.
