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

From Mariana Pichinini
DateSat Mar 20 01:54:11 2010
Subject [greenstone-devel] Re: OAI protocol datestamps (was reformat dates in a collection?)
In-Reply-To (4BA29750-8010706-bates-edu)
Hi Jim

This is a bug. See the ticket http://trac.greenstone.org/ticket/665. It
will be fixed for the next release, I hope.

If the metadata schemma is not Dublin Core, no problem. Nevertheless, if
you want to validate OAI, you can to change globally the DC.date tag by
any other one and to prove.

Best regards
Mariana

> 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.
>>
>>
>