On the Effective Manipulation of Digital Objects

1. 9th European Conference on Research and Advanced Technology for Digital Libraries (ECDL 2005) On the Effective Manipulation of Digital Objects A Prototype-based Instantiation Approach Kostas Saidis, George Pyrounakis, Mara Nikolaidou Libraries Computer Center Department of Informatics & Telecommunications University of Athens

2. Outline • Motivation – The University of Athens (UoA) DL • Digital Objects (DOs) • Encoding & Storage • Manipulation (DL Application Logic) • Manual Handling of DO Type variations • Digital Object Prototypes • Automatic DO Type conformance • Digital Object Dictionary • A 3-tier DL Architecture • Collection Management & Scope of Prototypes • Open Issues & Future Work

3. The UoA DL Project • Over 1 million objects originating from 8 different collections • Folklore notebooks, Ancient papyri, Historical archive’s folders & documents, Byzantine music manuscripts, Theatrical photos & brochures, Informatics research papers and dissertations, Medical images, Press articles • Heterogeneous & (mostly) digitized material • We are developing a Web based DL System for all material, using FEDORAas a digital object repository

4. Motivation • Increase productivity (strict time limits) • Simplify & speed up the cataloging process • Provide effective Web-based cataloging interfaces (cataloging personnel not librarians) • Decrease development time (small team) • Avoid custom coding for each content variation • Elaborate on reusable and configurable DL modules • Treat content variations in a unified manner

5. Digital Objects • A Digital Object is a human generated artifact consisting of the digital content and related information • Digital Content (files) • Metadata (descriptive, administrative, etc) • Structure & Reference information • Behaviors (DO related functionality)

6. Abstract Representation of a DO

7. Encoding & Storage of DOs • Several XML-based standards support various forms of digital content & metadata (METS, FOXML, MPEG21, RDF…) • METS • Sections, Behaviors, Profiles • FEDORA Digital Object Model • METS variant in version 1.x • Fedora Object XML (FOXML) in 2.x • Datastreams, Disseminators, Content Models • Focus on how each DO part is encoded & stored

8. Manipulation of DOs • In the context of DL Application Logic, DOs should be manipulated in a higher level of abstraction • Focus on the overall behavior of the DO (what are the DO parts and how do they behave) • DO Manipulation depends on the nature of the DO – the DO reflects the underlying “real world” object

9. 2-tier DL Architecture

10. DL Application Logic • A DL Module performs the following steps: • Loads the DO and its required parts • Parses XML and puts the data in the appropriate memory data structures • Performs operations on the data • Serializes the data in XML format • Saves the DO and its parts to the repository • Steps 1, 2, 4, 5 require different implementations for each DO Type

11. DO Types? • Do we capture, express and use DO Typing information in an effective manner? • METS “Profiles” & FEDORA “Content Models” model DO Types… • … but their goal is to be used by humans as a guide and not by the DL System as a DO type specification • We resolve DO Typing issues manually

12. Manual Handling of DO Types • Developers generate ad-hoc, custom & not reusable implementations of DO types’ variations of behavior • Catalogers carry out manual XML editing in a low level of abstraction with too technical, complex & over detailed semantics • DL modules exhibit limited evolution and configuration capabilities (due to scattered code and strong couplings & interdependencies)

13. Position The DL System should resolve DO Typing issues automatically (in a manner transparent to the DL Application Logic)

14. An example – Theatrical Collection • What is an Album DO? • A container of photos accompanied by theatrical play metadata • What is a Photo DO? • A digital image • stored in various formats (e.g high quality, www quality, thumbnail) • accompanied by the metadata required for describing the picture • How can we make Album and Photo DOs behave as such, automatically?

15. By Drawing on the notions of OO

16. The OO Viewpoint • In the OO model an object is itself aware of its “nature” and behaves accordingly • Objects are conceived as instances of a type, automatically conforming to the type’s definitions & specifications • OO types are separate entities (named either classes or prototypes)

17. Digital Object Prototypes • A DO Prototype is a DO Type Specification, a separate entity that defines the DO’s: • Constitutional parts – metadata sets, files, structure, etc • Private behaviors – DO internal operations such as serializations, validations, assignment of default values, content conversions, etc • Public behaviors (behavior schemes) – the DO external interface, consisting of high level operations such as Detail view, Browse View, Edit View, etc

18. OO Encapsulation

19. Photo Prototype & Instances

20. Digital Object Instances • The process of generating a DO from a Prototype is called instantiation • The resulted object is an instance of the prototype • A DO instance automatically conforms to the Prototype’s specifications • Stored DOs vs DO instances

21. 3-tier DL Architecture

22. Digital Object Dictionary • The runtime environment in which DO instances and Prototypes operate • The DO Dictionary • Instantiates a DO based on the prototype specifications (loads & parses XML, assigns default values, etc) • Exposes the public behaviors of DOs in a high level, uniform API (for use by DL Modules) • Saves the DO instance (serializes data structures in XML, performs validations, etc)

23. 3-tier DL Architecture Separation of Concerns

24. 3-tier DL Architecture Separation of Concerns Storage

25. 3-tier DL Architecture DO Typing & Instantiation Separation of Concerns Storage

26. 3-tier DL Architecture Composition of DO behavior DO Typing & Instantiation Separation of Concerns Storage

27. DL Application Logic Revisited • A DL Module performs the following steps: • Acquires the DO Instance do = dictionary.acquireObject(“type”) do = dictionary.acquireObject(“uoadl:1024”) • Performs operations on its data do.getMDSet(“DC”).getField(“title”) dictionary.executeBehavior(do, “editView”) • Stores the DO in the repository dictionary.saveObject(do)

28. Scope of Prototypes • Should we have global DO Types? • Collection-pertinent types: A DO Prototype is defined in the context of a Collection • Support fine grained definition of collection specific kinds of material • Hierarchical naming scheme for types • Theatrical Collection Photo: dl.theatre.photo • Medical Collection Photo: dl.medical.photo • Avoid type collisions

29. Album Prototype & Instances

30. Collection Management • DL = Hierarchy of DO instances • Collections are also DOs, conforming to the Collection Prototype • The DL itself is a DO, representing the “super-collection” (the collection of all the collections) • All content is modeled in a unified manner • All content can be characterized • Easily add new collections & sub-collections • Allow the DL designer to work out the details of each collection independently, yet in a uniform manner

31. DL as a Hierarchy of DO instances

32. Open Issues & Future Work • OO Inheritance for DO Prototypes (e.g the Notebook type derives from the Book type) • OO Polymorphism for DO instances (e.g the DO “uoadl:1234” is both a Notebook & a Book) • Generalize the notion of behavior schemes & investigate relations with FEDORA behaviors • Supply general purpose linking capabilities that exceed structural relations • Deliver on schedule…