Table of Contents

  1. What are Fedora Digital Object Relationships?
  2. Why are Fedora Digital Object Relationships Important?
  3. Where is Digital Object Relationship Metadata Stored?
  4. How is Digital Object Relationship Metadata Encoded?
  5. Resource Index - RDF-based Indexing and Searching for Digital Objects
  1. What are Fedora Digital Object Relationships?

    Fedora digital objects can be related to other Fedora objects in many ways. For example there may be a Fedora object that represents a collection and other objects that are members of that collection. Also, it may be the case that one object is considered a part of another object, a derivation of another object, a description of another object, or even equivalent to another object. For example, consider a network of digital objects pertaining to Thomas Jefferson, in which scholarly works are stored as digital objects, which are related to other digital objects representing primary source materials in libraries or museums. The composite scholary objects can be considered a graph of related digital objects. Other types of objects can also be related to the scholarly object over time, for instance annotations about the scholarly object can be created by others and related to the original object. Also, digital objects can be created to act as "surrogates" or "proxies" for dynamically produced web content such as an Amazon page for a book relevant to the scholarly object. Such a network of digital objects can be created using Fedora, which in the abstract, would look like this:

    jefferson graph

    Digital object relationship metadata is a way of asserting these various kinds of relationships for Fedora objects. A default set of common relationships is defined in the Fedora relationship ontology (actually, a simple RDF schema) which defines a set of common generic relationships useful in creating digital object networks. These relationships can be refined or extended. Also, communities can define their own ontologies to encode relationships among Fedora digital objects. Relationships are asserted from the perspective of one object to another object as in the following general pattern:
    <subjectFedoraObject>    <relationshipProperty>    <targetFedoraObject>

    The first Fedora object is considered the "subject" of the relationship assertion. The relationship, itself, is considered a property of the subject. The target Fedora object is the related object. Thus, a valid relationship assertion as an English-language sentence might be:
    <MyCatVideo>    <is a member of the collection>    <GreatCatVideos>
  2. Why are Fedora Digital Object Relationships Important?

    The creation of Fedora digital object relationship metadata is the basis for enabling advanced access and management functionality driven from metadata that is managed within the repository. Examples of the uses of relationship metadata include:
  3. Where is Digital Object Relationship Metadata Stored?

    Object-to-Object relationships are stored as metadata in digital objects within a special datastream. This datastream is known by the reserved datastream identifier of "RELS-EXT" (which stands for "Relationships-External"). Each digital object can have one RELS-EXT datastream which is used exclusively for asserting digital object relationships.

    A RELS-EXT datastream can be provided as part of a Fedora ingest file. Alternatively, it can be added to an existing digital object via component operations of the Fedora management service interface (i.e., addDatastream). Refer to the FOXML reference example to see an example of the RELS-EXT datastream in context. Modifications to the RELS-EXT datastream are made via the Fedora management interface (i.e., modifyDatastream).

    The RELS-EXT datastream should be encoded as an Inline XML datastream, meaning that the relationships metadata is expressed directly as XML within the digital object XML file (as opposed the relationship metadata existing in a separate XML file that the digital object points to by reference).
  4. How is Digital Object Relationship Metadata Encoded?

    Fedora object-to-object metadata is encoded in XML using the Resource Description Framework (RDF). The relationship metadata must follow a prescribed RDF/XML authoring style where the subject is encoded using <rdf:Description>, the relationship is a property of the subject, and the target object is bound to the relationship property using the rdf:resource attribute. The subject and target of a relationship assertion must be URIs that identify Fedora digital objects. These URIs are based on Fedora object PIDs and conform to the syntax described for the fedora "info" URI scheme. The syntax for asserting relationships in RDF is as follows:
      <rdf:Description rdf:about="info:fedora/demo:99">
    	<fedora:isMemberOfCollection rdf:resource="info:fedora/demo:c1"/>
    	<myns:isPartOf rdf:resource="info:fedora/mystuff:100"/>
    	<myns:owner>Jane Doe<myns:owner/>

    The above RDF fragment indicates that the Fedora digital object identified as "info:fedora/demo:99" is the subject that is being described (as specified by the rdf:about attribute). This object has two relationships to other digital objects. It has an "isMemberOfCollection" relationship to the object identified as "info:fedora/demo:c1" which is a Fedora object that represents a collection. This collection object is considered the target of the relationship assertion. The second relationship assertion that is just like the first one, except that it asserts that the subject is a part of another Fedora digital object, "info:fedora/mystuff:100". The third relationship asserts that the digital object has owner "Jane Doe". Note that the object of this relationship is a text literal, not a URI.

    To ensure the integrity of relationship metadata so that it can be properly indexed by Fedora, the Fedora repository service validates all RELS-EXT datatreams and enforces the following constraints on the RDF:
    1. The subject must be encoded as an <rdf:Description> element, with an "rdf:about" attribute containing the URI of the digital object in which the RELS-EXT datastream resides. Thus, relationships are asserted about this object only. Relationship directionality is from this object to other objects.
    2. The relationship assertions must be RDF properties associated with the <rdf:Description>. Relationship assertions can be properties defined in the default Fedora relationship ontology, or properties from other namespaces.
    3. Prior to 2.1, the objects of relationships were restricted to other Fedora digital object URIs. This has since been relaxed so that a relationship property may reference any URI or literal, with the following exception: a relationship may not be self-referential, rdf:resource attribute must not point to the URI of the digital object that is the subject of the relationship.
    4. There must be only one <rdf:Description> in the RELS-EXT datastream. One description can have as many relationship property assertions as necessary.
    5. There must be no nesting of assertions. Specifically, there cannot be an <rdf:Description> within an <rdf:Description>. In terms of XML "depth," the RDF root is considered at the depth of zero. The must be one <rdf:Description> element that must exist at the depth of one. The relationship assertions are RDF properties of the <rdf:Description> that exist at a depth of two.
    6. Assertions of properties from certain namespaces for forbidden in RELS-EXT. There must NOT be any assertion of properties from the Dublin Core namespace or from the FOXML namespace. This is because these assertions exist elsewhere in Fedora objects and may conflict if asserted in two places. The RELS-EXT datasream is intended to be dedicated to solely object-to-object relationships and not used to make general descriptive assertions about objects.
  5. Resource Index - RDF-based Indexing and Searching for Digital Objects

    Yes! The Fedora repository service automatically indexes the RELS-EXT datastreams for all objects as part of the RDF-based Resource Index.

    This provides a unified "graph" of all the objects in the repository and their relationships to each other. The Resource Index graph can be queried using RDQL or ITQL which are SQL-like query languages for RDF. The Fedora repository service exposes an web service interface to search the Resource Index. Please refer to the Resource Index documentation for details.