1. Toward an Open Architectural Framework for Digital Objects M. Cristina Pattuelli INLS 210-98 March 19, 2001

2. Overview  Kahn/Wilensky Framework (K/W) -Infrastructure for digital information services  Warwick Framework (WF) -Offer a conceptual foundation for an open architectural framework  Fedora -A project which implements key concepts from K/W and WF

3. Khan/Wilensky Framework Developers  Robert Kahn Corporation for National Research Initiatives (CNRI)  Robert Wilensky University of California at Berkeley May 1995

4. Kahn/Wilensky Framework Motivation To develop an infrastructure with open architecture for supporting a large and extensible class of distributed digital information services

5. Kahn/Wilensky Framework Architecture  The System  Digital Objects  Handle, Handle generators  Metadata, Key metadata  Repositories - RAP  Originators  Users  Global/Local naming authorities

6. Kahn/Wilensky Framework System Components Digital Object = data + key-metadata Metadata includes the Handle: primary global identifier of the Digital Object Handle = name of local name authority + locally unique string assigned by Handle generator

7. Kahn/Wilensky Framework Deposit a Digital Object 1.Originator of Digital Object requests Handle from a Handle Generator + Repository Name 2. Upon deposit, registration of Handle and Repository Name with a System of Handle Servers 3. Digital Object becomes Registered Digital Object

8. Kahn/Wilensky Framework Repository Repository is a network accessible storage system where Digital Objects may be:  Stored  Added to its collection  Accessed through the Repository Access Protocol (RAP) Repository contains properties record (metadata) for each of the stored Digital Objects

9. Kahn/Wilensky Framework Naming Conventions Repository has unique name assigned by a Global Naming Authority GNA assigns a name to a Local Name Authority LNA may use this name as a name of the Repository It may be extended to create new names by suffixing the name with “.” + a new unique name component

10. Kahn/Wilensky Framework RAP Each Repository must support the Repository Access Protocol (RAP) that allows for: Deposit of Digital Objects Access to Digital Objects by specifying the Handle + a service request type Related repository services Output of the service request is dissemination A dissemination maybe also be defined as the result of an access service request

11. Kahn/Wilensky Framework Access to a Digital Object Commands:  ACCESS_DO service request  DEPOSIT_DO service request  ACCESS_REF service request

12. Kahn/Wilensky Framework Implementation Designs for implementing key aspects of the K/W Framework:  Framework for Distributed Digital Object Services (FDDOS) – CNRI & DLRG/Cornell  Inter-Operable Secure Object Stores (ISOS) – CNRI & DLRG/Cornell & CCG/NCSA

13. Warwick Framework April 1996 - OCLC/UKOLN Warwick MetadataWorkshop (2 nd Dublin Core Metadata Workshop)

14. Warwick Framework Motivation 1.Need of architecture that will accommodate a wide variety of separately maintained metadata models 2. Need to insure extensibility of schemas

15. Warwick Framework Consensus was reached on:  A high-level infrastructure for aggregating and interchanging multiple metadata packages associated with a common resource  WF as the first practical approach to the effective integration of metadata into a global information infrastructure

16. Warwick Framework Architecture  Container-package architecture Users or software agents able to aggregate discrete packages in a conceptual container No assumption about the content of the packages Containers and packages have identifiers for cross-reference on another

17. Warwick Framework Package A metadata package may be:  simple = one of the metadata formats (Dublin Core, MARC record, digital signatures, terms and conditions, etc.)  indirect – reference to an external object by URIs  a container – a container may be itself a package, embedded in another container, no limit for this recursion

18. Warwick Framework Container Transient: is a transport object used for shipping metadata among repositories, clients, agents  Persistent: exists as a first-class object in the info structure, stored on servers, accessible via URI  Wrapped: within another object, the wrapper with a URI itself

19. Warwick Framework Container No matter what implementation, only an operation is defined for a container: return a sequence of packages in the container

20. Warwick Framework Container Container aggregates: 3 packages of metadata 1.Dublin Core record 2.MARC record 3.Terms and condition

21. Warwick Framework Architecture Advantages:  Consistency in aggregating and exchanging metadata  Extensibility via modularity (LEGO metaphor) - vs. redundancy and overlapping - additional elements to support local or discipline-specific requirements

22. Warwick Framework Architecture Advantages:  Interoperability across resources  Distribution for reference to external metadata types

23. Warwick Framework Implementation How to associate a container to a content is a matter of implementation

24. Warwick Framework Possible implementations  SGML -requires a DTD that can handle the container/package architecture  Distributed Objects CORBA  HTML  MIME

25. Warwick Framework HTML Limited implementation in HTML 2.0 Use of META tag for embedding metadata within the HEAD  Encoding for the value of the NAME attribute that groups a number of META tags into a single metadata set  LINK tag for: –Indirect linking to reference definition of a schema –Indirect linking to a single set

26. Warwick Framework MIME Suitable for the encapsulation and transport of metadata + data Exploits:  multipart type which is used for messages that include multiple components  the body parts of a MIME multipart message already correspond to the packages in WF  content-type message/external-body can be used “for indirect package”

27. Warwick Framework MIME Advantages: -Well-established standard for transmitting and storing docs -Composed of multiple objects - Large body of code available - Registration mechanism for handling new content already exists - Implementation experience

28. Warwick Framework Strengths Simplicity of the design WF can be expressed in the context of existing WWW

29. Warwick Framework Open Issues  Users understanding of semantic interaction of overlapping metadata sets  No provision about the order of the members of the sequence  Reliable identifiers implementation  Registry agency

30. Warwick Framework Open Issues  Data encoding problems: - syntax for packages transfer - syntax for the package itself  Repository “access” - protocol for retrieval - efficiency in access/retrieval operation

31. Beyond Warwick Framework  Metadata = Data  WF container as an aggregator of inter-related datasets  Need to make relationships between packages become explicit

32. Beyond Warwick Framework Warwick Framework Catalog -Warwick Framework Catalog as a way to describe the relationships between packages -Relationships become first-class resources with description and access control of their own -WF container of Digital Library Objects

33. Beyond Warwick Framework Digital Library Object DLObject = Aggregations of datasets + relationships expressed by WFC no local restriction on the package a package may either be - physically in a container - indirectly referenced via a URI

34. Beyond Warwick Framework Digital Library Object

35. Beyond Warwick Framework DAR Distributed Active Relationships (DAR) Rich conceptual structure for:  explicitly expressing the relationships between networked resources  allowing those relationships to be dynamically downloadable and executable

36. FEDORA Flexible and Extensible Digital Object and Repository Architecture Developer  Digital Library Research Group at Cornell University - A DARPA funded project

37. FEDORA Related Projects  Digital Object Repository for the LC Digital Library Initiative Implemented by the Corporation for National Research Initiatives (CNRI)  Digital Service Model A part of the Making of America Project (MOAII)

38. FEDORA Motivation  To develop a repository architecture for storing and disseminating digital library content An interoperable, distributed repository service for providing uniform access to complex, compound, dynamic content types digital library objects distributed among multiple repositories.

39. FEDORA Theoretical Foundations  Concepts from Kahn/Wilensky Framework  Extension of Warwick Framework  Notions of Distributed Active Relationships (DAR)

40. FEDORA Architecture Key Features:  Supporting heterogeneous data types  Accommodating of new emerging types  Aggregating mixed, distributed data into complex objects  Specifying multiple content disseminations of digital objects  Associating rights management schemas

41. FEDORA Components Architectural abstractions:  Digital Object – Data Stream  Repository  Disseminator -- Disseminations

42. FEDORA DigitalObject-DataStream DigitalObject: container abstraction for heterogeneous content Multimedia content expressed in MIME--typed byte stream packages called DataStream DataStream: building blocks for aggregating content in DigitalObjects -- local = physically associated with the DO -- remote = logically associated with the DO, actually stored in another DO

43. FEDORA Repository Repository: logical service  To deposit  To store  To replicate/move/delete  To access DigitalObjects identified by URNs  Object lifecycle management  Secure environment for running mobile code

44. FEDORA RAP Access to the functionality of the architecture is expressed through Repository Access Protocol (RAP) that defines an open interface to the Repository functions

45. FEDORA Disseminator Disseminator: a component that associates an extended set of service requests with a DigitalObject to produce disseminations The PrimitiveDisseminator is common to all DigitalObjects Other Content-Type Disseminators can be associated with DigitalObjects

46. FEDORA PrimitiveDisseminator A set of basic behaviors logically associated with every DigitalObject:  to create and access DataStreams  to manipulate the structure of the DigitalObject Primitive Disseminator Content Type Disseminator

47. FEDORA DigitalObject application/ postscript application/ MARC Primitive Disseminator Structural Kernel Content-Type Wrapper

48. FEDORA Content Type A set of behaviors that formally describes the functionality of any global or domain-specific notion of content. E.g., Content Type: Book Operations: getTableofContent, nextPage Client interacts with the DigitalObject through its Content Type

49. FEDORA Disseminations  Direct transcription of stored data (e.g., a page of a book)  An interactive object (e.g., a book viewing applet)  Any computable derivation of stored content  Any mixture of these

50. FEDORA Disseminations Dublin Core Book MARC ToC DataStream (MIME-typed byte stream)

51. FEDORA Content-Type Disseminator  Identifies a particular content type and a set of DataStreams to be used as arguments when executing the service requests that define the type.  Clients don’t speak directly to a Content-Type Disseminator  The PrimitiveDisseminator acts as a “gateway” to the content-Type Disseminator

52. FEDORA Content-Type Disseminators Eg. By issuing the ListDisseminatorTypes requests, a client can obtain a list of all contect types associated with the DO.

53. DAR in FEDORA  DAR abstraction makes possible to specify disseminations from content aggregations  DAR is the basis for implementing FEDORA components called “Interfaces” and “Enforcers” which are linked to Digital Objects

54. FEDORA Interfaces & Enforcers  INTERFACES define relationships and behaviors and are attached to DOs to enable them to produce DISSEMINATIONS of their content packages  ENFORCERS are a special type of interface that protect “intellectual content” in a DigitalObject

55. FEDORA Architecture

56. FEDORA Implementation  FEDORA implementation uses CORBA distributed object model. Interfaces are defined using CORBA’s Interface Description Language (IDL)  FEDORA is also being developed in Java using CORBA ORBs, Iona’s OrbisWeb for Java and Visigenic’s VisiBroker

57. FEDORA Implementation UVA Digital Library Initiatives (2000) -FEDORA provides a modular and flexible architecture to handle a variety of complex multimedia entities, such as electronic texts with multi-level references

58. FEDORA UVA Technical Customized mechanisms to support UVA specific notion of content:  Signatures (DisseminatorType) for particular content abstractions  Servlets as an executable program for implementing Signatures

59. From K/W to FEDORA Synopsis Kahn/WilenskyExtended WFFEDORA Data & MetadataPackageDataStream Digital ObjectContainerDigitalObject DisseminationDARInterface Terms & Conditions DAREnforcer RepositoryContainerRepository