|
Search | Back Issues | Author Index | Title Index | Contents |
 |
D-Lib Magazine
|
|
Jeffrey A. Young |
|
IntroductionOpenURL was originally developed to enable link resolution of citation information in a distributed interoperable way. The initial standard (version 0.1) has been effectively subsumed as an application (named the San Antonio Level 1 profile) of a much more general framework called OpenURL 1.0. We used the framework to create WikiD (Wiki/Data), an application that has little to do with citation link resolvers, but is instead a set of general purpose services for managing arbitrary collections of items. The model for this application is a wiki engine generalized to manage multiple collections of XML records. This article describes WikiD and how it can serve as an example for applications that can be built on the foundation of the OpenURL framework. Using OpenURL 1.0 as a Foundation for ApplicationsThe title of the ANSI/NISO Z39.99-2004 (OpenURL 1.0) specification is "The OpenURL Framework for Context-Sensitive Services". It is primarily a standard for defining interoperable web-service applications. Although interoperability is a hallmark of OpenURL, this doesn't need to be the primary consideration for choosing it as the foundation of an application. The framework defined by OpenURL is equally useful for creating one-of-a-kind standalone applications. In a standalone application, interoperability is simply "along for the ride" waiting for someone to see and use the added potential. For example, we could consider WikiNames [1] to be referent identifiers and observe the variety of techniques used by different wiki engines to perform an edit service on them:
Despite the common function being performed, the particular wiki engine request and response structures differ widely, not to mention their schemes for referent and service identification. In contrast, the OpenURL framework supports Community Profiles that could standardize requests for these communities without, necessarily, affecting the uniqueness of their responses. The potential of such a profile for interoperability should be apparent, but it is interesting to consider the potential for making it easier to develop these applications. Each of these examples currently involves a separate code base to decipher the parameters as well as a different architecture for installing new services. In comparison, OpenURL application distributions could be created to allow these communities to share common code for parsing the request, along with simple templates to contain any proprietary business logic. In addition, if developers could agree to define and use community-wide response schemas, it would be all the better for automated clients. We might even imagine new services created and written for one system that could be bundled and dropped into another without any additional code needed to activate them. The WikiD system described in this article could be viewed as a prototype implementation for just such a Community Profile. The key components of this profile are services applicable to almost any type of collection:
The OpenURL component of WikiD supports all these services, but, in hindsight, these profile choices are not necessarily recommended. The development of a legitimate Community Profile would require the buy-in and participation of a diverse community of developers. Systems providing similar services already abound, but standards for interoperability (beyond OAI-PMH) are mostly lacking. If developers contributed to the creation of a communal OpenURL Community Profile, a significant level of interoperability could easily be achieved without disruption to legacy infrastructures. Furthermore, new systems could potentially use this profile as their primary API and thus avoid creating yet another proprietary interface. Bridging the Gap between Wikis and OpenURLSo far, the standardized structure of OpenURL requests has only been hinted at. OpenURL is a general-purpose URL-based protocol, so even in the simplest case of performing a "service" on a "referent", the parameter names are derived from this more general level of abstraction. Here, then, is a sample OpenURL request for an edit service performed on a SandBox [2] page referent along with a break-down of the parameters: http://alcme.oclc.org/wikid/resolver?rft_id=info:wikid/CollectionWikiPages:
The generality of the parameter names, prevalence of URIs, and the Extending Wiki Principles to Other Forms of DataOpenURL was originally developed to support linking to distributed bibliographic information. The application of OpenURL to wikis takes OpenURL in a different direction. The fact that the OpenURL model holds up so well across both is a testament to its power and flexibility. Beyond that, applying the abstractions in the OpenURL model to a concrete application can inspire us to see a bigger picture, even in the midst of developing a specific application. Ward Cunningham describes a wiki as "the simplest online database that could possibly work" [3]. While this is an apt description of a wiki, it ignores the fact that the content in such a database is limited to wiki markup. Fortunately, this is a self-imposed limitation that is merely assumed by developers of typical wiki engines. In fact, the same set of "wiki" services ("e.g., display, edit, history) is equally useful for any form of record-based content ("referents"), if only application developers could enable it. WikiD takes this step by supporting data encoded in any form of XML. To make this possible, WikiD supports the creation and use of multiple collections of data, where each collection is associated with a particular XML Schema. This required a change in the wiki naming convention to use a colon to separate the collection identifier from the item identifier within that collection. For example, CollectionWikiPages:FrontPage (a wiki markup page) and CollectionGsafd:GSAFD000001 (a thesaurus entry) are referent identifiers to items in two different collections [4]. To maintain a consistent model across all forms of data, wiki markup is enclosed in an XML wrapper element and placed in a collection dedicated to that schema (CollectionWikiPages). The only difference between accessing wiki markup and accessing other forms of XML data (such as the Zthes thesaurus format used for CollectionGsafd), is the XSL Stylesheet assigned to the collection to render items for display and editing. The underlying services are the same in their treatment of these as anonymous XML documents. Here, then, are various wiki-style services applied to a CollectionWikiPages referent (using the WikiD shorthand forms mentioned in the previous section):
WikiD mechanically transforms each of these into an OpenURL equivalent for processing:
These same wiki-style services can be applied to a Zthes record referent in CollectionGsafd. As just mentioned, the only difference from the CollectionWikiPages examples is the XSL stylesheet assigned to the service to render the referent for display. Therefore, in the case of the following:
WikiD mechanically transforms these into the OpenURL equivalents for processing as well:
These examples from WikiD demonstrate the efficacy and adaptability of a limited subset of OpenURL abstractions, viz. referents and service types. And while the short-hand URL forms that WikiD provides as a bridge between humans and the OpenURL resolver are not part of the OpenURL standard, they demonstrate how easy it can be to support both human and automated clients. Adding Context-Sensitive Information to OpenURL RequestsSo far, we have observed referents and service types, but these are just two types of entities modeled by the OpenURL Framework. OpenURL applications actually have a variety of entity types to choose from to capture information pertinent to the service request. Taken together in a request, these entities are collectively referred to as a "ContextObject". Here are the formal descriptions of each entity type from the OpenURL 1.0 specification [5]:
The interpretation and accumulation of these abstract entities into the ContextObject might vary from application to application. As an example of the standard scenario for citation linking, we can imagine that Jane Doe, a Caltech student, clicks a hot-linked reference to an article by Bergelson within an article by McArthur that she found in Elsevier ScienceDirect. This scenario maps to OpenURL entities in the following way:
Applying these entity abstractions to a wiki engine dedicated to book reviews, we can imagine request details that facilitate authorization, authentication, parameter interpretation, and logging/data mining. As an example of an alternative to the bibliographic linking scenario, we can imagine that a Caltech student named Jane Doe clicks the "Write an online review" link in a bibliographic record for Zadie Smith's "On Beauty" in OCLC's OpenWorldCat service. This scenario maps to OpenURL entities in the following way:
Looking back on each of these applications, we can imagine the response changing significantly if any one of these values changes. Here is a summary of how the result might change for each entity in relation to the bibliographic linking application:
Here is the same analysis performed in the context of a wiki application:
SummaryWikiD demonstrates that OpenURL has potential far beyond its roots in citation linking. It shows the potential for a new OpenURL Community Profile that defines services that can be applied to collections of any type of data. And although OpenURL is inherently a machine-to-machine protocol, it is easy to create a thin overlay to handle human-friendly URL requests that can be mechanically transformed into standard OpenURL representations before being handed off to the resolver for processing. Much of this functionality can be provided with the minimal requirements of OpenURL's referent and service-type entities. For more complex situations such as the need for authentication and authorization, OpenURL provides a richer set of entities to represent the subtle context in which the service is being performed. Notes[1] WikiNames are typically used in wikis to identify individual pages. See <http://en.wikipedia.org/wiki/WikiName>. [2] Most wikis define a SandBox page where users can harmlessly experiment with the system. [3] What is Wiki? <http://wiki.org/wiki.cgi?WhatIsWiki>. [4] Note, however, that within certain bounds "CollectionWikiPages:" is considered to be the default collection, which means it can typically be omitted to preserve the conventional wiki aesthetic. [5] See "Section 5.1" of The OpenURL Framework for Context-Sensitive Services, ANSI/NISO Z39.88-200X. National Information Standards Organization, 2004. Available at <http://alcme.oclc.org/openurl/docs/pdf/z39_88_2004.pdf>. Copyright © 2006 OCLC Online Computer Library Center, Inc. |
|
|
|
Top | Contents |
| |
|
D-Lib Magazine Access Terms and Conditions doi:10.1045/july2006-young
|