To a great extent, VIAF is a pure reflection of its source authority files and the bibliographic records linked to them. We have dedicated our limited VIAF resources towards improving the automatic processes and error reporting capabilities of VIAF rather than spending much time manually fixing problems with clusters. However, we knew from the beginning that VIAF would need methods for merging and splitting clusters and that has been handled with internal tables and procedures. In fact, we get a steady stream of emails noting problems, mostly about two clusters that should be merged, and do our best to deal with them, whether it requires reporting problems to one of the VIAF participants (we never edit source authority records here at VIAF central), changes to the code that merges records into clusters, or adding to our internal tables.
Two years ago, after giving a talk about VIAF at a RERO meeting, there were several questions about how they could not only participate in VIAF, but have a direct way of adding and modifying VIAF clusters. Thinking about how we could do this we realized that we might be able to build something that addressed both external and internal issues with VIAF. Not surprisingly, we started with our internal issues, with an eye towards the possibility of more general use.
An example record in xA is the one for Barack Obama. Since we were unable to algorithmically match some of the source authority records with each other, we manually pulled together most of them into a single cluster using an internal table. Now we have a xA MADS record which identifies the source authority records, adds the President's birth month and day, and adds an additional source record that wasn't in the internal table. Currently we have the capability of creating personal and corporate authority records.
xA gets integrated into VIAF as an additional source file. No special privileges were needed (we treat any link between source records as a 'forced' link which is almost always respected). It is probably worth noting that changes in xA are not direct changes to VIAF. We rebuild VIAF about once/month, and it is at that point that xA records get their chance to affect VIAF clusters. To give more immediate feed-back to VIAF, we have considered flagging clusters that we expect to be affected by new xA records, but have not pursued that yet.
By the way, xA is the 24th source file we are merging in VIAF.
Right now record creation and editing in xA is only available internally, although we do have a external authorities project we expect to use the same framework. How and if the process of controlling and adding to VIAF in this manner can be made more public is something we will be exploring. Right now we are just happy to have finally gotten xA into production and that we no longer need to deal with those internal merge tables!
No direct linked data yet either, although since xA shares much with VIAF, that should not be too difficult.
You are free to poke around in xA. I should warn you, however, that it will let you try to edit and create records, but will challenge you before you can save your work, so you won't be able actually change anything. We do have a site at http://viaf.org/hosted/sandbox that will let you save things if you know the secret user name and password (guest/guest).
- Ralph LeVan (SRU, AtomPub, Web)
- J.D Shipengrover (Interface)
- Karen Smith-Yoshimura (Requirements, suggestions, enthusiasm)
- Jenny Toves (Requirements, integration into VIAF)
- Jeff Young (MADS advice, protocols)
- Eric Childress (General advice)