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
Many discipline-specific and community-specific metadata standards have evolved to meet the challenge of supporting data management and discovery as well as capturing information and communicating information it to users. Islandora’s system is based on an understanding that the complexity of content-types and metadata standards, and the scarcity of metadata creation, management, and validation tools pose barriers to effective information management.
The following chapter will outline the role of descriptive metadata in the Islandora system. If you are using Islandora, it is presumed you have a strong understanding of metadata standards that you will be working with, and the role of descriptive metadata in organizing information assets.
...
Islandora by default tends to use MODS, and the DC datastreams provided natively by FedoraCommons, for descriptive metadata, PREMIS for preservation metadata (leveraging the AUDIT datastream from FedoraCommons) MARCXML for some ingests, etc. However, Islandora supports any XML-based metadata standard or approach and leverages xsl for crosswalking and indexing of metadata.
As the proliferation of Descriptive Metadata standards continues to create interoperability and compatibility issues, XML is and its accompanying tools are increasingly viewed as a key tool in for automating and translating metadata, so that appropriate Metadata can continue to be produced, persisted, and managed. The benefits are widely recognized as reduced effort, greater consistency of metadata, and enhanced accuracy of metadata.Using XML to represent metadata means that a representative document is created that represents what fields are used to describe a given object, and then these fields are mapped to a particular object, creating an XML-based metadata record. These representative documents are called schemas, and have
...
Islandora utilizes Fedora’s ability to represent Descriptive metadata in XML format via one or more Datastreams in an object. Fedora is written in such a way that any object may have multiple metadata Datastreams, which can store Metadata following any schema, such as MODS, Dublin Core, or QDC.
When an object is created in Islandora, a datastream containing Dublin Core XML metadata is automatically produced and is given "DC" as its DSID, but you will most likely want a separate datastream containing metadata from a richer metadata schema. For this reason, Islandora Solution Packs usually provide on or more MODS forms (and occasionally other forms) for storing more complex descriptive metadata. Typically, developers of Islandora Solution packs will define DSIDs appropriate to the metadata standard being used. For example, Islandora Solution packs usually store MODS metadata in a datastream with the DSID "MODS."
A user To accommodate the richer metadata, each Islandora Solution Pack comes with a pre-installed metadata form that can be used as a starting point in building your own rich metadata form. So, a user ingesting a new object is presented with the metadata form appropriate for that collection. The Content Model for the collection specifies the DSID of that metadata datastream in order to maintain consistency across all objects associated with that Content Model.
The form that come pre-installed with a Solution Pack represent just a starting point to help you create an XML form appropriate for your data. You can leave the form as is or modify it to meet the needs of your repository.
XML Metadata Forms can be edited, created, copied, and affiliated with Content Model objects using the Islandora Form Builder (XML Forms Modules). When you use the Form Builder, an .xsd in the Form Builder Modules can read in an externally or internally stored schema (another .xsd document), and allow for a form to be created and validated based on that external schema. Users can then associate the newly created or edited form with other content models in the repository via the User Interface (providing that they associate the form with a content model that prescribes that scheme, and permits an XML datastream corresponding to it). Likewise, one Associations between forms and content models can be changed or removed by users of Islandora as described in the XML Forms section of this documentation. One Islandora content model may be associated with a number of forms to suit the needs of different collections.In order to fully utilize the Forms Builder, users will have to have an understanding of XML, Schema documents, and XPath (the language used to navigate XML documents).
In order to crosswalk metadata, Islandora makes extensive use of XML transformations, or .xslts. Transformation serve a number of purposes in the Islandora system. Of particular significance here is the way that Islandora crosswalks data on ingest.
Fedora requires that any object created in the system contain a default Dublin Core Stream. By extension, any object that is created in Islandora (and therefore in a Fedora repository) will have a default Dublin Core Datastream. However, Islandora’s Solution Packs presume that users will often want to store an additional metadata stream outside of the default Dublin Core stream, in order to create richer descriptive metadata, and also to adhere to standards for metadata description of particular types of data and collections. For example, the MODS form that comes by default with any Solution Pack is designed to suit the most common cases for that solution pack.
This means that Islandora’s Solution Pack Content Models define a Datastream that allows for additional granularity and is customized to the needs of a particular data type or subject area. When metadata is created using this ingest form, an .xslt is called by the Content Model to transforms the richer metadata schema into the default Dublin Core datastream, and stores both the richer XML based Descriptive Metadata and the Dublin Core Metadata in the object. In this way, Islandora preserves a common metadata stream (in Dublin Core format) that can be useful for searching and retrieving metadata objects across the repository, as well as a more granular metadata stream, say, MODS or Darwin Core, that describes the object as is most appropriate for the subject area or discipline to which the object relates. Whenever a metadata field is updated through the Islandora interface, the .xslt is called to perform the transformation again, making sure that the Dublin Core datastream is kept consistent with the data in the richer Metadata Datastream.
Solution packs provide default transformations that do things like crosswalk MODS metadata to DC on ingest and edit of metadata. Both MODS and DC are thus persisted and kept in sync. When creating and editing forms based on new schemas, systems administrators can also add xslt files to folders in an Islandora installation, and make them available for administrators.
The architecture surrounding In the end, the architecture surrounding descriptive metadata in Islandora is designed to provide out-of-the box metadata creation, but also customization. New forms can be created and associated with Content Models via the Islandora interface. Content Models can be written to define any number of metadata datastreams, and to call .xslt files to create new datastreams on ingest, and to update datastreams when metadata is edited. The system leverages the external community by taking advantage of .xslts that are commonly produced to serve similar use-cases for other organizations. When installing an Islandora module, explore what metadata datastreams, transformations, and forms are made available to learn more about what options are available to you.