Page History

...

<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH>
...
<record>
    <header>
        <identifier>urn:uuid:fd23522ee5d037a0-c447633c-480111df-9be4a08a-c93c60a2d5500800200c9a66 </identifier>
        <datestamp>2009-06-02T14:10:02Z</datestamp>
    </header>
    <metadata>
        <context-objects xmlns="info:ofi/fmt:xml:xsd:ctx">
            <context-object> ... </context-object>object xmlns="info:ofi/fmt:xml:xsd:ctx" datestamp="2009-06-01T19:20:57Z">
            <context-object>  ...
            </context-object>
             </context-objects><context-object xmlns="info:ofi/fmt:xml:xsd:ctx" datestamp="2009-06-01T19:20:57Z">
    </metadata>
</          ...
            </context-object>
        </context-objects>
    </metadata>
</record>
...
</OAI-PMH>

In the aforementioned example, the OAI-PMH record is identified by a UUID (in form of a URI), see RFC 4122. When offering single <context-object> documents rather than an aggregation using <context-objects> containers like above, a conformal OAI-PMH record may look like the following:

<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH>
...
<record>
    <header>
        <identifier>urn:uuid:fd23522e-c447-4801-9be4-c93c60a2d550 </identifier>
        <datestamp>2009-06-02T14:10:02Z</datestamp>
    </header>
    <metadata>
        <context-object xmlns="info:ofi/fmt:xml:xsd:ctx" datestamp="2009-06-01T19:20:57Z">
          ...
        </context-object>
    </metadata>
</record>
...
</OAI-PMH>

<record>
    <header>
        <identifier>urn:uuid:1ad69103-6bd0-4a90-ae75-e4b644c136a6 </identifier>
        <datestamp>2009-06-02T14:10:04Z</datestamp>
    </header>
    <metadata>
        <context-object xmlns="info:ofi/fmt:xml:xsd:ctx" datestamp="2009-06-01T19:21:07Z">
          ...
        </context-object>
    </metadata>
</record>
...
</OAI-PMH>

5.2. SUSHI

OAI-PMH is a relatively light-weight protocol which does not allow for a bidirectional traffic. If a more reliable error-handling is required, the Standardised Usage Statistics Harvesting Initiative (SUSHI) must be used. SUSHI http://www.niso.org/schemas/sushi/ was developed by NISO (National Information Standards Organization) in cooperation with COUNTER. This document assumes that the communication between the aggregator and the usage data provider takes place as is explained in figure 1.

Figure 1.
The interaction commences when the log aggregator sends a request for a report about the daily usage of a certain repository. Two parameters must be sent as part of this request: (1) the date of the report and (2) the file name of the most recent robot filter. The filename that is mentioned in this request will be compared to the local filename. Four possible responses can be returned by the repository.

...