66th IFLA Council and General
Jerusalem, Israel, 13-18 August
Code Number: 031-82(WS)-E
Division Number: VI
Professional Group: Information Technology
Joint Meeting with: National Libraries: Workshop
Meeting Number: 82
Simultaneous Interpretation: No
& Terry Noreault
OCLC Online Computer Library Inc.
Dublin, OH, USA
What's in a name? That which we call a rose by any other name would smell as sweet.
While Shakespeare may have been right about rose fragrances, the same cannot be said about Web-based names. We have entered an age where naming plays a role in who can access and provide services for an object. Here we propose that references on the Web reflect standard library names because these names provide a means for developing services that will better serve libraries, library patrons, and scholars.
Every object we encounter has at least one name, sometimes more. We use names because we need simple monikers for things we describe and build services around. On the Web, we often think of a URL as a name for the item it points to. Of course, this is not quite true. The item can move, invalidating the URL name, and the item described might not exist on the Web, like a car or old book. What has commonly been called a name on the Web is really just a "reference". A traditional reference in the paper world would include many pieces of information about the object in question. On the Web, it is assumed that the complete unique identification of an item can be accomplished in a single URL. The URL is really a reference or service request, not a name in and of itself. The real name of the object is independent of the service being provided or any URL that might refer to some manifestation of the object.
The idea of naming objects instead of relying on URLs is not new. Work on Uniform Resource Names (URNs) as a replacement to URLs is nearly a decade old. There have been many eloquent articles written describing the need for digital object names as well as the pros and cons of naming solutions. Interest in more natural names on the Web is quite widespread. For instance, on March 14, 2000 Steve Ballmer, president and CEO of Microsoft, announced Microsoft's further commitment to RealNames Corporation Internet Keyword solution. This technology relates phrases like "ford explorer" to appropriate URLs. This brand name to URL lookup manifests itself today in several Internet browsers and search engines.
The library community deals with standard names of many different forms every day. Some of these traditional names and services need to be carried over to the Web to offer patrons and scholars the level of service they require. Consider a book. The book's title is a name. It provides a reader with a set of words to help them identify and remember the book. We can also say that the book's ISBN is a name. While the ISBN is not used to entice a potential reader or recommend the book to a friend, it is much easier to use than a title when building services since it more uniquely identifies the book.
We would like to propose that identifiers on the Web reflect the names used before the Web came into being. This would allow many of the traditional library services to be provided along with many new services. In essence, we suggest that the name is not a URL or URN or URL-like link. The real name of the object is somehow unique in the physical world and the Web. The name should be part of a URL that designates a service request. For instance, if the name for a book is the ISBN, a standard reference could look something like:
Since this is a simple URL, the resulting reference might be a display with the book's title and a list of available services. We could even make specific services, like a title/author display available as links:
Many services become possible because of the fact that the ISBN is a known standard supported by many systems with additional metadata. If, however, the reference for a given book is just an arbitrary URL or private identifier, these enhanced services become very difficult, if not impossible to provide.
As an example of third-party services and the power of open naming, we are researching prototype name services using ISBNs and metadata to which we have access. These services show that naming on the Web can reflect standard names from pre-Web days. They also show that third-party services do not have to be complex for end-users to benefit from them. For instance, the following two live references in our prototype use ISBNs as suggested above:
Of course, the idea of building name services does not address the issues of access and rights. Just because names are well known, does not imply that all services on the names will be free. Services may very well be restricted, as in the case of document delivery. However, standard references would even help make these services more robust. If references contain the standard name, sites receiving requests that they cannot fulfill can take the standard name in the request and put new links on the resulting page to jump-start the patron elsewhere. One such link might be something like:
Hopefully, the default name service for this name would then help the patron find an appropriate copy or at least provide enough metadata for the patron to inquire further from their information provider. The default service might even help the patron properly authenticate themselves with the site that could not fulfill the original request - or provide a hidden id/password automatically for them.
The idea of default services and services that help patrons after unsuccessful access attempts take on increased importance in light of some recent developments elsewhere. The publishing community recently announced an initiative to ensure that article references can be resolved to the original publisher so the article can be retrieved. This is a wonderful step towards better scholarly research on the Web. Hopefully, this will result in quicker access to the articles and wider dissemination of the materials. However, this effort has several important implications for OCLC members.
OCLC members require multiple suppliers for many resources. They do not want to be put in a situation where there is only one supplier for the information and services their patrons require. As a simple example of why a single source is not sufficient, imagine that a consortium has reached an agreement with a publisher to host a copy of the journals for a given period at the consortium headquarters. When a reference is seen by a patron from the participating institutions, the consortium would want the article retrieved from the local copy, not the remote supplier. Simple resolution back to the original supplier may not sufficiently address this appropriate copy problem.
One possible solution to the appropriate copy problem would be for third-party services to act as resolvers for standard references. These services could take the requested reference, match it against complex profiles based on IP addresses, id/passwords, and administrative and resource metadata to pick the appropriate copy for the patron. The reference and the metadata needed to determine which copy to retrieve need not be (and probably would not be) bound together. We do not believe that each information provider or naming service is going to want to deal with all this complexity. It is therefore likely that name services will have to be provided by parties other than the original content providers. Also, patrons will need help should they come across a reference to a site which they do not have access.
We believe that many services should be built using names that the library community already uses like ISBNs. It is interesting to note that many of the items for which ISBNs have been assigned are not available on the Web. That does not diminish the importance of these names and services. The names can still be used on the Web if appropriate services are built around them such as purchasing, cataloging, referencing, and lending. While we have focused on ISBN examples in this article, similar arguments can be made about ISSNs, SICIs, and other unique identifiers in the library and publishing worlds. It does not take too much effort to think of all kinds of potential services once well known names are applied to objects. Technology is not the limiting factor. We need groups like the OCLC members and publishers to agree on open names. We then need organizations to step forward and commit to services on these names. Maintaining these services will be a big effort. The library community should promote the use of these names and services. If name services are lightly used, the effort to build and maintain them is probably not worthwhile.