-
The Fedora Digital Object Model
All Fedora objects conform to the Fedora digital object model which is described in detail elsewhere (Fedora publications). Briefly, the Fedora object model consists of:
- PID - a persistent, unique identifier for the object
- Datastream(s) - the component in a Fedora object that represents MIME-typed content. An object can have one or more Datastreams. The content of a Datastream can be either data or metadata, and this content can either be stored internally in the Fedora repository, or stored remotely (in which case Fedora holds a pointer to the content in the form of a URL).
- System Metadata - a set of system-defined attributes that are necessary to manage and track the object in the repository.
- Disseminator(s) - the component in a Fedora object that associates a service with the object for the purpose of transforming or presenting the content represented by Datastreams. An object can have zero or more Disseminators. Each Disseminator points to a Behavior Definition and a Behavior Mechanism. A Behavior Definition defines an abstract set of methods to which the object is said to “subscribe.” A Behavior Mechanism defines the concrete bindings to a service that implements the abstract methods of the Behavior Definition.
-
Three Types of Fedora Digital Objects
Although every Fedora digital object conforms to the Fedora object model, as described above, there are three distinct types of Fedora digital objects that can be stored in a Fedora repository. The distinction between these three types is fundamental to how the Fedora repository system works. Basically, in Fedora, there are objects that store digital content entities, objects that store service descriptions, and objects that store service binding information.
Data Objects
In Fedora, a Data Object is the type of object used to represent a digital content entity. Data Objects are what we normally think of when we imagine a repository storing digital collections. Data Objects can represent such varied entities such as images, books, electronic texts, learning objects, publications, datasets, and many other entities. One or more Datastreams represent the parts of the digital content entity. One or more Disseminators represent services that can present different views or transformations of the content entity.
Behavior Definition Objects
In Fedora, a Behavior Definition Object is the type of object used to represent an abstract service definition in the form of an abstract set of methods. This is similar to the notion of an interface in Java. From the Fedora perspective, a Behavior Definition Object defines a “behavior contract” that one or more Data Object may “subscribe” to. A Data Object is said to subscribe to a particular behavior contract when its Disseminator points to the PID of a given Behavior Definition Object.
Behavior Definition Objects are stored in the repository just like other Fedora objects. Although the Fedora repository system is able to identify Behavior Definition Objects as special “utility” objects, it stores and manages them just like Fedora Data Objects. Also, clients can access these objects in the same manner they access Data Objects.
Behavior Mechanism Objects
In Fedora, a Behavior Mechanism Object is the type of object used to represent a concrete service definition. From the Fedora perspective a Behavior Mechanism Object represents a service that fulfills the requirements of a behavior contract defined by a Behavior Definition. The combination of a Behavior Definition and Behavior Mechanism constitutes a Disseminator on a Data Object. Together, they provide the means for associating a set of behaviors with a Fedora Data Object.
For a Disseminator to work, a Data Object must be associated with particular service that is an “implementation” of a behavior contract it to which the object “subscribes.” Thus, a Data Object’s Disseminator not only points to the PID of a given Behavior Definition Object, it also points to the PID of particular Behavior Mechanism Object.
A Behavior Mechanism Object stores several forms of metadata that describe a set of methods and the runtime bindings for invoking these methods. The most significant of these metadata formats is service binding information encoded in the Web Services Description Language (WSDL). Fedora uses WSDL to “normalize” the view of a service. This enables Fedora to talk to a variety of different services in a predictable and standard manner. It also contains metadata that defines a “data contract” between the service and any object that associates with the service. The data contract (also known as the “Datastream Input Specification”) specifies the kind of datastreams that must be available in the data object to serve as input to the various methods of the service. Given that a typical use of a service is to transform or present the datastream content of a Data Object, it is necessary to define datastreams as “input parameters” to the service methods.
Behavior Mechanism Objects are stored in the repository just like other Fedora objects. Although the Fedora repository system is able to identify Behavior Mechanism Objects as special “utility” objects, it stores and manages them just like Fedora Data Objects. Also, clients can access these objects in the same manner they access Data Objects.
-
Application Programming Interface for Object Creation (API-M)
Digital object construction is achieved via the methods of the Fedora Management API (API-M). The Management API exposes methods to ingest objects into the repository, as well as methods to create objects interactively. For a detailed description of each of the methods in API-M, see the specification at http://www.fedora.info/definitions/1/0/api/. The API is also expressed in the Web Services Description Language (WSDL) and is available at http://www.fedora.info/documents/Fedora-API-M.wsdl
-
Creation of Data Objects (3 ways)
XML Submission (Ingest)
- Process summary: An XML submission package is prepared outside of Fedora. This can be done manually with an XML editor, or programmatically. The submission package is sent to the Fedora repository for “Ingest” via one of the Fedora clients that support the ingest function.
- XML submission format: A Fedora-specific extension of METS 1.0. See rules for encoding Fedora objects in METS below.
- Clients for ingest:
- Admin GUI - From the menu select File/Ingest. You will be prompted to select a file from the file system so make sure your submission package XML file is on a drive that is visible from the machine on which the Admin GUI is running. For more details, see the guide entitled “Java Application: Admin GUI– Object Creation and Repository Management via API-M” in the Client Documentation.
- Batch Loader via Admin GUI - From the menu, select Tool/Batch/IngestBatch. This will provide a means to select a target directory where one or more METS submission packages reside. Multiple objects can be loaded via this utility. See the guide entitled “Admin GUI - Batch Utility for Object Creation” in the Client Documentation.
- AutoIngester Script
Interactive Building
- Process summary: A user can create a digital object through a visual metaphor using the Admin GUI java application. The Admin GUI provides a New Object command and an Object Editor that can be used to edit objects.
- Clients for interactive building:
- Admin GUI - From the File menu, select New, then Object.
Batch Loading
- Process summary: Batches of similar objects can be created by defining a set of templates and targets. This is fully described in the Client Documentation section of the Fedora documentation.
- Clients for batch loading:
- Admin GUI - From the menu, select Tools/Batch. For more information see the guide entitled “Java Application: Admin GUI - Batch Utility for Object Creation” in the Client Documentation.
-
Creation of Behavior Definition and Mechanism Objects (2 ways)
XML Submission (Ingest)
- Process summary: Just like with Data Objects, an XML submission package is prepared outside of Fedora for Behavior Definition and Mechanism Objects. This can be done manually with an XML editor, or programmatically. The submission package is sent to the Fedora repository for “Ingest” via one of the Fedora clients that support the ingest function.
- XML submission format: A Fedora-specific extension of METS 1.0. Within the METS file, inline XML metadata sections will be created in accordance with the following XML schema:
- Fedora Method Map [for Behavior Def and Mech]
Namespace: http://fedora.comm.nsdlib.org/service/methodmap
Schema Loc: %FEDORA_HOME%\dist\server\xsd\methodmap.xsd
- OAI Dublin Core [for Behavior Def and Mech]
Namespace:"http://www.openarchives.org/OAI/2.0/oai_dc/
Schema Loc: http://www.openarchives.org/OAI/openarchivesprotocol.html
- Web Services Description Language (WSDL) [for Behavior Mech]
Namespace: http://schemas.xmlsoap.org/wsdl/
Schema Loc: http://www.w3.org/TR/wsdl
- Fedora Datastream Input Spec [for Behavior Mech]
Namespace: http://fedora.comm.nsdlib.org/service/bindspec
Schema Loc: %FEDORA_HOME%\dist\server\xsd\bindspec.xsd
- Clients for ingest: (see clients listed in Data Object section above)
Interactive Building
- Process summary: A user can create Behavior Definition and Behavior Mechanism objects using the Admin GUI java application. The Admin GUI provides builders which act as a “wizards” for creating objects in a one-up manner. Behind the scenes the builders create METS submission packages containing all of the requisite metadata formats for method definitions and service bindings.
- Clients for interactive building:
- Admin GUI - From the menu, select Builders/BDefBuilder or Builders/BMechBuilder. These will open up a respective wizard for creating new objects. For more details see the guide entitled “Java Application: Admin GUI - Behavior Definition and Mechanism Builders” in the Client Documentation.
- AutoIngester Script