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
This documentation refers to an earlier version of Islandora.
https://wiki.duraspace.org/display/ISLANDORA/Start
is current.
This chapter focuses on explaining the way that Islandora understands content, and providing basic instructions for how you can create, view, update, and delete (purge) content in your repository. This chapter presumes that you have access to a running instance of Islandora, either through the online sandbox or a virtual machine image on your local machine. Both the online sandbox and the VM come with pre-installed collections that will be used as examples in this documentation.
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.
Understanding Islandora means understanding the following:
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. 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 an object, 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.
Collection Object - As the name suggests, the collection object gathers objects into a collection. If you want to make an image collection in Islandora, you would start with a collection object that subscribes to one ore more Image Content Models. Every data object you add to (ingest into) this collection would then be a member of that collection, because a relationship between that new data object and the collection object (the image collection) is written. Every instance of Islandora will have a root collection object. This collection object will subscribe to a “Collection” Content Model, enabling 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.
Each object has Datastreams, which are the parts of an object.
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), and the TN datastream stores a display thumbnail for the object.
For an overview of the Datastreams you will encounter in Islandora, see APPENDIX C - Datastream Reference.
Every object in Islandora can also be set to one or more "states" - An object is said to be "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 be set to a state of "Deleted" and are not removed from the repository. This is in contract 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.
The RDF statements in this 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 (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.
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:
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 these namespaces meaningful in order to help us sort and find items in our 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.
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.
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. These tutorials assume that you have installed one or more Solution Packs. Please review Chapter 5 - Islandora Modules if you are not sure if you have Solution Packs installed. If no solution packs are installed, you will not be able to create collections of content in Islandora.
The following tutorials will guide you through the basics of managing and building your Islandora collections:
For more information please visit https://islandora.ca