UserPreferences

ScholarsBox/TechnicalSpecification

  1. Pieces of the puzzle
    1. (1) web browser interface
    2. (2) web services interface
    3. (3) inputs
    4. (4) products
    5. (5) transformation services
    6. (6) digital libraries/archives
    7. (7) individual scholars and personal repositories
    8. (8) destination for products
  2. Infrastructure: A Wish List
  3. Abstraction Framework vs Specific Implementations
  4. Other work to consider

A schematic diagram for describing the overall architecture:

IU_Tech_Architecture_Diagram_2004_03_14

We seek an architecture that is flexible, extensible, and portable to support the functionality of the Scholar’s Box. The diagram below presents a schematic view of this architecture. Content flows into the Scholar’s Box from two types of sources: digital libraries and archives (6 on the diagram) and content from individuals or teams of scholars (7 on diagram). We distinguish between these two categories because the architectures required to support them are different. Digital libraries and archives typically are backed by full databases holding materials with their associated metadata, accessible through persistent handles. Materials produced by individual faculty and departments may need various forms of structuring to be made accessible.

End-users will have access to the Scholar’s Box through the traditional browser interface (HTML or DHTML) (1 on diagram). However, the Scholar’s Box will also be designed to interface with computer agents. Programs (desktop and other web apps) that use an XML-RPC /SOAP interface will be able to communicate with the Scholar’s Box (2 on diagram). Output and input will be carried in XML packets.

A key element of the design of the Scholar’s Box is to determine the type of content that will flow in and out the Scholar’s Box: what type of scholarly materials (inputs) have to be handled and what do users want to be able to produce (products) from the input materials (3 and 4 on diagram). Internally, the Scholar’s Box is an XML data store, with an extensible workflow system that enables input materials (which themselves may not be XML) to be transformed into desired products (5 on diagram). Such workflow is instantiated as an extensible set of tools that act on the data. Although the detailed design of the Scholar’s Box must still be carried out, there are good models from which to learn. In particular, Groove and Jabber illustrate how XML can be successfully integrated, routed, and manipulated at various places in a technology architecture. We believe the movement and manipulation of XML based content packets will be a critical issue for the development of the Scholar’s Box.

Pieces of the puzzle

(1) web browser interface

We will likely want to build the ScholarsBox as both a desktop client and as a web-accessible tool. Actually, as a desktop client, it will likely have a native UI

(2) web services interface

(3) inputs

(4) products

(5) transformation services

(6) digital libraries/archives

(7) individual scholars and personal repositories

(8) destination for products

Infrastructure: A Wish List

  1. Unified object models for all data

  2. Object dis-aggregator and re-aggregator functionality

  3. A UniversalCanvas for composing and authoring of multimedia documents

  4. Translators among data and metadata schemes

  5. Integrated handlers for many protocols: SOAP, XML-RPC, Z39.50, HTTP, SMTP and inter-application communication

  6. Hooks into groupware, P2P and centralized file sharing for sharing of content

Abstraction Framework vs Specific Implementations

The Scholar's Box abstraction framework allows the separation of logic and intelligence common to all implementations from implementation-specific details. This document will guide the implementation of the Scholar’s Box tool in other environments, enhancing its adoption and adaptability across institutional and technical contexts. In its most general formulation, the Scholar's Box allows users to (1) gather digital objects (of varying formats) and organize them into collections, and (2) transform them into other digital objects (through services). The Scholar's Box does not, of course, magically handle every format and implement every service. Rather, it can be systematically extended (programmed) to handle a new format or service. This framework is geared to enable practical interoperability in a sea of data heterogeneity as seen from the end-user of cultural digital objects.

Specifically, the Scholar's Box allows for the aggregation of complex (multipart) and simple objects; disaggregation of collections and complex objects into constituent pieces (because people often want pieces); reassembly of parts from multiple source objects into new objects; the association of metadata with digital objects; the interconversion of digital object types and their metadata; and the implementation of crosswalks among metadata systems. The disaggregation and reformation must take place while preserving key aspects of the original context of the materials. Although the Scholar's Box can conceivably be programmed to handle arbitrary transformation of digital objects, it is not meant to replace specialized authoring or viewing tools but work with them to leverage their functionality.

Other work to consider