Metadata For Workflows

Instead of the LEAD Metadata Schema (LMS) used with XMC Cat in the LEAD project, this is an alternate metadata schema for tracking metadata about workflow definitions based on the JSDL for the workflow and some addtitional attributes that are compatible with unqualifed Dublin Core elements to the extent they do not duplicate metadata already captured in the JDSL. Since each object stored in XMC Cat must have a unique ID, this metadata schema has a required ID element even though the ID in the JSDL schema is optional. Also, the additional elements that are compatible with Dublin Core directly reference the simple Dublin Core schema. A simple cross-walk would be needed to get a Dublin Core or OAI-PMH compatible output based on unqualified Dublin Core.

For the elements that come from the JSDL schema, many are directly referenced, but other elements are defined that then contain some of the leaf elements from the JSDL schema. There are two reasons that elements are not referenced directly. The predominate reason for not directly referencing a JSDL schema element is that many allow for the inclusion of any additional XML content or XML attributes from any other namespace. Since the syntax of this additional content is not defined in the schema, it could not be indexed to search (however all of the content is still available in the full JSDL instance). In the case of some of the resource elements (e.g., CPU speed) are grouped into an architecture element in the metadata schema.

Usually the metadata schema used in XMC Cat would contain only metadata and the data would be stored separately. Since the data in this case is the XML based on the JSDL schema, the metadata schema also contains the full JSDL the metadata is based on as a property so it can be easily retrieved.

What is the XMC Cat Domain Metadata Schema?
The XMC Cat schema (used in the wsdl for XMC Cat) is composed of three schema files that are compiled into two jars. The first jar is the XMC Cat types jar (xmccat-types-metadata-1.x.x.jar) and it contains the xmccat-types-metadata.xsd and xmccat-status.xsd schema files. These schemas are generic for XMC Cat across all domains regardless of the domain schema being used (such as the workflow metadata schema or the LEAD schema). The second jar is the domain metadata jar (jsdl-xmccat-domain-metadata-1.0.0.jar for the workflow schema). This jar contains the domain-specific element of the XMC Cat schema. This schema tells XMC Cat what the root element of a metadata document is in each domain's schema and the elements within that schema that can be added or updated after the initial metadata is added.

Changes in the Types Jar from the myLEAD Version
Prior to implementing the JSDL-based metadata schema in XMC Cat, the schema for XMC Cat was already divided into 3 separate schema files:
    catalog_types.xsd
    catalog_status.xsd
    domain_properties.xsd
All of these were compiled into a single jar - the latest version (as of December 1, 2008) was mylead-catalog-types-1.0.15.jar. The domain schema contains references to elements in the LEAD schema to specify the root element for new metadata objects (LEADResource) and those elements that represent concepts in the LEAD schema and can be added, updated or used as property filters when filtering the content of a query response. To minimize the configuration changes when a new domain is implemented, the types and status are now contained in one jar: xmccat-types-metadata-1.0.1.jar and the references to the domain schema are contained in a separate jar: jsdl-xmccat-domain-metadata-1.0.1.jar. However, query and response elements that are based on complex types that include domain references had to be moved to the domain schema (which now has its own namespace). When switching from the prior mylead types jar to the new xmccat types and domain jars, the only code change that should be required is to include the following additional import statement:
    import edu.indiana.dde.metadata.catalog.domain.*;
This is in addition to the import you already have:
    import edu.indiana.dde.metadata.catalog.types.*;
The types and domain jars also need to be on your classpath as well as the jar for the domain-specific schema.

The elements and related types that moved from the types to the domain schema are:
   catalogDataType
   objectResponse and objectResponseType
   propertyResponse and propertyResponseType
The catalogDataType is used when inserting a new metadata object. The objectResponse and propertyResponse are used in query responses that contain objects based on the full schema content filter or contain only selected concepts from the metadata schema based on the property filter.

---