Page History

...

• Everything in Islandora's repository is an Object 
• Objects are made up of Datastreams
• Objects have Relationships to one another
• Objects have Persistent Identifiers (PIDs) that are unique in your repository

Everything in Islandora's repository is an

...

object

Everything in Islandora’s Fedora Commons Repository is an object made up of datastreams. An object is like a directory or folder full of different files (the datastreams). However, unlike the folder system on your computer (which contain other folders), Islandora's information architecture is graph-like, more like a network. There are several kinds of objects, and each object performs a different function. Islandora's main object types are Content Model Objects, Collection Objects, and Data Objects.

Content Model Object

- A Content Model Object is a “template” for a particular type of content. Content model objects are usually built through a Solution Pack. Other analogies are a cookie-cutter or recipe ingredient list. Fedora Commons has its own notion of a Content Model, which you can read more about here. This version of Islandora uses the Fedora Commons 3.x content model architecture. 

Unlike previous versions of Islandora (6.x), Islandora 7's content model is very lightweight and defined in a DS-COMPOSITE-MODEL datastream. The DS-COMPOSITE-MODEL defines what datastreams comprise types of files can be added to an object, including whether or not these datastreams are optional or enforced, and what mimetype the datastream can, should, or must contain. Content model objects are usually built through a Solution Pack. 

Content Models want to treat media types differently. For example, a PDF and a map might have very different data associated with them, based on the metadata conventions used for describing those kinds of objects, or what type of file it is. The Content Model object will define the list of Datastreams the associated digital object will have, as well as the list of binary files.

required.

Collection Object

Collection objects are Fedora objects that have "child" objects that are gathered into a collection in the Islandora displayCollection Object - As the name suggests, the collection object gathers objects into a collection. If you want to make an image a collection of PDFs in Islandora, you would start with by creating a collection object that subscribes to one ore more Image Content Models. Every has the PDF Content Model. Because of Fedora's ability to automatically create relationships between objects, every data object you add to (ingest into) this collection would then be become a member of that collection, because a relationship between that new data object and the collection and would have a content model of PDF.

object (the image collection) is written. Every instance of Islandora will have starts with a root collection object. This collection object will subscribe to a “Collection” has the Collection Content Model, enabling more collections to be created “under” that object. All Collection objects will be affiliated with the Collection Content Model object, and that affiliation will define what types of Data Objects can belong to a Collection. That affiliation will be defined in one of the Datastreams of the collection object - the COLLECTION_POLICY stream.

Data Object - The “Data Object” is the actual asset being stored. So, one “image” and its associated Datastreams (metadata, alternate image formats/sizes) is a “data object.” The image object will have a number of different Datastreams. These Datastreams will tell the system where the main file is located -as well as any derivatives that are used for web-display, they will contain the metadata associated with that object, and they will indicate which collection (or collections!) the image belongs to.

Objects have Datastreams

as children (sub-collections) of the root collection. These sub-collections can have their own sub-collections, or can contain any type of data object as defined in the collection policy datastream of each collection.

Data Object

Data Objects are the files ingested into the repository and any associated metadata, derivatives, or related files that should be managed as a single digital asset in the repository. For example, one image (such as a TIFF file) and its associated datastreams (such as descriptive and technical metadata, thumbnails, and access derivatives in other formats) make up a “data object.” Fedora also stores relationship metadata in datastreams that connect objects to parent collections, content models, and other related objects.

Objects have datastreams

Each object has datastreamsEach object has Datastreams, which are the parts of an object.

Datastreams may include content files (such as a PDF or an image), metadata, or information about relationships to content models or other objects. Every object in Islandora has at least three datastreams in common (DC, RELS-EXT, and TN) as well as specialized datastreams to serve the functions of that object. Datastreams may reference to a file (such as a PDF, or an image), they may reference a Content Model Object, and they may store information about the relationship of that object to other objects. The relationship of an object to other objects is stored in the RELS-EXT datastream, simple metadata about the object is stored in the DC stream ( Dublin Core (DC) datastream, and the TN datastream stores a display thumbnail for the object is stored in the TN datastream. 

For an overview of the Datastreams you will encounter a complete list of datastreams in Islandora, see APPENDIX C - Datastream Reference.

Objects have

...

states

Every object in Islandora can also be set to one or more "states" - An object is said to be in Fedora. Fedora states include "Active," "Inactive," or "Deleted." These multiple states are used in different ways by Islandora code and are part of what makes Fedora Commons secure. Objects can . By default, only "Active" objects display to anonymous users. Inactive states can be used for objects that aren't ready to be published (for example, objects waiting for approval in an ingest workflow). Objects can also be set to a state of "Deleted" and are not removed from the repository," which maintains a copy of the object in the repository but restricts viewing and management to certain roles. This is in contract contrast to "Purging" purging an object, which permanently removes the object and its administrative history from the repository. 

Objects have

...

relationships

Objects in Islandora have relationships to one another. These relationships are stored in a RELS-EXT Datastream datastream in an object, which usually has the label “Fedora Object-to-Object Relationship Metadata.” This Datastream datastream is written in RDF/XML.

The RDF/XML statements in this Datastream datastream will indicate, for example, what collection object(s) an object belongs to, what content model object it subscribes to, and what its Persistent Identifier persistent identifier (PID) is. These statements take the following form:

<subjectFedoraObject> <typeOfRelationship> <targetFedoraObject>

So, for example, the relationship between an object and the collection it belongs to might look like this:

<myMapImage> <isMemberOf> <myMapCollection>

A default set of common relationships is defined in the Fedora Relationship Ontology. More information on digital object relationships in general is available from the Digital Object Relationships section of the Fedora Commons documentation. References to these documents are also provided in the selected reading section of this guide.

Objects have

...

unique, persistent identifiers

Each object in Islandora has a unique identifier called a PID (Persistent IdentifierIDentifier). No two PIDs in your repository can be the same. PIDs look like this:

...

In the first case, the entire PID has been specified by a user. In the second case, the first part of the PID (the namespace prefix ) has been added by the user, and the system is automatically assigning a number to make up the second part of the PID. Islandora now supports the creation of PIDs based on UUIDs as well.

PID namespace prefixes do not need to be meaningful, they just need to be unique. However, we often make making these namespaces meaningful in order to can help us you sort and find items in our your repository. For example, a namespace might refer to the type of content (such as audio:) or it may refer to the name of an institution or collection (upei: OR stmatthews:). As you navigate Islandora, you will see PID namespaces mentioned frequently, and you will be prompted to choose PID namespace prefixes or PID namespaces. 

...

You should see any collections that are installed as part of a Solution Pack, and they will appear with a default “icon” folder , or a thumbnail image. icon.

The following tutorials will guide you through the basics of managing and building your Islandora collections: