---
title: 'Fedora: Digital Repository Architecture'
url: https://www.emergentmind.com/topics/fedora
type: topic
---

# Fedora: Digital Repository Architecture

Fedora is a digital object and repository architecture for storing, managing, and disseminating digital library content. It is presented as the **Flexible Extensible Digital Object and Repository Architecture**, and as an extensible framework for the storage, management, and dissemination of complex objects and the relationships among them. Fedora accommodates the aggregation of local and distributed content into digital objects, the association of services with objects, and the production of several accessible representations, some of them dynamically produced. Its architecture includes a generic RDF-based relationship model, an RDF triple store for relationship queries, and web-service exposure through REST and SOAP interfaces; the implementation was made available as open-source software for digital libraries, archives, institutional repositories, and learning object systems [0501012].

## 1. Concept and architectural position

Fedora was proposed to provide a reliable and secure means to store and access digital content while also supporting extensibility and interoperability. In the earlier architectural formulation, it occupies the digital object and repository service parts of a broader layered digital library architecture that also includes repository services, index services, collection services, naming services, and user interface services. The central design problem is not simple file storage, but the need to support heterogeneous data types, the accommodation of new types as they emerge, the aggregation of mixed, possibly distributed, data into complex objects, multiple content disseminations, and the association of rights management schemes with those disseminations [1312.1258].

The architecture was originally developed as a research project at Cornell and later prototyped at the University of Virginia. The Mellon-funded phase aimed to turn that research architecture into a robust, open-source, web-native implementation suitable for large, heterogeneous digital collections. In that account, Fedora is described as a digital object repository architecture designed to manage, preserve, and deliver digital library content in a way that is flexible, extensible, and interoperable, with the repository itself serving as the core digital library service layer [1312.1385].

A common misconception is to treat Fedora as merely a storage substrate. The design documents explicitly reject that interpretation. The repository is not merely storage; it is a service environment for creating, maintaining, discovering, and disseminating digital objects. This emphasis on repository services, rather than file persistence alone, is one of the persistent features across the architectural descriptions [1312.1385].

## 2. Digital object model

Fedora’s digital object model separates structure from behavior. In the earlier formulation, a **DigitalObject** has a structural kernel and an interface or behavior layer. The structural kernel contains **DataStreams**, defined as typed byte streams that preserve internal format and encoding while allowing generic treatment within the DigitalObject, together with a **Primitive Disseminator** that provides the basic service interface common to all objects. The interface layer contains content-type **Disseminators**, which expose semantic behaviors such as book, journal, or Dublin Core. This model allows the same object to contain heterogeneous content without forcing a fixed document taxonomy [1312.1258].

In the Mellon-era formulation, a digital object contains a **Persistent Identifier (PID)**, one or more **datastreams**, one or more **disseminators**, and **system metadata**. The object aggregates both content and behaviors or services. This is a major architectural point: Fedora digital objects are not just files or records; they also carry the means for accessing and transforming themselves. The repository therefore manages both stored content and the access behaviors bound to that content [1312.1385].

Fedora was explicitly designed to support heterogeneous content and evolving content types. Examples given for datastream content include GIF images, MARC records, Dublin Core metadata, PostScript documents, audio, geographic data, ACLs, MPEG video, XML metadata, and references to external data. The architecture also supports **ReferenceDataStreams**, which may point to external data, disseminations of other Fedora objects, or remote services. This suggests an object model intended for aggregation across both local and distributed resources rather than for isolated records only [1312.1258; 1312.1260].

An important consequence is **functional equivalency**. Two objects may differ in internal representation yet expose the same behavior definition and therefore support the same access methods. The canonical example contrasts a digital object containing four image datastreams at different resolutions with another containing one wavelet-encoded image datastream; both can subscribe to the same behavior definition and therefore behave equivalently to clients [1312.1385].

## 3. Dissemination, services, and interfaces

A defining Fedora concept is the **dissemination**, described as a stream of data that manifests a view of the digital object’s content, or more generally as a view of the information contained within the DigitalObject. Disseminators package the service requests that release disseminations from the object. This makes multiple representations a first-class property of the architecture rather than an application-specific add-on [1312.1385; 1312.1258].

In the web-services implementation, a disseminator subscribes to a **behavior definition**, uses a **behavior mechanism**, and binds that mechanism to the object’s datastreams. The behavior definition is abstract and specifies the methods; the behavior mechanism is concrete and is the service implementation. Fedora therefore supports distributed services because the object need not contain the actual code. Instead, it contains references to service definitions and implementations. Examples include image methods such as `GetThumbnail` and `GetHighResolution`, course-content methods such as `GetSyllabus` and `GetLectureVideo`, and transformations such as translation between languages [1312.1385].

The implementation exposes repository functions through **API-M** and **API-A**, described as Fedora Management and Fedora Access services. These services are described using **WSDL** and support both **HTTP GET/POST** and **SOAP**. This web-native exposure replaced the earlier Cornell research implementation’s reliance on CORBA, and it aligned Fedora with XML and Web services as the main integration technologies. XML is used to encode digital objects, express metadata, support structured repository communication, and provide the underlying format for object storage and exchange; the implementation adopts **METS** as the XML schema for Fedora digital objects [1312.1385].

Fedora also supports component versioning. The Mellon system versions **datastreams** and **disseminators**, preserves earlier instantiations of both content and services, and uses audit trail records rather than multiple full copies of an object. Historical states can be retrieved through a date-time-stamped `GetDissemination` request. This versioning strategy reinforces the view of Fedora objects as durable, stateful entities whose content and behavior both evolve over time [1312.1385].

## 4. Relationships, RDF, and interoperability

Relationship modeling is one of Fedora’s most distinctive architectural features. The 2005 architecture explicitly includes a generic RDF-based relationship model representing relationships among objects and their components, with queries supported by an RDF triple store [0501012]. In the earlier FEDORA formulation, the architecture was already compatible with **Distributed Active Relationship (DAR)** abstractions, allowing relationships between resources in different repositories, executable relationships, and relationships that are themselves named entities [1312.1258].

This relationship-centric design later became the basis for higher-level systems. In **NCore**, Fedora serves as the persistence and relationship layer for a flexible, collaborative digital library. NCore is built on top of a central Fedora-based repository and extends Fedora’s underlying relationship architecture using Semantic Web-style RDF triples. Its first-class object types—resources, metadata, aggregations, metadata providers, and agents—depend on Fedora’s open architecture and highly flexible relationship model. The NCore work emphasizes that Fedora is powerful as repository and middleware, while NCore adds a library-oriented data model, organizing relationships, and end-user services [0803.1500].

Fedora’s interoperability role is also visible in cross-repository work. The **Pathways** experiment describes an interoperability framework that enabled the workflow involved in the creation of an overlay journal over several different repository systems, specifically **Fedora, aDORe, DSpace and arXiv**. The stated premise is that cross-repository interoperability should be augmented through a service architecture rather than by promotion of a single repository architecture or content representation [0610031]. A plausible implication is that Fedora’s object and service model made it suitable as one participant in heterogeneous scholarly repository workflows.

## 5. Rights management, policy, and workflow integration

Rights management is built into the architecture through the **AccessManager**, the entity that attaches a rights-management mechanism to a Disseminator. The AccessManager can control whether a service request may be invoked, how the result is delivered, and what transformations occur before delivery. The earlier paper’s example is a book dissemination that might charge five cents per page before allowing `getPage`, while also applying a digital watermark to the returned page. Rights-management mechanisms themselves are treated as named, storable, disseminable content objects [1312.1258].

Later work argued that repository-level access control is too coarse for Fedora objects, because Fedora objects often have item-specific behaviors and context-specific usage rules. The **policy-carrying, policy-enforcing digital object** model extends Fedora so that a digital object can carry its own policy and enforce that policy on the behaviors it exposes. In the reported experiments, a Fedora object includes both a default policy for generic API methods and a content-specific policy attached to a particular behavior interface. Fedora was integrated with **PoET**, an implementation of security automata and in-lined reference monitors for Java, so that the repository’s Mechanism Manager retrieves a behavior’s code module and sends both the code and the relevant policy to PoET for just-in-time bytecode modification [1312.1260].

Fedora also served as a repository back end for configurable submission workflows. The **eSciPub** prototype combined **jBPM**, **JSF/JSP**, **MySQL**, and a **SOAP minimal binding stub** with a Fedora Repository back end. The prototype is described as a service-oriented, 4-tier architecture in which workflow logic and repository management remain loosely coupled. Submission begins by creating a new Fedora object through `API-M`, receiving a PID, and storing that PID as a workflow process variable; later steps update metadata through `modifyDatastreamByValue` and store article files through `modifyDatastreamByReference` or `addDatastream` [0706.0306]. This use illustrates how Fedora’s object model and SOAP interfaces supported external workflow engines without collapsing workflow state into repository internals.

## 6. Implementation trajectory, deployment, and significance

The implementation trajectory moves from an initial CORBA and Java prototype to a web-services-based architecture using XML, WSDL, METS, HTTP GET/POST, SOAP, and open-source release. The Mellon project planned evaluation using a diverse set of digital collections, including digital images, numeric data, XML objects, TEI-encoded texts, art and archaeology collections, social science datasets, and born-digital humanities projects such as the Salisbury Cathedral project and the Rossetti Archive. Deployment partners included Indiana University, New York University, Tufts University, King’s College London, Oxford University, the Library of Congress, and Northwestern University [1312.1385].

The Virginia prototype was stress-tested with Apache JMeter. Reported results were about **0.5 seconds per request** for **20 simultaneous users** on a Sun Ultra80 two-processor machine, and about **1.5 seconds per transaction** when scaled to **1,000,000 to 10,000,000 objects** on a four-processor dedicated server. These figures were used as benchmarks for the Mellon implementation [1312.1385].

Fedora’s significance is also visible in production-scale platforms. In the NSDL deployment described for NCore, the Fedora-based **NSDL Data Repository** supported 7x24 operation, Fedora-level transaction journaling, replicated follower systems, and large-scale ingest through OAI-PMH harvesting. As of **January 21, 2008**, the repository contained **3.02 million resource objects**, **2.3 million metadata objects**, **990 aggregation objects**, and **816 agents** [0803.1500]. This does not demonstrate Fedora in isolation; rather, it shows that a Fedora-based repository could function as the central technical infrastructure for a major digital library.

Across these formulations and deployments, Fedora’s durable architectural idea is the combination of object aggregation, behavior binding, relationship modeling, and repository services. The architecture treats digital objects as content-plus-services, represents inter-object structure through RDF-based relationships, supports multiple disseminations and rights mechanisms, and exposes repository functions through standard web protocols. Its later extensions in policy enforcement, workflow integration, and higher-level platforms suggest that Fedora was designed less as a fixed application than as a repository substrate for heterogeneous, distributed, and evolving digital library systems [0501012].

Source: https://www.emergentmind.com/topics/fedora