Bug #11827

OAI-PMH returns cannotDisseminateFormat error when using "oai_ead" metadataPrefix

Added by David Juhasz over 4 years ago. Updated about 4 years ago.

Status:FeedbackStart date:12/27/2017
Priority:LowDue date:
Assignee:-% Done:

0%

Category:OAI-PMH
Target version:-
Google Code Legacy ID: Tested version:2.4, 2.5
Sponsored:No Requires documentation:

Description

Reported in forum (https://groups.google.com/forum/#!topic/ica-atom-users/qPvHjIJ0h5o) and reproduced on demo.accesstomemory.org

To reproduce:
  1. Enable OAI-PMH repository plugin
  2. Configure OAI-PMH Repository
  3. Attempt to List records with "oai_ead" metadataPrefix, e.g.
    https://demo.accesstomemory.org/;oai?verb=ListRecords&metadataPrefix=oai_ead
    

Resulting error:

<?xml version="1.0" encoding="utf-8" ?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>2017-12-27T19:42:02Z</responseDate>
  <request verb="ListRecords" metadataPrefix="oai_ead">https://demo.accesstomemory.org/;oai</request>
  <ListRecords>
              <error code="cannotDisseminateFormat">The metadata format identified by the value given for the metadataPrefix argument is available for item oai:demo.accesstomemory.org:demo_10267.</error>
        <resumptionToken>eyJmcm9tIjoiIiwidW50aWwiOiIiLCJjdXJzb3IiOjEsIm1ldGFkYXRhUHJlZml4Ijoib2FpX2VhZCIsInNldCI6IiJ9</resumptionToken>
    </ListRecords>
</OAI-PMH>

Expected result

The first record available should be returned in EAD XML format.


Related issues

Related to Access to Memory (AtoM) - Bug #10279: AtoM returns "badVerb" response instead of "cannotDissemi... Verified 09/07/2016
Related to Access to Memory (AtoM) - Bug #11829: OAI-PMH character encoding is invalid Verified 12/28/2017

History

#1 Updated by David Juhasz over 4 years ago

  • Related to Bug #10279: AtoM returns "badVerb" response instead of "cannotDisseminateFormat" when OAI-PMH request made for unavailable metadata format added

#2 Updated by David Juhasz over 4 years ago

  • Description updated (diff)

#5 Updated by David Juhasz over 4 years ago

  • Tested version 2.5 added

Tested and reproduced in qa/2.5.x

#6 Updated by David Juhasz over 4 years ago

  • Priority changed from Medium to High

#7 Updated by Dan Gillean over 4 years ago

  • Related to Bug #11829: OAI-PMH character encoding is invalid added

#8 Updated by Mike Cantelon over 4 years ago

  • Status changed from New to Feedback
  • Assignee set to David Juhasz

This is related to caching of XML representations of OAI data and error occurs when no cached XML representation of the EAD exists.

The error goes away if you run the cache thing:

./symfony cache:xml-representations

It relates to: https://projects.artefactual.com/issues/10680#note-9

I could add additional logic so the EAD is dynamically generated if the “Cache description XML exports upon creation/modification” setting is off. I’m thinking we might have deliberately avoided doing that, however… can’t remember.

#9 Updated by David Juhasz over 4 years ago

Thanks Mike. I don't think we should automatically generate an EAD document on load. However, when running a command like "ListRecords" that is not requesting a specific document, I think records with no EAD document generated should be omitted from the list, and a "cannotDisseminateFormat" error should not be returned. If a specific record (e.g. https://demo.accesstomemory.org/;oai?verb=GetRecord&identifier=oai:atom_demo:test/10001&metadataPrefix=oai_ead) is requested and the EAD document has not been generated then "cannotDisseminateFormat" is probably the best response.

#10 Updated by David Juhasz over 4 years ago

  • Assignee changed from David Juhasz to Mike Cantelon

#11 Updated by Dan Gillean over 4 years ago

Don't forget that one of our development changes for the oai_ead response was to only return 1 EAD record at a time when using the ListRecords verb for oai_ead. So if you have no EAD pre-generated, it's very likely you'll get a cannotDisseminateFormat response.

#12 Updated by Mike Cantelon over 4 years ago

  • Assignee changed from Mike Cantelon to David Juhasz

Given you and Dan's feedback it sounds like the current behaviour might be what we want then, unless I'm misreading.

#13 Updated by David Juhasz over 4 years ago

  • Assignee changed from David Juhasz to Mike Cantelon
Reading the definition of the error responses in https://www.openarchives.org/OAI/openarchivesprotocol.html#ListRecords, the two that seem relevant to me are:
  • cannotDisseminateFormat - The value of the metadataPrefix argument is not supported by the repository.
  • noRecordsMatch - The combination of the values of the from, until, set and metadataPrefix arguments results in an empty list.

Based on those definitions I think we should be returning "noRecordsMatch" in the case where "ListRecords" returns no valid results.

#14 Updated by Mike Cantelon over 4 years ago

cannotDisseminate applies to items, though, as well as repositories and our error text specifies this... "The metadata format identified by the value given for the metadataPrefix argument is not supported by the item or by the repository":

https://www.openarchives.org/OAI/openarchivesprotocol.html#ErrorConditions

It's kind of misleading (some kind of "record not currently available" error would be better), but maybe less so than "noRecordsMatch".

#15 Updated by Mike Cantelon over 4 years ago

  • Assignee changed from Mike Cantelon to David Juhasz

#16 Updated by David Juhasz over 4 years ago

  • Assignee changed from David Juhasz to Mike Cantelon

My reading is the definition of "cannotDisseminateFormat" depends on the context of the request. For sets of records it indicates that the repository does not support the metadata standard requested:

1. https://www.openarchives.org/OAI/openarchivesprotocol.html#ListIdentifiers

cannotDisseminateFormat - The value of the metadataPrefix argument is not supported by the repository.

2. https://www.openarchives.org/OAI/openarchivesprotocol.html#ListRecords

cannotDisseminateFormat - The value of the metadataPrefix argument is not supported by the repository.

Therefore "cannotDisseminateFormat" is not applicable to AtoM in these cases, because the repository does support "oai_ead".

At the individual record level, "cannotDisseminateFormat" indicates the request format is not available for the item:

3. https://www.openarchives.org/OAI/openarchivesprotocol.html#GetRecord

cannotDisseminateFormat - The value of the metadataPrefix argument is not supported by the item identified by the value of the identifier argument.

This is accurate for AtoM when the requested record does not have an EAD document available to serve.

Therefore, I still argue that "noRecordsMatch" is the correct response for the GetRecords and GetIdentifiers verbs, when the requested format is "oai_ead" and no records have an EAD representation available.

#17 Updated by Mike Cantelon over 4 years ago

Good point. noRecordsMatch sounds good to me then for listRecords.

#18 Updated by Mike Cantelon over 4 years ago

  • Assignee changed from Mike Cantelon to David Juhasz

How's this, as an example, for an error response?

<error code="noRecordsMatch">
The metadata format identified by the value given for the metadataPrefix argument is unavailable for item oai:192.168.168.194:goat_2.
</error>

This avoids implying that the repository doesn't support EAD, but communicates that the record returned by listRecords isn't available as EAD.

#19 Updated by David Juhasz over 4 years ago

Mike, I think that ListRecords should be treated as a result list showing a single result. If records "oai:192.168.168.194:goat_2" doesn't have an EAD representation then the first record that does have an EAD representation should be returned. If no records have an EAD representation then the error response should either be a general "No results" message like:

<error code="noRecordsMatch">
  No records found that match the supplied ListRecords request arguments
</error>

Or if it's possible to determine that the "metadataPrefix" value is the critical argument, then:

<error code="noRecordsMatch">
  No records available for metadataPrefix="oai_ead" 
</error>

#20 Updated by David Juhasz over 4 years ago

  • Assignee changed from David Juhasz to Mike Cantelon

#21 Updated by David Juhasz over 4 years ago

Also, keep in mind that ListRecords should return a "noRecordsMatch" error when no records match the "from", "until", or "set" arguments, in addition to the "metadataPrefix" argument.

#22 Updated by Mike Cantelon over 4 years ago

Okay, I'm going to have to rework the query logic then as it's currently just doing a LIMIT 1 query when EAD is fetched via ListRecord.

#24 Updated by Mike Cantelon about 4 years ago

  • Assignee changed from Mike Cantelon to David Juhasz

I'd estimate 4 to 8 maybe? The solution'd likely be a bit inelegant given we'd need to pull extra results (10? 100? 1000?) to check through until we get to something that's cached in which case we then need to calculate a new resumptiontoken for paging based on the row cursor position of the first row with a corresponding cache file (and if we don't find anything that is cached redirect to an error). I'm not sure it's really worth it given people's stuff is likely going to be completely cached or not cached at all, I'd guess.

#25 Updated by Dan Gillean about 4 years ago

  • Assignee deleted (David Juhasz)
  • Priority changed from High to Low
  • Target version deleted (Release 2.4.1)

Removing a target release from this at the moment - this is a minor fix (a change in the type of message returned) that would be nice to implement, but not worth 8 hours of time that could go into fixing more pressing bugs for our community.

Also available in: Atom PDF