• Created by user-f44b9, last updated on Oct 31, 2008 2 minute read

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Agenda

  • review webinar on name identifiers
  • discuss approaches to implementation
    • how much to implement
    • possible models
    • possible collaborations – see just below
    • scalability issues

From Dean's 10/21 agenda:

One item people might want to take a look at was brought to my attention by
MacKenzie Smith during my visit to MIT. Apparently OCLC is working on a
follow-on to the original PURLs. This is still a work in progress, but some
info is available at:
http://prototypo.blogspot.com/2008/02/beyond-redirection-rich-and-active.html

Notes

present: Adam, Bill, Brian, Jon, Marty, Rick, Simeon

Marty will circulate links to the NISO names identifier webinar when they have been posted. The Thomson ResearcherId and ISNI identifiers for individuals are further along than organizational identifiers; while of interest, we do not plan to collect or maintain external identifiers for individuals or organizations as part of this project.

Simeon reviewed the Los Alamos National Lab Id 2-step locator system for their approximately 10,000 aDORe repositories, many of which correspond to an individual ARC file. Resolution speed (~10 milliseconds) is essential since a single page view may require multiple (~10) separate id resolution actions. They maintain some 600 million identifiers, which are converted into a 16-byte md5 hash as the index of a very large MySQL table. The repository id is the only other field in the main resolution table; collisions are resolved via a much smaller 2nd table of repository ids, which also contains the URL of the repository. The system is powered by 4 IBM blade servers having collectively 16 Gb of memory, and was implemented in Java. Hashing the identifiers, while resulting in some collisions that have to be resolved, does support load balancing by the simple mechanism of the leading digits of the hash values.

We concluded this system was too closely linked to the aDORe federated repository design (which had not been implemented at the time Bill and Adam started using aDORe here at Cornell) to be of use for this project. While capable of scaling and very fast, we do not anticipate wanting a 2-stage approach or needing so large an identifier space.

  • No labels