May I add some other annoyance from OAI server, that would be nice to get
I reported this behaviour since version 2.74, when I start testing. We
here got a workaround, but I see this same problem still is present, from
reports I was reading about 2.82 in the spanish mailing list.
I explain: where among the metadata reported is a DC.date tag, the OAI
server treats this as a datestamp for the register.
In common practice, this DC.date metadata means the publishing date for a
resource, and since this is a internal resource, it usually is not
formatted ISO 8601 compliant; in consequence, when OAI server try to read
it, it reports a validation fail (I.e. with Open Archives or validators
I don't know the reason for the OAI server to take this DC.date as a
datestamp; AFAIK, the most reliable date to take in such a way is the
modified date for a source document, which you can take from the
'lastmodified' metadate, present in doc.xml. This is the date that's got
everywhere there is no DC.date tag, and I think this is the only one tag
that that date should be read from.
When the collection do not implement Dublin Core in their metadata, there
is no such trouble. So this mislead is not always raising...
I hope this could be helping to get Greenstone on OAI succesful. Thanks
you very much for your attention.
Best regards to you all
Lic. Mariana Pichinini
BIBHUMA - Biblioteca Profesor Guillermo Obiols
Facultad de Humanidades y Ciencias de la Educaci□n
Universidad Nacional de La Plata
Calle 48 entre 6 y 7 - 1er subsuelo
B1900AMW LA PLATA, Argentina
Telefax: +54-221-4230125 interno 162 (l□neas rotativas)
> Hi all
> I have just had a quick look at the URL in identifier problem. I don't
> think there is any existing metadata that is suitable to be mapped, so
> the solution will have to involve source code modification of oaiserver.
> I have added a ticket to trac, which contains a few more details of the
> Hopefully I will be able to work on this early next year.