MXR Son of CGI

MXR - Mapped Extensible Resources

The proposed DSpace functionality known as CGI (Context Guided Ingest) has assumed a new identity (or at least acronym) in mds, but the concepts are essentially the same. At the highest level, there are a small set of APIs that enable mapping of DSpaceObjects (typically - but not necessarily - Items) to 'resources' that are useful to them in various situations, such as submission, workflow, etc. The notion of a resource here is not confined much, but examples from DSpace might include: 'input forms' used by web submission, 'submission steps' used in configurable submission, 'item templates' used for metadata creation, etc. The mapping facility is indirect, and includes the ability to express higher-level 'rules', for maximum flexibility. What follows is a summary of the APIs and how they connect.

Scoped Object Attributes

The first API exposes a simple facility to assert persistent 'attributes' (i.e. name/value pairs) about any DSpaceObject. These attributes differ from generic metadata in several respects: there is no notion of qualification, language, etc - they are simple name/value pairs. They do not belong to the object's permanent curated state, and in this sense are outside the data model proper. Rather, they represent a way to persist useful state beyond in-memory representations. These attributes have one additional aspect: every attribute is relative to what is called a scope, which is essentially a named context of use. The primary function of scoping is to prevent attribute name collisions. The API is simple:

public void setAttribute(String scope, String name, String value)
public String getAttribute(String scope, String name)
public void clearAttributes(String scope)
public Set<String> getAttributeNames(String scope)

The clearAttributes call would typically be made when the object scope became irrelevant (e.g. when an object exits workflow), and all attributes are automatically purged when an object is deleted. The Object Attribute API has applicability beyond MXR - attributes could hold Workspace data (like the last page reached in a web submission), or workflow or curation results, etc.

Mapped Resources

At the other end, there is an API for mapping keys to named resources. A named resource in this context is a unique instance of a resource within a given class or type. To use an example from configurable submission (input-forms), "traditional" is the name of a given

stanza that describes the resource (which is a structured list of metadata prompts and UI info). We map that resource to given collection IDs: collection:123456789/1 -> "traditional" in the input-forms.xml file. The API is also simple (all the methods are attached to a ResourceMap object):

public void add(Context context, String key, String resId)
public void remove(Context context, String key)
public Set<String> keysFor(Context context, String resId)
public Object find(Context context, DSpaceObject dso, String scope)

The first three methods are relatively self-explanatory - adding, removing or querying the mappings to a specific resource with the name 'resId'. The last method requires a bit more explanation: it attempts to deliver a specific resource of a given type for an object in a given scope. How is this accomplished?