[greenstone-devel] OAI protocol datestamps (was reformat dates in a collection?)

From Jim Hart
DateFri Mar 19 10:13:09 2010
Subject [greenstone-devel] OAI protocol datestamps (was reformat dates in a collection?)
In-Reply-To (D6B530A1090A224EA17A37D3BFE35F5E39F3E6A6A9-XVS2-CLUSTER-yu-yale-edu)
Thanks, Arthur. You're right. GLI updates in the 'import' tree, so it'll
be easy to reformat our dates with a program.

It turns out that the fundamental problem may lie in how the
'oaiserver.cgi' is behaving. If our metadata contains a dc.Date field or
one of our fields mapped to dc.Date, oaiserver.cgi supplies that date as
a 'datestamp' for the item. But,
http://www.openarchives.org/OAI/openarchivesprotocol.html#Datestamp says:

" Repositories *must* support selective harvesting with the |from| and
|until| arguments expressed at day granularity. ... A repository *must*
update the datestamp of a record if a change occurs ...

Repositories *must* use the following rules to create a |ListRecords|
<http://www.openarchives.org/OAI/openarchivesprotocol.html#ListRecords>
response matching the specified datestamp range according to the type of
change that occurred within the repository. The response to a
|ListIdentifiers
<http://www.openarchives.org/OAI/openarchivesprotocol.html#ListIdentifiers>|
request follows the same rules but is abbreviated to include only
headers rather than records.

* /modification/ - the response *must* include records,
corresponding to the |metadataPrefix|
<http://www.openarchives.org/OAI/openarchivesprotocol.html#metadataPrefix>
argument, which have changed within the bounds of the |from| and
|until| arguments.
* /creation/ - the response *must* include records, corresponding to
the |metadataPrefix|
<http://www.openarchives.org/OAI/openarchivesprotocol.html#metadataPrefix>
argument, that have become available from the repository within
the bounds of the |from| and |until| arguments.
* /deletion/ - depending on the level at which a repository keeps
track of deleted records
<http://www.openarchives.org/OAI/openarchivesprotocol.html#DeletedRecords>,
the response *may* include headers of records, corresponding to
the |metadataPrefix|
<http://www.openarchives.org/OAI/openarchivesprotocol.html#metadataPrefix>
argument, which have been withdrawn from the repository within the
bounds of the |from| and |until| arguments. Deleted status is
indicated via the status attribute of the header
<http://www.openarchives.org/OAI/openarchivesprotocol.html#header>
element and no metadata is included.

Every header
<http://www.openarchives.org/OAI/openarchivesprotocol.html#header>
returned by the |GetRecord|
<http://www.openarchives.org/OAI/openarchivesprotocol.html#GetRecord>,
|ListRecords|
<http://www.openarchives.org/OAI/openarchivesprotocol.html#ListRecords>
or |ListIdentifiers|
<http://www.openarchives.org/OAI/openarchivesprotocol.html#ListIdentifiers>
requests contains a datestamp, which reflects the most recent date and
time of the creation, modification, or deletion according to the rules
defined above."

Note the last sentence. It seems clear that these datestamps aren't
related to the Dublin Core 'Date' element, which is maintained manually
and intended to represent "A point or period of time associated with an
event in the lifecycle (sp) of the resource." For example, one of our
items is a photograph taken sometime in 1895, so we set the dc.Date
field to '1895'.

Does anyone have a suggestion of what to do? Is there a way to configure
the OAI server so it complies with the above protocol specifications?

Jim Hart
Bates College

On 3/18/10 11:16 AM, Belanger, Arthur wrote:
> How was the metadata changed? Through the GLI? If so, then the metadata.xml files should have been changed by the GLI, at least this is my understanding of how the system works; we do not use the GLI.
>
> After changing the metadata.xml files, I would do use:
>
> Import.pl -removeold collectionname
>
> This will remove all items in the archives tree and reimport the entire collection.
>
> This strategy will not work if you changed the metadata by editing the doc.xml files created by the import process.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://list.scms.waikato.ac.nz/mailman/private/greenstone-devel/attachments/20100318/0c644df1/attachment.html