All Versions
Islandora 7.x-1.13
Islandora 7.x-1.12
Islandora 7.x-1.11
Islandora 7.x-1.10
Islandora 7.x-1.9
Islandora 7.x-1.8
Islandora 7.x-1.7
Islandora 7.x-1.6
Islandora 7.x-1.5
Islandora 7.x-1.4
Islandora 7.x-1.3
Islandora 7.x-1.2
Islandora 7.x-1.1
Islandora 7.x-1.0 (Beta)
Islandora 6.x-13.1.x
Islandora 6.x-12.2.x
Islandora 6.x-12.1.x
Islandora 6.x-11.3.x
Islandora 6.x-11.2.x
...
If you do not have access to an instance of Islandora, please review Chapter 2 - Accessing Islandora.
Before accessing and using Islandora, it is important to learn how Islandora understands your content. Islandora uses Fedora Commons’ flexible digital object model, relationships, and content model architecture. If you are familiar with these concepts, you may find this section repetitive, because it borrows heavily from the Fedora Commons documentation to provide what is most relevant for Islandora.
...
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.
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 datastreamMODEL datastream. The The DS-COMPOSITE-MODEL defines what types of files can be added to an object, including whether these datastreams are optional or required.
Collection objects are Fedora objects that have "child" objects that are gathered into a collection in the Islandora display. If you want to make a collection of PDFs in Islandora, you would start by creating a collection object that 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 become a member of that collection, and would have a content model of PDF.
Every instance of Islandora starts with a root collection object. This collection object has the Collection Content Model, enabling more collections to be created 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 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.
Each object has datastreams, which are the parts of an object.
...
For a complete list of datastreams in Islandora, see APPENDIX C - Datastream Reference.
Every object in Islandora can also be set to one or more "states" in Fedora. Fedora states include "Active," "Inactive," or "Deleted." These states are used in different ways by Islandora code. 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," which maintains a copy of the object in the repository but restricts viewing and management to certain roles. This is in contrast to purging an object, which permanently removes the object and its administrative history from the repository.
Objects in Islandora have relationships to one another. These relationships are stored in a RELS-EXT datastream in an object, which usually has the label “Fedora Object-to-Object Relationship Metadata.” This datastream is written in RDF/XML.
...
A default set of common relationships is defined in the Fedora Relationship Ontology. More information on digital object relationships 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.
Each object in Islandora has a unique identifier called a PID (Persistent IDentifier). No two PIDs in your repository can be the same. PIDs look like this:
...
Another way of understanding the PID is as the basis for your repository’s Uniform Resource Identifiers (URIs) which uniquely identify items in your repository. To learn more about PIDs and PID namespace prefixes, visit Fedora Commons documentation; specifically, the section on Fedora Identifiers.
Once you have logged into your Islandora site as an administrator, you can view a list of all current collections by clicking the Islandora Repository link.
...