API

State: Not started

Time used: 0 md.

Description

Sub tasks

• 8.1 Wrapper of Fedora API-M (approx. 15 methods, estimate 2 md)
• 8.2 PID generator - including making the code ready for production (1 method, estimate 2 md)
• 8.3 ECM (enhanced content models, 3 methods, estimate below)
• 8.4 Characterization (1 method, estimate below)
• 8.5 Bitstorage (4 methods, estimate below)
• 8.6 Object manipulation (2 methods, estimate below)
  • Preparation of the four tasks above is estimated to 2 md.

Documentation

• Analysis Document

• Design Document

• System Set-up and Maintenance Document

Parent task

• TaskX

Progress history

Action Hook ECM API

Assigned

ABR(2md), JRG(1md)

Prev assigned

Tasks adressed

Tasks/3/2

Time estimated

3md

Time used

1.5md(ABR), 0.5md(JRG)

Priority

5

Status

Finished

Iteration

21

Notes

Problem

Fedora has a object property called state. We want to use this state. To do so, we have made the following rules

1. No objects in the Active state can be altered
2. No object can be put in the Active state without being validated

The first rule should be enforced as a repository wide XACML policy. The second should be done as a hook into the Api function ModifyObject

Progress

The api hook have been completed. It is a jar file, that must be installed on the Fedora classpath. It is set up as a Management decorator in fedora.fcfg. It has been sporadically tested, and works.

The xacml policy have been achieved

Result

The result of this action can be found in the module FedoraApiHooks in the Ecm project

Checklist For Working On An Action

The Life Cycle of an Action:

• Assign people for action definition: Done at start of iteration status meeting. Fill out Assigned

• Define the action: Describe information about what is to be done and how. Fill out Tasks Addressed and Time Estimated.

• Review the definition: Get another project group member to review the action definition, and update it.

• Assign people for action implementation: Done by project manager, usually the same persons who wrote the definition. Fill out Assigned and Prev assigned if new persons are assigned.

• Implement the action: See details below

• Review the action: Get another project group member to review what is implemented (code and documentation), and update it.

• Finish the action: Change the status to "Finished" and update the "time used" field on the action page.

Please make sure that you address the below issues, when working on an action:

• Update the state of the action to "In Progress" when you start working on it.
• Check if the tasks addressed by this action have their status set to "In Progress". If that is not the case, then change the state of them.

• Keep track of how much time that has been spent working on the action. If it addresses more than one task, then make a note on the action page about how much of the elapsed time that has been spent on the individual tasks. Hint: Continually updating the "Time used" field will make it easier for you.

• Update the "Progress History" and documentation pages of each task addressed by this action when appropriate. This depends on the situation, but in general, the task pages should hold all important related information about the work done, experiences gathered, identified requirements and so on.

Bitstorage API

See DomsFileHandling for how to work with files.

Bitstorage API

WSDL: Bitstorage.xml The following describes those methods of the Bitstorage API that may be called by the GUI.

uploadFile

Upload the provided file to the temporary area of bitstorage, giving it the provided file name. Return a bitstorage object, containing different characteristics about the uploaded file. The file is only uploaded to a temporary approve-area of the bitstorage, and needs to be approved by calling approveFile before it is actually moved to the permanent bitstorage.

If you try to upload a file that is already there, it checks the provided md5 against the file of the file on the server. If they match, there is no upload, you just get the return about the file already there. If they do not match, an exception is thrown.

Input parameters:

• String fileName The filename to store the file by.

• URI localurl The url to where the bitstorage webservice can get the file.

• String provided_md5 The locally generated md5sum of the file.

Returns:

• BitstorageFile A bitstorage object, detailing the characteritics and public url of the uploaded file. Data structure summarized below.

Throws:

• RemoteException If anything went wrong.

• CannotGetFile If the service cannot get the file from the localurl.

• InvalidFileName If the provided fileName is invalid.

• CannotStoreFile If the service cannot store the file on the server.

• WrongChecksum If the provided checksum does not match.

• CharacterizationFailed If the characterization service failed somehow.

• DifferentFileWithThatNameExist If there is already a file with that name, but a different checksum.

approveFile

Check the earlier uploaded file against the provided checksum, and if this succeeds, and possibly other criteria are met, move the file from the temporary area of bitstorage to the permanent bitstorage.

If you call this method on an already approved file, with the correct checksum, nothing happens. If the checksum is wrong, you get an exception.

Input parameters:

• URI fileurl The url to the file (in bitstorage)

• String md5sum The md5sum of the file

Throws:

• RemoteException If anything went wrong with the connection.

• UnknownURI If the URI is not to this bitstorage.

• WrongChecksum If the provided checksum match.

• CannotStoreFile If the file cannot be stored in the permanent storage area or if the file is not available in the temporary area.

disapproveFile

Delete the named file from bitstorage. Only works for files that have not yet been approved.

If the file is not in temporary bitstorage nothing happens.

Input parameters:

• URI fileurl The url to the file (in bitstorage).

• String md5sum The md5sum of the file.

Throws:

• RemoteException If anything went wrong with the connection.

• UnknownURI If the URI is not to this bitstorage.

• WrongChecksum If the checksum does not match the file in temporary.

spaceLeft

Return the number of bytes left in bitstorage.

Returns:

• long The number of bytes left in bitstorage.

Throws:

• RemoteException If something unforseen broke while performing the request.

Data structures

BitstorageFile

Returned by uploadFile.

Contains the following public methods.

• URI getFileurl

• String getFileName

• byte[] getCharacterizationOutput

• String getMd5CheckSum

• String getPronomID

• String getValidationStatus

DOMS Server API

Note: in the work of estimating for DOMS Server, methods have been added, which are not yet on the list below. Methods mentioned in the estimates, see Server task or ask JRG.

WORK IN PROGRESS

Object operations

newObject(template) => pid

Given a template, create a new object, return the PID

deleteObject(pid)

Given a PID, mark the object as deleted (note: object may only be undeleted by direct access to Fedora)

markPublishedObject(pid)

Given a PID, mark the object as published. Will fail if object does not validate.

markInProgressObject(pid)

Given a PID, mark the object as in progress.

listDatastreamsObject(pid) => listOfDatastreams

Given a PID, list datastream names in object.

getObjectTitle(pid) => title

Given a PID, return the title of the object.

Datastream operations

newDatastream(pid, name, content)

Given a pid and a datastream name, add a datastream with that name, and given content. Will fail if name already exists with different content.

deleteDatastream(pid, name)

Given a pid and a datastream name, mark that datastream as deleted.

modifyDatastream(pid, name, content)

Given a pid and a datastream name, replace the contents of that datastream with the given content. Will fail of datastream does not exist.

getDatastream(pid, name) => content

Given a pid and a datastream, return the datastream content. Will fail of datastream does not exist.

File operations

addFile(pid, name, content, checksum)

Given a pid and a name, add a new file to the object with the given content. Will fail if pid does not describe a file object, if a file is already added to the object with different content, or if content does not match checksum.

?deleteFile(pid)

Given a pid, delete the file in this object. This will fail if this is not a file object, if no file is present in the object, or if the object has been published so the file is undeletable.

TODO: Do we need/want this operation?

getFileUrl(pid) => url

Given a pid, return an externally resolvable URL that disseminates this file.

Relation operations

addRelation(fromPid, name, toPid)

Add a relation between two objects.

?getRelations(pid) => listOfNamesAndPids

Given a pid, list relations out of this object

TODO: Should this just be an RI-query?

?getRelations(pid, name) => listOfPids

Given a pid, list relations out of this object of a specific type

TODO: Should this just be an RI-query?

deleteRelation(pid, name, pid)

Given a specific relation, remove it.

?modifyRelation(pid, oldName, oldPid, newName, newPid)

Given an old relation, replace it with a new relation.

TODO: Do we need this operation?

Search operations

findObjects(queryString) => listOfPids

Given a query string, return list of objects matching

TODO: Should we return more than pids?

TODO: Paging

listObjects(modifiedSinceDate) => listOfPids

Given a date, return a list of objects modified since then.

TODO: Should we return more than pids?

TODO: Paging

riQuery(queryString) => queryResult

Given a query string for the resource index, return result.

TODO: Specify better

TODO: Do we want direct access to the Resource Index?

View operations

getView(pid, name) => viewBundle

Given an entry PID and a view name, return a bundle

getViewStructure(pid, name) => datastructureOfView

Given an entry PID and a view name, return a spanning tree over the view graph.

TODO: DFS or BFS? How does the data structure look?

Structural operations

For creating new entry objects

?listCollections() => listOfPids

List all collection objects in DOMS.

TODO: Should this just be an RI-query?

?getEntryTemplatesForCollection(collectionPid, viewName) => listOfPids

Given the PID of a collection, return all templates for that collection, that are also entry objects for the given view name.

TODO: Should this just be an RI-query?

For creating new subobjects in view

?getSubItemTemplates(pid, viewName) => listOfPids

Given an object and a named view, return templates that could be used to generate subobjects for that pid in that view.

TODO: Should we also return the specific relation of the template?

TODO: Should this just be an RI-query?

?addSubItem(pid, viewName, template)

Given an object, a named view, and a template, create a new object for that template, then add relation between old and new object in the view. Will fail if there is no allwed relation in the view between the object and the template.

TODO: Should we also get as paramter the specific relation of the template?

TODO: This could also be done with newObject and addRelation

For adding new view-external relations

?getAllowedRelations(pid) => listOfNamesAndCMS

Given a pid, return possible relations that could be added, and the content models allowed as object for those relations.

?listObjectsWithContentModel(pid)

Given a content model pid, list all objects that subscribe to that content model.

TODO: Should this just be an RI-query?

For content model driven behaviour

?getContentModel(pid) => compoundContentModel

TODO: ContentModels for views?

TODO: Should this just be an RI-query?

General notes

TODO: A lot of operations are currently defined to return a list of pids. Perhaps it would be better to return a list of pids AND object names/types

Fedora 3.0 API

DOMS metadata objects will be stored in Fedora-commons 3.0.

The API is documented here, as far as it goes: http://www.fedora-commons.org/documentation/3.0/userdocs/index.html#webservices

The structures below are used by Fedora, almost no matter which lanquage you use to interact with it. We use our own shorthand to specify the types. This schema should help you translate to your language of choise

The "fedora-types:ArrayOfString" is defined thus

<complexType name="ArrayOfString">
   <sequence>
      <element name="item" minOccurs="0" maxOccurs="unbounded" type="xsd:string"/>
   </sequence>
</complexType>

The API to Fedora is directly exported as the primary API to DOMS. We have restricted a few methods, and have some conventions about certain other should be used.

API restrictions

• apiM.PurgeDatastream andapiM.PurgeObject are not allowed. Instead use apiM.modifyDatastream and apiM.modifyObject to change the state to "D" (deleted).

• apiM.setDatastreamVersionable is disallowed. The internal datastreams are always versioned.

• Do not use getNextPID, instead use the method provided from DOMS

Fedora has the concept of state for all objects. We have added additional meaning to this term, which is described in FedoraState. Basically, an object can be Active, Inactive or Deleted. If it is Active, the only allowed change is to make it Inactive. All other attempted changes will throw exceptions. If Inactive, all changes are allowed. Changing the state from anything to Active will cause the object to be validated, and if the object is not valid, the state will not be changed.

Best practice, when perfoming changes in a set of objects it to mark each of them as Inactive, before performing any changes, and perform all changes before moving any of them back to Active.

The Fedora API is described in the the pages below.

• The public Access API - Everybody can use this, this is the primary way for external applications to query the repository.

• The protected Management API - Only authenticated administrators, such as users of the GUI, can use this.

• The Resource Index API - The interface to the Fedora triple store.

Fedora Resource Index

The Fedora Resource Index service is described in http://www.fedora-commons.org/confluence/display/FCR30/Resource+Index

iTQL

The resource index is queried by iTQL (interactive Tucana Query Language?), which is largely similar to SQL (Structured Query Language). A guide to iTQL can be found on http://docs.mulgara.org/itqlcommands/select.html

This has a graphical user interface, which it very helpful to users, but not programmatically useful. The interface is described here: http://www.fedora-commons.org/confluence/display/FCR30/Resource+Index+Search

We have prepared a number of useful iTQL queries, that can serve as examples. These can be tested on the doms testbed in http://localhost:8080/fedora/risearch

Find all direct subclasses of doms:ContentModel_File in the Base collection

select $object
from <#ri>
where      $object <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> <info:fedora/doms:ContentModel_File>
      and  $object <http://doms.statsbiblioteket.dk/relations/default/0/1/#isPartOfCollection> <info:fedora/doms:DOMS_Base_Collection>

Find the ancestors of doms:ContentModel_AudioPreservationFile

select  $object
from <#ri>
where walk(
        <info:fedora/doms:ContentModel_AudioPreservationFile> <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> $object 
        and $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> $object )

Find all objects that relate to doms:ContentModel_DOMS via a series of extendsModel relations.

select $subject
from <#ri>
where walk(
        $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> <info:fedora/doms:ContentModel_DOMS>
        and $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> $obbject
        );

Same as above, but with more expressive output, namely the relation-chain.

select $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> $object
from <#ri>
where walk(
        $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> <info:fedora/doms:ContentModel_DOMS>
        and $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> $object
        );

Anylevel children of ContentModel_DOMS in the base collection

select $subject
from <#ri>
where walk(
        $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> <info:fedora/doms:ContentModel_DOMS>
        and $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> $object
        )
        and $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#isPartOfCollection> <info:fedora/doms:DOMS_Base_Collection>

Any objects relating to Root collection through a series of "isPartOfCollection" relations.

select   $subject '<isPartOfCollection>' $object 
from <#ri>
where walk(
        $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#isPartOfCollection> <info:fedora/doms:Root_Collection>
        and $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#isPartOfCollection> $object )

All Templates of content models in the base collection

select $defbject
from <#ri>
where walk(
        $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> <info:fedora/doms:ContentModel_DOMS>
        and $subject <http://doms.statsbiblioteket.dk/relations/default/0/1/#extendsModel> $object
        )
        and $defbject <http://doms.statsbiblioteket.dk/relations/default/0/1/#isTemplateFor> $subject
        and $defbject <http://doms.statsbiblioteket.dk/relations/default/0/1/#isPartOfCollection> <info:fedora/doms:DOMS_Base_Collection>

Interacting with the Resource index

For programs, there are two interfaces.

REST interface

The first is the REST-based interface defined in http://www.fedora-commons.org/confluence/display/FCR30/Resource+Index+Search#ResourceIndexSearch-ApplicationInterface

Java interface

The second is the Fedora client, which has a method getTuples(). See http://www.fedora-commons.org/documentation/3.0/javadocs/index.html?fedora/client/FedoraClient.html.

The method getTuples() has the following javadoc

    /**
     * Get tuples from the remote resource index. The map contains
     * <em>String</em> values for parameters that should be passed to the
     * service. Two parameters are required: 1) lang 2) query Two parameters to
     * the risearch service are implied: 1) type = tuples 2) format = sparql See
     * http://www.fedora.info/download/2.0/userdocs/server/webservices/risearch/#app.tuples
     */

which is unfortunately outdated, but still largely correct.

The method returns an org.trippi.TupleIterator which parses the sparql result. The javadoc for this can be found on http://trippi.sourceforge.net/api/org/trippi/TupleIterator.html, which is for 1.1.2 Note that the page is not updated either. The releaseses can be found in the svn, and has reached version 1.4. Fedora uses 1.3.2, which is unknown, but 1.3.1 can be checked out. Look at http://sourceforge.net/svn/?group_id=123675 to do this.

The result consist of a list of maps. The iterator iterates through this list, returning maps. The iterator has a method, names(), giving the keys to each map. The values in the maps are of type Node, see http://jrdf.sourceforge.net/0.3.4/doc/javadoc/org/jrdf/graph/Node.html

In practice each node will always be a Literal node or a URI reference Node or a Blank node, see the following

• http://jrdf.sourceforge.net/0.3.4/doc/javadoc/org/jrdf/graph/Literal.html,

• http://jrdf.sourceforge.net/0.3.4/doc/javadoc/org/jrdf/graph/URIReference.html,

• http://jrdf.sourceforge.net/0.3.4/doc/javadoc/org/jrdf/graph/BlankNode.html

File characterization API

A webservice is provided, that given a URL will provide output of characterization tools, and a file format ID.

The concept is that the output of this webservice must be included in a technical datastream for the file object. Also, the format ID must be provided in technical metadata.

File Characterization API

WSDL: DOMSFileCharacterizer.xml

The following describes those methods of the File Characterization API that may be called by the GUI.

characterizeFile

Generates characterization output from analysis of file.

Input parameters:

• org.apache.axis.types.URI fileURI URL to the file to be characterized.

Returns:

• FileCharacterization Characterisation message and a format ID. Data structure summarized below.

Throws:

• IOException If the characterizer failed downloading the file.

• NoSuchAlgorithmException This exception should never be thrown.

Data structures

FileCharacterization

Returned by characterizeFile.

Characterisation response. Contains the following private fields. Each has corresponding getter and setter methods.

• byte[] characterizationOutput The output of the characterization tool.

• String pronomID The PRONOM file format ID.

• String validationStatus Whether or not the format of the file is valid. Value "VALID" or "INVALID".

• String md5CheckSum Checksum of the file.

Authentication API

DOMS will use the Fedora authentication system to authenticate users of the system. This means that authentication is handled by using the HTTP authentication mechanism used by Fedora. Best practice is using the function Fedora 3.0 API/Access#describeRepository to check credentials on first login.

In TestBed we will simply be using fedora-users.xml to define users. In the final production system, see http://www.fedora-commons.org/documentation/3.0b2/userdocs/server/security/securingrepo.html - we will use the LdapFilterForAttributes filter. However, since we use the Fedora authentication system, this will not change how you actually check credentials in any way.

It is acceptable that you need to log out, and back in, if you change the password in the LDAP.

Object creation API

A webservice for creating a new object, as the clone of an existing template.

Given the PID of a template, it returns the PID a new object which is cloned from the old object and ingested into Fedora.

Object creation API

WSDL: DomsObjectCreation.xml

The following describes those methods of the Object creation API that may be called by the GUI.

createObjectFromTemplate

Created a new object from the given template, and returns the PID of the new object.

Input parameters:

• String user Username for the user creating a new object

• String pass Password for the user creating a new object

• org.apache.axis.types.URI templatePID DOMS PID of the template to use for creation of the object.

Returns:

• org.apache.axis.types.URI PID of the (topmost) new object created in the DOMS. Other objects may have been created, and are in that case related to this object.

Throws:

• Exception If an internal error occurred.

GUI Object manipulation API

A webservice for manipulating object, specifically adding files

Object manipulation API

WSDL: DomsGUIObjectManipulation.xml

The following describes those methods of the Object manipulation API that may be called by the GUI.

addFileToObjectNoMD5

Add a file to an object

Input parameters:

• String user Username for the user creating a new object

• String pass Password for the user creating a new object

• String filePath Path to the file to add to the object

• org.apache.axis.types.URI domsObjectPID DOMS PID of the object to add file to

Returns:

• Nothing

Throws:

• Exception If an internal error occurred.

addFileToObject

Add a file to an object, with MD5 already known. Preferred and more efficient method.

Input parameters:

• String user Username for the user creating a new object

• String pass Password for the user creating a new object

• String filePath Path to the file to add to the object

• String md5CheckSum

• org.apache.axis.types.URI domsObjectPID DOMS PID of the object to add file to

Returns:

• Nothing

Throws:

• Exception If an internal error occurred.

PID API

A webservice for generating a PID is provided.

The API is trivially simple: A call to the given method will give the next available API. Optionally, a string may be given that should be part of the PID.

The call should never fail.

Implementation note: Due to a length restriction of 64 characters for Fedora PIDs, any string longer than approx 50 characters will be shortened, to ensure space for adding a unique part to the PID.

PID API

WSDL: DomsPIDGenerator.xml

The following describes those methods of the PID API that may be called by the GUI.

generateNexAvailablePID

Generates a new PID.

Input parameters:

• String infix The PID of the object.

Returns:

• String The newly generated unique PID, possibly including the provided infix.

Risearch API

A webservice which wraps the most common requests made to the resource index.

Risearch API

WSDL: DomsResourceIndex.xml

The following describes those methods of the Risearch API that may be called by the GUI.

allReferencingTheseObjects

Find the objects that have some relation to one of the objects given and is not deleted.

Input parameters:

• String[] objects A list of pids of objects.

• String user The username for the fedora server.

• String pass The password for the username.

Returns:

• DigitalObject[] The objects that have a relation to these objects. Data structure summarized below.

Throws:

• Exception If something went wrong.

allTemplatesInCollectionForContentModel

Finds the object that are templates in the given collection for the specified content model, and are not deleted.

Input parameters:

• String collection The collection the templates should be in.

• String contentModel The content model they should be templates for.

• String user The username for the fedora server.

• String pass The password for the username.

Returns:

• DigitalObject[] The list of templates. Data structure summarized below.

Throws:

• Exception If something went wrong.

getState

Syntactic sugar method for getting the state of an Fedora object.

Input parameters:

• String pid The pid of the object to examine.

• String user The username for the fedora server.

• String pass The password for the username.

Returns:

• String The state as a string. Could be "A", "I" or "D".

Throws:

• Exception If something went wrong.

Data structures

DigitalObject

Returned by allReferencingTheseObjects and allTemplatesInCollectionForContentModel.

Contains the following private fields. Each has corresponding getter and setter methods.

• String title

• String pid

Search API

DOMS Search uses simple search methods of the Summa Search interface.

WSDL: DomsGUISearch.xml

Content of this page:

• Operations

• Result XML Description

• Result XML Example

Operations

simpleSearch

This method executes the given query and returns a search result ranked by relevance.

Input parameters:

• String query The query string.

• int numberOfRecords The maximum number of records returned in search result.

• int startIndex The number of the first record to return.

Returns:

• String simpleSearchReturn The search result sorted by relevance as structured XML document. See description below.

Throws:

• java.rmi.RemoteException

simpleSearchSorted

This method executes the given query and returns a search result ranked by the given sort key.

Input parameters:

• String query The query string.

• int numberOfRecords The maximum number of records returned in search result.

• int startIndex The number of the first record to return.

• String sortKey The key to sort by.

• boolean reverse A boolean indication whether or not to sort in reverse.

Returns:

• String simpleSearchReturn The search result sorted by the given key, reversed if so indicated, as structured XML document. See description below.

Throws:

• java.rmi.RemoteException

Result XML Description

The result string defined by Summa is XML, in the following form:

<?xml version="1.0" encoding="UTF-8" ?>  
<responsecollection>  
  <response>  response-xml-1 </response>  
  <response>  response-xml-2 </response>  
  ... 
<responsecollection> 

Possible responses (in place of response-xml-1, response-xml-2, ... above) are document response, facet result and others. In DOMS we only use document response, which looks like this:

<documentresult filter="..." query="..." startIndex="..." maxRecords="..." sortKey="..." 
                reverseSort="..." fields="..." searchTime="..." hitCount="...">  
  <record score="..." sortValue="...">  
    <field name="recordID">...</field>  
    <field name="shortformat">...</field>  
  </record>  
  ... 
</documentresult>

Currently, we do not have a schema for the result. The result can be read as follows:

documentresult element

• Attribute filter is not used in simple search results.

• Attributes query, startIndex, maxRecords, sortKey, reverseSort: Same as input to method.

• Attribute fields: Always "recordID, shortformat" in DOMS.

• Attribute searchTime: Time it took to search.

• Attribute hitCount: Number of results.

record element

• Attribute score: relevancy ranking, value from 0 to 1.

• Attribute sortValue is the value that the sort was performed on.

field element

• Attribute name: In DOMS always either recordID or shortformat.

• Contents are the PID for recordID, or XML for shortformat.

The XML for shortformat is of the following form:

<shortrecord>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <rdf:Description>
      <dc:title>...</dc:title>
      <dc:creator>...</dc:creator>
      <dc:date>...</dc:date>
      <dc:type xml:lang="da">netdokument</dc:type>
      <dc:type xml:lang="en">net document</dc:type>
      <dc:identifier>...</dc:identifier>
      ...
    </rdf:Description>
  </rdf:RDF>
</shortrecord>

The important elements are the "dc" fields. They will contain the actual results.

Result XML Example

This example is the same as the one given by the Summa Minimal Deployment Tutorial, except without the facet result response.

<?xml version="1.0" encoding="UTF-8" ?>
<responsecollection>
<response name="DocumentResponse">
<documentresult query="narrative" startIndex="0" maxRecords="20" sortKey="summa-score" reverseSort="false" fields="main_titel, lsubject, lsu_oai, author_normalised, recordID, shortformat" searchTime="8" hitCount="2">
  <record score="0.20924361" id="122" source="NA">
    <field name="main_titel">Pensare per immagini: una strada per la coscienza</field>
    <field name="lsubject">NoSubject</field>
    <field name="lsu_oai">NoOAI</field>
    <field name="author_normalised">Ferdinando Testa</field>
    <field name="recordID">oai:oai:doaj-articles:badd9ac32fc2e096cf76fec4f0d19250</field>
    <field name="shortformat"><shortrecord>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description>
<dc:title xmlns:dc="http://purl.org/dc/elements/1.1/">Pensare per immagini: una strada per la coscienza</dc:title>
<dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ferdinando Testa</dc:creator>
<dc:date xmlns:dc="http://purl.org/dc/elements/1.1/">2005</dc:date>
<dc:type xml:lang="da" xmlns:dc="http://purl.org/dc/elements/1.1/">netdokument</dc:type>
<dc:type xml:lang="en" xmlns:dc="http://purl.org/dc/elements/1.1/">net document</dc:type>
<dc:identifier xmlns:dc="http://purl.org/dc/elements/1.1/">http://www.analisiqualitativa.com/magma/0304/articolo_01.htm</dc:identifier>
<dc:identifier xmlns:dc="http://purl.org/dc/elements/1.1/">http://www.doaj.org/doaj?func=openurl&amp;genre=article&amp;issn=17219809&amp;date=2005&amp;volume=03&amp;issue=04&amp;spage=</dc:identifier>
<dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">todo</dc:format>
</rdf:Description>
</rdf:RDF>
</shortrecord></field>
  </record>
  <record score="0.20924361" id="149" source="NA">
    <field name="main_titel">La narrazione: dimensione ontologica della formazione</field>
    <field name="lsubject">NoSubject</field>
    <field name="lsu_oai">NoOAI</field>
    <field name="author_normalised">Francesca Pulvirenti</field>
    <field name="recordID">oai:oai:doaj-articles:dd2dffe34df1293e045aee58f06a5c3f</field>
    <field name="shortformat"><shortrecord>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description>
<dc:title xmlns:dc="http://purl.org/dc/elements/1.1/">La narrazione: dimensione ontologica della formazione</dc:title>
<dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Francesca Pulvirenti</dc:creator>
<dc:date xmlns:dc="http://purl.org/dc/elements/1.1/">2005</dc:date>
<dc:type xml:lang="da" xmlns:dc="http://purl.org/dc/elements/1.1/">netdokument</dc:type>
<dc:type xml:lang="en" xmlns:dc="http://purl.org/dc/elements/1.1/">net document</dc:type>
<dc:identifier xmlns:dc="http://purl.org/dc/elements/1.1/">http://www.analisiqualitativa.com/magma/0303/editoriale.htm</dc:identifier>
<dc:identifier xmlns:dc="http://purl.org/dc/elements/1.1/">http://www.doaj.org/doaj?func=openurl&amp;genre=article&amp;issn=17219809&amp;date=2005&amp;volume=03&amp;issue=03&amp;spage=</dc:identifier>
<dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">todo</dc:format>
</rdf:Description>
</rdf:RDF>
</shortrecord></field>
  </record>
</documentresult>
</response>
</responsecollection>