Metadata Handling Workflow + Custom FormatIDs¶

Process Overview¶

Science metadata goes through several stages between the time it leaves the Member Node and the point in which an end user views the record's search result in search.dataone.org. These stages including synchronization, indexing, and view rendering.

for new formatid we need:
* a schema to refer to in metadata
* schema must be imported and registered into metacat. T his enables metacat to recognize it. (Jing?)
* To index /parse the meteadata data, we need indexing rules in place for that formatID. Modificaton of DCQ except url is in the (Jing)
* View Service - without rules for service it will pull what it finds from Solr and render. Since DC is so simple, should not be an issue (This doesn’t work well for more complicated formats). Just have to verify that it looks right.

Processing Requests for Customization¶

Who can handle what changes at each stage?

Indexing¶

Web display¶

Search¶

• Member Node Icon. TODO: How do we change a Member Node's icon (the one that appears on search.dataone.org)

Landing Page¶

We call the web view of a metadata record the landing page. An example of a landing page is https://search.dataone.org/#view/fridley.14.2.

The display of the landing page is dependent on two things directly:

1. The metadata record itself
2. MetacatUI

The dependency on MetacatUI can be further divided into two areas:

1. What theme MetacatUI is running (usually the 'dataone' theme)
2. How the Metacat View Service MetacatUI is pointing to is configured

The distinction between what part of the landing page is the Metacat UI theme (1) or the Metacat View Service can be seen in the following diagram. Everything outside the box tagged "Metacat View Service" is directly MetacatUI's responsibility and everything inside is dependent on the Metacat View Service.

The Metacat View Service is a web service (and part of the DataONE Member Node API) that takes a metadata record (an XML document), transforms it to HTML via an XSLT, and returns the HTML back to the calling agent (in this case, MetacatUI, which then injects that HTML into the container highlighted above). How the HTML injected back into the above container looks is dependent on two things:

1. The HTML the View Service's XSLT returns
2. The stylesheet(s) MetacatUI is using

Note that this means that MetacatUI and the Metacat View Service are thus linked in this way.

To change what HTML the Metacat View Service returns to MetacatUI, you need to find out what formatId you're dealing with then see what XSL your formatId is mapped to in MetacatUI in this file: lib/style/skins/metacatui/metacatui.xml.

• If your formatId already has a mapping, look at that XSL.
• If your formatId does not already have a mapping, add it by adding a block like this example of mapping Pangaea's metadata formatId to the main metacatui.xsl.

<!-- Pangaea-variant ISO 19115 metadata -->

/style/skins/metacatui/metacatui.xsl

Then, in that XSL, which calls out to other XSLs, you need to follow the XSL processing logic to determine which XSLs are called when your document passes through the root XSL. For example, with an ISO 19115 document, there is an xsl:if statement that'll catch the root element which calls the isodocument template:

<xsl:if test="*[local-name()='MD_Metadata'] | *[local-name()='MI_Metadata']">
  <xsl:call-template name="isodocument"/>
</xsl:if>

which is defined in the imported XSL:

<xsl:import href="./iso19115/isoroot.xsl"/>