Old Release

This documentation covers an old version of Fedora. Looking for another version? See all documentation.

Skip to end of metadata
Go to start of metadata

This guide describes how Service Definition Objects are constructed in detail.  For a conceptual overview of these and other special Fedora object types, please see the Fedora Digital Object Model document. 


In Fedora, a Service Definition ("SDef") is a special kind of object that defines a set of operations on objects in a repository.  As you will see, that set of operations needs to be expressed in a particular way inside the object in order for Fedora to understand it. 

Although you may author Fedora objects in other ways (e.g. by making a series of API calls to your repository), we will assume for this guide that the object is being constructed in FOXML format outside the repository, then ingested in a single step.

Persistent Identifier

As with all Fedora objects, Service Definitions must declare a persistent identifier ("PID") that is unique within the repository.  There are no special restrictions on the PID beyond those described in the Fedora Identifiers document.  In FOXML format, the PID is declared in the root element of the XML document as shown below:

<?xml version="1.0" encoding="UTF-8"?>
<foxml:digitalObject xmlns:foxml="info:fedora/fedora-system:def/foxml#"
    VERSION="1.1" PID="demo:MyServiceDefinition">
  <!-- Object Properties -->
  <!-- Datastreams -->

Object Properties

There are also no special restrictions on the top-level object properties for Service Definitions.  In the following FOXML fragment, we assert that the state of the object is Active and the label is My Service Definition.

        VALUE="My Service Definition"/>

DC Datastream

The DC datastream describes the object in human terms using the Dublin Core Metadata Element Set.  If you don't provide it yourself, Fedora will automatically add a bare-bones DC datastream for the object at ingest time.  For an example DC datastream, please see the FOXML Ingest Example.

RELS-EXT Datastream

The RELS-EXT datastream expresses relationships and properties of the object in RDF.  An object asserts that it is a Service Definition Object through a special hasModel relationship to the fedora-system:ServiceDefinition-3.0 object as shown below:

  <foxml:datastream ID="RELS-EXT"
    <foxml:datastreamVersion ID="RELS-EXT1.0"
        LABEL="RDF Statements about this object">
        <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          <rdf:Description rdf:about="info:fedora/demo:MyServiceDefinition">

METHODMAP Datastream

The METHODMAP datastream is the heart of the Service Definition object.  It defines the set of methods in the Fedora Service Definition Method Map format.  Each method may be defined in this datastream as taking zero or more user-supplied parameters. Each parameter may be required or optional, with a default value and optionally, a set of valid values. 

In the following example, we define several methods:

  • methodOne - takes no user parameters
  • methodTwo - takes one parameter:
    • parm1 - optional, with any possible value and default value of "value1"
  • methodThree - takes two parameters:
    • parm1 - optional, with two possible values and a default value of "value1"
    • parm2 - required, with any possible value and a default value of "" (empty string)
  <foxml:datastream ID="METHODMAP"
    <foxml:datastreamVersion ID="METHODMAP1.0"
        LABEL="Abstract Method Map" MIMETYPE="text/xml">
          <fmm:Method operationName="methodOne"/>
          <fmm:Method operationName="methodTwo">
            <fmm:UserInputParm parmName="parm1" defaultValue="value1"
                required="false" passBy="VALUE"/>
          <fmm:Method operationName="methodThree">
            <fmm:UserInputParm parmName="parm1" defaultValue="value1"
                required="false" passBy="VALUE">
                <fmm:ValidParm value="value1"/>
                <fmm:ValidParm value="value2"/>
            <fmm:UserInputParm parmName="parm2" defaultValue=""
                required="true" passBy="VALUE"/>
  • No labels