Dynamic Interoperation of Noncooperating Digital Libraries

1
Dynamic Interoperation of Non-cooperating
Digital Libraries

• R. Shi, K. Maly, and M. Zubair Department of
  Computer Science
• Old Dominion University
• DLOC2002, Beijing, July 10, 2001

2
Overview

• Introduction
• Background
• Architecture Design Enhanced LFDL
• Experimentation Implementation
• Conclusion Future Works

3
Introduction

• Many approaches for DL Interoperation
• Harvesting and distributed search
• Earlier work on LFDL Lightweight Federated
  Digital Library
• Universal search interface
• DL specification in DLDL
• DL registration
• Query mapping
• Limitations
• Search capabilities, QoS, performance
• Enhanced LFDL
• Interactive user-centered search

4
Background

• Levels of interoperability
• Technical protocol, format
• Contents data, metadata, messages
• Organizational rules for access, payment,
  authentication,
• General models
• Federation
• complete, but requires more from data providers
• Harvesting
• some efforts from both data and service providers
• Gathering
• Little from data providers

5
LFDL Introduction

• General principle
• Gathering and distributed search
• Lightweight both to data and service providers
• Basic solution
• Dynamic DL metadata registration
• Universal interface
• Dynamic Query mapping
• Efficient system management
• Local repository

6
LFDL Architecture
7
LFDL Services

• Registration service
• Metadata server
• Registration server
• Dynamic library proxy
• Rules engine
• Search service
• Search engine
• Result processing engine
• Management service
• DL removal, verification,
• Runtime info
• DL availability
• DL average response time
• Most often used queries
• System total hits

8
LFDL Design metadata specification

• DLDL in XML
• Structure
• General info on a digital library
• Mapping rules
• Access methods of the digital library
• Information to be retrieved from the digital
  library
• DTD
• All XML Specifications have a common Data Type
  Definition (DTD)
• Allows XML parser to check the validity of the
  XML specification and whether it is well formed
• Sample Specification for NEEDS (National
  Engineering Education Delivery System)

9
Limitations and Issues

• Limited search capabilities
• Static, simple interface
• Quality of service
• Precision/recall need to be improved
• Obstacles
• DLs have different interfaces and unique features
• Unique features were lost when using simple
  interface

10
Enhanced LFDL - Approach

• Simple vs. advanced search
• User friendly advanced search
• Approach
• User-centered interactive search
• Start from simple keyword
• Dynamic interface based on the keyword
• Dynamic query mapping based on interface

11
Enhanced LFDL - Design

• Keyword-driven dynamic interface
• Pre-defined keyword-hit set
• Base keyword set from OAI test-bed
• Generate keyword-hit set
• Interface generation
• Generic universal interface
• Based on Dublin Core
• Complete DL specification in DLDL
• Filter field type, name, values
• Mapping with UI field
• Allow DL unique features (no mapping)

12
Interface Generation Algorithm

• Factors
• Input keyword
• Generic base UI
• DL keyword-hit
• DL specification
• Algorithm
• Weight based DL features selection
• DL weight determined by keyword-hit
• Absolute feature weight within UI
• Relative feature weight within a DL
• User behavior from user features selection log
• Algorithm
• balance all weights
• select features with highest weight

13
Experimentation and Implementation - UI
14
Experimentation and Implementation keywords-hits

• ltFORMFIELDgt
•   ltREQUIRED Title"Required Field or
  not"gtYlt/REQUIREDgt
•   ltWEIGHT Title"Weight of Field"gt1lt/WEIGHTgt
•   ltTYPE Title"Search Criteria or Display
  Option"gtSearch Criterialt/TYPEgt
•   ltLABEL Title"Displayed Field
  Name"gtKeywordslt/LABELgt
•   ltLENGTH Title"Field Length"gt35lt/LENGTHgt
• - ltINPUTNAMEgt
•   ltINPUTNAME_VALUE Title"Internal Form
  Name"gtkeywordslt/INPUTNAME_VALUEgt
•   ltINPUTNAME_MAPPING Title"Mapped UI Field
  Name"gtUI_keywordlt/INPUTNAME_MAPPINGgt
•   lt/INPUTNAMEgt
•   ltINPUTTYPE Title"Form Type"gttext
  inputlt/INPUTTYPEgt
•   ltINPUTVALUE /gt
•   lt/FORMFIELDgt

15
Experimentation and Implementation Interface
for keyword html
16
Experimentation and Implementation Interface
for keyword university
17
Evaluation

• Test-bed
• Approach comparison
• System measurements
• Tools and reports
• Reference data for participants

18
Evaluation - Performance

• Hypothesis
• LFDL will perform better or at least equal to the
  sum of individual DLs
• Metrics
• User response time
• Cache hit rate
• Control variables
• Baseline Data
• Log files of existing DLs
• Experimental Design
• From baseline data calculate query locality,
  average response time
• Simulation and get LFDL average response time

19
Evaluation Quality of Service

• Hypothesis
• LFDL will produce better or at least equal
  quality of result set than the sum of the results
  from individual DLs
• Metrics
• Precision/Recall
• Control variables
• Baseline Data
• Log files of existing DLs
• Experimental Design
• From baseline data get result set of each DL
• Simulation and get precision/recall for LFDL

20
Conclusion and Future Works

• Federation service for non-cooperating DLs is
  possible
• Dynamic user-centered interface is practical to
  improve quality of service
• Future works
• Usability domain oriented, post-processing
• Complex interface mapping, access control
• Scalability, and performance
• Automatic specification generation