1 / 47

Alternative Architecture for Information in Digital Libraries

Alternative Architecture for Information in Digital Libraries. Onno W. Purbo Onno@indo.net.id. Reference. http://www.dlib.org/dlib/february97/cnri/02arms1.html

zazu
Download Presentation

Alternative Architecture for Information in Digital Libraries

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Alternative Architecture for Information in Digital Libraries Onno W. Purbo Onno@indo.net.id

  2. Reference • http://www.dlib.org/dlib/february97/cnri/02arms1.html • William Y. Arms, Christophe Blanchi, Edward A. Overly, “An Architecture for Information in Digital Libraries,” Corporation for National Research Initiatives Reston, Virginia, February 1997.

  3. The Structure of Information • Digital data  digital library. • Digital objects • Metadata • Unique identifier (handle). • Group of digital objects  set of digital objects. • Different type of material  categories.

  4. Components of Comp System

  5. Work Flow Example • Search • Z.39.50 – list of digital objects identified by handle. • Select • Retrieval • Resipository Access Protocol (RAP) • Display

  6. Information Architecture

  7. Structure of Info in Digi Lib • Relationship (chapter, index) • Format (SGML, HTML) • Version • Right & Permission • Computer System & Network (dialup vs. broadband).

  8. Basic Principles • User & app. Program must be flexible. • Collections must be straightforward to manage. • The information archirectire must reflect economic, social & legal framework.

  9. Data type, structural metadata • Data type – technical properties of data, format & processing. • Structural metadata – type, version, relationship of digital material. • Meta-object – reference to a set of digital object.

  10. Guidelines for all categories • All data is given an explicit data type • All metadata is encoded explicitly • Handles are given to individual items of intellectual property • Meta-objects are used to aggregate digital objects • Handles are used to identify items listed in meta-objects

  11. An Example of the Use of Meta-objects • Scanned photographs • Digital objects for a scanned photograph • Digital objects for individual versions • Meta-object • Handles for scanned photographs • Depositing a scanned photograph

  12. Digital objects for a scanned photograph • Low resolution “thumbnail” • High resolution “reference” image

  13. Digital objects for individual versions • Key metadata. • used to manage the object in a networked environment. It includes the handle, and the rights and permissions associated with the digital object. • Structural metadata. • includes fields for description, owner, handle of meta-object, data size, data type (e.g., "jpg"), version number, description, date deposited, use (e.g., "thumbnail"), and the date of last revision. • Image data. • This is the image data.

  14. Meta-object • Key metadata. • includes the handle, and the rights and permissions associated with the digital object. • Structural metadata. • includes a description, the owner, the number of versions, the date deposited, the use ("meta-object"), and the date of last revision. • Data about each version. • For each of the three scanned versions (e.g., the thumbnail), there is a package of information including the handle of the version, and the relationship among the versions.

  15. Handles for scanned photographs • control identifier - 3a16116r.jpg • replace the control identifiers by handles, which provide a unique, persistent, location independent name for each item - loc.ndlp.amrlp/3a16116 • Terminology to describe handles: • "loc.ndlp.amrlp" is the naming authority • "3a16116" is a locally unique string • For convenience in processing, use sequence numbers • loc.ndlp.amrlp/3a16116.1 • loc.ndlp.amrlp/3a16116.2

  16. Meta object identifies 2 image

  17. Depositing a scanned photograph • Human • machine

  18. Depositing a scanned photograph - human • Selection of the material that will be made into each digital object. • Specification of the metadata for those fields that require judgment.

  19. Depositing a scanned photograph - machine • Creation of the meta-object and the links to other digital objects. • Depositing the digital objects in the repository. • Registering the handles in the handle system.

  20. Access to a scanned photograph • Bibliographic entries in search systems refer to the scanned photograph by the handle of the meta- object. • If a user requests a summary of the photograph, the "thumbnail" image is provided. • If the user requests access to the photograph without specifying which version, the "access" image is provided.

  21. Technical Information

  22. Digital Object

  23. Digital Object • Key-metadata • The key-metadata is the information stored in the digital object that is needed to manage the digital object in a networked environment -- for example to store, replicate, or transmit the object without providing access to the content. This includes terms and conditions, and the handle. • Digital material • The digital material (or data) comprises a set of sequences of bits.

  24. Digital Objects Internal Structure • An element is a bit sequence comprising an elementary unit of information. An element has its own ID. • A package is a collection of elements and other packages, with its own ID. • A digital object is a package with key-metadata for use in a networked environment. The ID is a handle.

  25. Data Element

  26. Data Element • Data element • A data element is any bit-sequence. • Element ID • The element ID is the internal identifier of the element within the digital object. Unlike a handle, which is unique and known publicly, the element ID is of local importance only. • Attributes • Attributes are the information that is needed to process the element. They include: a role, which defines the function of the element (such as "DTD" in the SGML world), and a type, which includes technical information (such as "jpeg").

  27. A Package

  28. Packages • Packages are used to group or associate elements and other packages. • A package has a package ID. • If the package is a digital object, the package ID is a handle. Otherwise, it is the internal identifier of the package within the digital object. Unlike a handle, which is unique and known publicly, such a package ID is of local importance only. The content of a package consists of elements and other packages.

  29. Handle & Handle System

  30. Handle & Handle System • The digital library is assembled from a great variety of components. They include people, computers, networks, repositories, databases, search systems, Web servers, digital objects, elements of objects, bibliographic records, and many more. Keeping track of these components requires a systematic approach to identification. • http://www.handle.net

  31. Typical handle record

  32. Handle record for web

  33. Handle System • To resolve a handle is to present a handle to the handle system and receive as a reply information about the item identified. • The handle system is a distributed computer system, with many computers distributed across the world. CNRI manages a global handle registry and there are local handle services operated by other organizations, e.g. http://www.handle.net/

  34. Naming Authority • Handles are created by naming authorities, administrative units that are authorized to create and edit handles.

  35. The Repository

  36. Structure of a Repository • A repository is a system for networked based storage and access to digital objects. • All interaction with the repository uses a simple protocol, known as the Repository Access Protocol (RAP). RAP has a small number of fundamental operations, such as "deposit", which stores a digital object in the repository, and "access", which provides access to a digital object. • Thus RAP provides a clearly defined, open interface for the repository that allows others to write clients and higher level interfaces.

  37. Structure of Repository

  38. Structure of Repository • Repository shell • The repository shell is the part of the repository that interfaces with the outside world. It implements the RAP protocol • Persistent store • Information in the repository is held in the persistent store. The persistent store is completely hidden from the outside. • Object management layer • The object management layer provides an interface between the services provided by the persistent store and the object oriented functions required by the repository shell.

  39. The Repository Access Protocol (RAP) • VerifyHandle. Confirm that a handle has been registered in the handle system. • AccessRepoMeta. Access the repository metadata. • Verify_DO. Confirm that a repository stores a digital object with a specified handle. • AccessMeta. Access the metadata for a specified digital object. • Access_DO. Access the digital object. • Deposit_DO. Deposit a digital object in a repository. • Delete_DO. Deletes a digital object from a repository. • MutateMeta. Edit the metadata for a digital object. • Mutate_DO. Edit a digital object.

  40. Handle system to access DO

  41. Example RAP Work Flow • The handle "loc.ndlp/1234" is sent to the handle system. It resolves to data type "handle" (HDL), value "loc/repos1". This is interpreted as information that the digital object is stored in the repository identified by the given handle. • The handle "loc/repos1" is sent to the handle system. It resolves to information of type "RAP". This is information that the repository implements RAP. The corresponding data is a reference to a CORBA Object Request Broker (ORB). • The command "Access_DO (loc.ndlp/1234)" is now sent to the repository.

  42. Benefit Using Handle • Since the digital object is identified by a handle, if it is moved to another repository the only change required is to alter the data in the first of the handle records in the figure. Since the repository is identified by a handle, if the repository is moved to a different computer or otherwise changed, but its handle remains the same, altering the single data item in the second handle record in the figure is the only change needed, for all the digital objects stored in the repository.

  43. User Interface

  44. User Interface System

  45. Client via CGI-BIN

  46. DO sets as hierarchies

  47. Hierarchies • Level 0: • contains the digitized image, sound, text, or other data. • Level 1: • is a parent of digital objects of Level 0. Upon encountering a digital object of this type, the digital object browser extracts the content of the all the child Level 0 digital objects and displays them in an indexed list to the user. This type has been used to display indexes of thumbnail images. • Level 2: • is a parent of digital objects of Level 1.

More Related