Doc. B3a.

URLs in CONSER Records

Following is an email message from Matthew Beacom to the PCC 3^rd Task Group on Journals in Aggregator Databases on the subject of URLs in CONSER records. Adolfo Tarango, chair of the group, presented 3 options for URLs in records machine-derived from print or other format records: 1) Keep 856 fields found in source records … 2) Delete all 856 fields found in source records and do not add new ones; or 3) Delete all 856 fields found in source record and add generic 856 field to new record (aggregators home page). Matthew first responded rejecting option 2 and favoring option 1 as the only workable solution. This is also the solution presented by the Database group. I responded with a plea to consider long-term maintenance and Matthew responded with the following. I think this is an eloquent statement of what I concluded at ALA mid winter and want to share it with you for our discussions.

Jean

Dear Jean,

As I said the other day, there are no good solutions. I began my earlier note by voting for the option I thought made most sense--including the URLs, but I ended my note by suggesting that the CONSER Ops needed to think about what they want the CONSER record to do for them. Your note, Jean, is making me think again about what to do. I was especially struck by what Peter [McCracken] said. URLs will simply multiply exponentially.

Clearly, the problem with including URLs in the bibliographic record is maintenance. And the maintenance issues are driving me to re-think my preference. However, I think the question is better addressed by thinking about what CONSER is or is not responsible for. In other words, what data about serials can the community expect to have maintained cooperatively. When I do this I think that the CONSER records should not attempt to record the URLs (not only the 856 $u, but $3 and $z as well) as they are transient, local information about local holdings and local access arrangements.

The more I think of this today, the more I think the answer is that CONSER can, should and must maintain the bibliographic information about serials. No one else can do that. The bibliographic information is universal. It is true of the resource no matter who owns it or how much of it they own. As a community, we can maintain the universal facts about serials cooperatively. We have never tried to maintain local holdings information cooperatively. The recent efforts to include publication patterns and data about complete issuance history do not contradict this. They support it as the patterns and issuance history are universal, not local information about the serial.

I think we can see that CONSER can meet the charge of creating and maintaining bibliographic or universal information about serials. This gives CONSER and others a clear definition of CONSER's domain--its area or responsibility. And other organizations--publishers, 3rd party aggregators, libraries, and users--can continue to rely on CONSER for that information. CONSER can't meet the challenges of maintaining URLs for everybody. No one can. It simply isn't scalable.

This would mean a big change for what libraries now get from CONSER records. We are used to getting bibliographic records with URLs in them. Sometimes they work, sometimes they don't ... but we are used to getting them. So dealing with the change will be a big topic for discussion, should a decision be made not to include URLs. Some may argue for including at least one URL--the URL for the publication itself from the publisher. That is not necessarily a terrible idea, but I think that it would be best not to include them. If we would treat the URLs as inherently local information, then we make a very clear divide between what can be done in CONSER and what is done locally. URIs would be another matter. They would be universal and thus "bibliographic" and should be part of the bibliographic record. A successful, long-term solution to the maintenance issues very probably does require not only that we distinguish between what is universal and what is local but that we develop tools for maintaining both the universal information and the local. The difference in tools can be seen I think in the difference between bibliographic records in a utility (or even an OPAC) and the software we might use to generate links from that bibliographic data using reference linking tools like jake, or SFX, etc. I think there is a good division of labor here. Perhaps now is the time to draw that line.

Matthew