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.
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:
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.
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.
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:
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)