The IMesh Toolkit

[ Work In Hand > Technology Review > Standards and Protocols ]

Simple Digital Library Interoperability Protocol (SDLIP)

Overall Purpose

Simple Digital Library Interoperability Protocol is intended as a lightweight protocol for accessing information resources. It takes the function of search middleware, brokering access to diverse, autonomously-maintained information repositories, with the object of simplifying the task for client application writers who would like to offer access to those resources. SDLIP works on the client server model. The client requests searches over information sources. The server wraps the external information sources, which do not necessarily implement SDLIP themselves. SDLIP can be implemented over HTTP, CORBA or DCOM - interaction with an SDLIP information client can occur over any of these transport mechanisms.

Brief Overview of Functionality

The functionality is divided into three interfaces (or groups of operations). Clients initially request searches through the search interface. The second interface, the result access interface, handles follow-up requests about the results of searches. A third interface, source metadata interface, can be used to provide information about the identity and capabilities of the subcollections that are served (such as the query language for a subcollection and the searchable properties of documents in a subcollection).

Search Interface

Clients can specify the parameters for their search operation, namely: which subcollections they wish to search, the number of documents they would like to have returned immediately, which properties of the documents (title/author/abstract etc.) to return, and for how long they would like to be able to interact with those results.

Results Access Interface

Follow-up requests or information about the result set is acquired through this interface. Information that can be obtained: the total number of retrieved documents, and the time remaining for which the result set will be kept; Requests that can be made to the interface: requests for additional documents (or portions of documents). Requests can also be cancelled via this interface. This interface is only supported if the server maintains state (i.e. it is not functioning as a stateless server)

Source Metadata Interface

This interface deals with requests about the sub-collections that it serves out. For each sub-collection the name, a human-readable description of contents (optional), a list of query languages that may be used for querying, and whether it is the default sub-collection is stated. For the documents in a sub-collection, the document properties, and which of the properties are searchable and retrievable are stated.

State Maintenance.

This is negotiated within the search interface; excess time can be requested via the result access interface

Other capabilities

If the server becomes overloaded, it may designate a delgate and the client will be instructed to direct further queries about a result set to the delegate, (thus state is still maintained).

Deployment

Implementations in Java [9]

SDLIP-Core [1] describes an abstract interface which shields application builders from the underlying transport mechanisms. The SDLIP Application Programming Interface (API) is defined using the Interface Definition Language (IDL). IDL provides an interface description which is independent of any particular programming language. The authors of The Simple Digital Library Interoperability Protocol [1] provide a document which specifies how the SDLIP interface is realized when writing in Java. This specification is referred to as SDLIP's "Java binding". Also documented is an explanation of how to write a client application. The material also explains how to write a Library Service Proxy (LSP). An 'SDLIP Toolkit' that provides useful facilities to make the creation of applications and LSPs easy is described. Among the toolkit's facilities are client and server transport modules for both DASL and CORBA transports. The authors claim that the reader does not need to understand the details of these transports. This document explains how to instantiate and use the respective facilities.

SDLIP defines a mapping of SDLIP-Core operations onto DASL, which provides a coherent transport between SDLIP clients and services over HTTP and allows SDLIP clients to search DASL servers and DASL clients a minimum of search capabilities over SDLIP servers. SDLIP's binding to DASL is described in SDLIP DASL Transport Mapping [7].

CORBA-based interactions are specified with CORBA IDL, and SDLIP's CORBA binding is described in SDLIP CORBA Transport Mapping [8].

Most of the implementations of SDLIP which have been cited are US-based and related to the development partners. Search Middleware and the Simple Digital Library Interoperability Protoco [2] lists the following implementations:

"UC Berkeley created SDLIP access to the Berkeley Environmental Digital Library documentation collection. Berkeley also created a gateway from SDLIP to Z39.50, enabling access to the University's MELVYL catalog which covers UC library foldings, and to many holdings of the California Digital Library's extensive collections of digital resources. These include electronic journals, databases, reference texts, and archival finding aids. This bridge between SDLIP and Z39.50 further expands the coverage to other Z39.50 compliant servers including, for example, the Library of Congress. SDSC is using SDLIP to provide search interfaces to the Metadata Catalog (MCAT) of their Storage Request Broker (SRB)[3] and to the XML-based information mediator (MIX) [4], thereby facilitating access to further sources including, for example, the AMICO [5] image colleciton. Access to Web-based resources includes a people finder and a film review site.

We also implemented SDLIP access to the Dienst Protocol, which enables searches over distributed technical reports. (NCSTRL) [6]."

Related Standards

XML [UKOLN XML review]

Some parameters passed between SDLIP clients and servers are specified to be XML - encoded strings. XML-encoded strings are passed as XMLObjects. This is done to keep SDLIP's datatypes simple, and is particularly useful for parameters that contain mulitple pieces of information. Some of the parameters are intended to use the property lists, a catch-all expansion facility which consists of XML-encoded information.

One example provided in the documentation shows how search results can be returned in response to a search by encoding the information as XML. The following example is of SearchResult, which is one kind of XML string, demonstrates how the flexibility <proplist> can be used.

<SearchResult>
     <doc>
           <DID>1</DID>
           <propList>
               <author>Bill Smith</author>
               <author>Frank Miller</author>
               <title>This is My Life</title>
               <abstract> It's been great so far</abstract>
           </propList>
     </doc>
     <doc>
     ....
     </doc>
</SearchResult>

Other search protocols [UKOLN Z39.50 review] [UKOLN WHOIS++ review] [UKOLN LDAP review]

In the scenario where SDLIP is used as a broker that wraps a number of external sources, the SDLIP server will be required to communicate with these external sources via the protocols that they support. These well may be Z39.50, WHOIS++ or LDAP. Therefore the server will need to cope with these protocols and some format interchange for the data that it retrieves may be needed before it can be passed to the SDLIP client.

Relevance to IMesh context

The main function of Subject Gateways is to broker access to quality-controlled information resources. The means by which they make those resources (or descriptions of the resources) accessible for searching and/or browsing relies generally on a database or directory searching protocol like Z39.50 or WHOIS++ which sits between the client application and the data store (database or directory). SDLIP is a competitor to these standards and provides an alternative way of making resources available for searching. Moreover, SDLIP may also be a way of providing a uniform method of accessing existing datastores which support other protocols. This may be of particular relevance for existing subject gateways that may wish to re-utilise their resource descriptions by making them available through alternative protocols in addition to those already in use.

References

[1] The Simple Digital Library Interoperability Protocol (SDLIP-Core)
http://www-diglib.stanford.edu/~testbed/doc2/SDLIP/

[2] Search Middleware and the Simple Digital Library Interoperability Protocol, A. Paepcke et al., D-Lib Magazine, March 2000
http://www.dlib.org/dlib/march00/paepcke/03paepcke.html

[3] Storage Resource Broker (SRB)
http://www.npaci.edu/DICE/SRB/

[4] MIX
http://www.npaci.edu/DICE/MIX/

[5] AMICO
http://www.npaci.edu/DICE/AMICO/

[6] NCSTRL
http://cs-tr.cs.cornell.edu/

[7] SDLIP DASL Transport Mapping
http://www-diglib.stanford.edu/~testbed/doc2/SDLIP/daslMapping.htm

[8] SDLIP CORBA Transport Mapping
http://www-diglib.stanford.edu/~testbed/doc2/SDLIP/corbaMapping.htm

[9] Implementations in Java
http://www-diglib.stanford.edu/~testbed/doc2/SDLIP/transportModuleJava. htm

Other Standards and Protocols
CIP	DC	LDAP	OAI
RDF	RSS	SDLIP	SOAP
WHOIS++	XHTML	XML	Z39.50