Print

Print


Many of the listserv software packages check to see whether messages 
sent to the list are identical to a previous message by computing the 
MD5 hash of the message. They compare it to all the MD5 hashes of 
previous messages and, if there is a match, reject the message. As a 
list matures, there are more and more chances of getting a spurious 
match. This happened to us at the Library Systems Office at UC Berkeley 
with a listserv package we used to use. I would tell people to alter 
their message slightly and resubmit it. Tedious, but it worked.

Garey Mills
Library Systems Office
UC Berkeley

Ray Denenberg, Library of Congress wrote:
> The problem is somewhat of a mystery and has been for several years, 
> but my guess is that it part random, and part load-related.  It seems 
> to have popped up on several messages today, in fact, my own message 
> (below) got flagged.  But I have certainly encountered it on other 
> lists including MODS. I think that there have been several METS 
> messages in the past day or so and few to the other lists, which is 
> why it appears that the problem is specific to METS; I don't think it 
> is.   In any case it is a very infrequent problem (which I think is 
> why it hasn't been addressed). --Ray
>
>     ----- Original Message -----
>     *From:* Rick Beaubien <mailto:[log in to unmask]>
>     *To:* [log in to unmask] <mailto:[log in to unmask]>
>     *Sent:* Monday, April 06, 2009 10:41 AM
>     *Subject:* Re: [METS] Fwd: Rejected posting to
>     [log in to unmask] <mailto:[log in to unmask]> (mptr to
>     higher-level object)
>
>     It seems to me that I don't encounter this problem when submitting
>     to the MODS or MIX lists.  Is there some difference in the way
>     these lists are configured? 
>
>     Rick Beaubien
>
>     Ray Denenberg, Library of Congress wrote:
>>     It's a chronic (minor) bug with the LC listserv software.  You
>>     can safely ignore it. 
>>
>>         ----- Original Message -----
>>         *From:* Stefan E. Funk <mailto:[log in to unmask]>
>>         *To:* [log in to unmask] <mailto:[log in to unmask]>
>>         *Sent:* Monday, April 06, 2009 8:11 AM
>>         *Subject:* [METS] Fwd: Rejected posting to
>>         [log in to unmask] <mailto:[log in to unmask]> (mptr to
>>         higher-level object)
>>
>>         Dear METS list,
>>
>>         I am just wondering why the mailserver thinks, the same
>>         message has already been sent by me (or someone else?) to the
>>         list... maybe there is someething wrong with the list-server?
>>         Or maybe with my mail-client?
>>
>>         I'll just retry now....
>>
>>         Best wishes.
>>         *fu*
>>
>>
>>         Begin forwarded message:
>>
>>>         *From: *"LISTSERV.LOC.GOV LISTSERV Server (14.5)"
>>>         <[log in to unmask] <mailto:[log in to unmask]>>
>>>         *Date: *6. April 2009 13:03:20 Uhr MESZ
>>>         *To: *"Stefan E. Funk" <[log in to unmask]
>>>         <mailto:[log in to unmask]>>
>>>         *Subject: **Rejected posting to [log in to unmask]
>>>         <mailto:[log in to unmask]>*
>>>
>>>         Your message is  being returned to you unprocessed because
>>>          it appears to have
>>>         already been distributed  to the METS list. That is,  a
>>>         message with identical
>>>         text (but  possibly with different mail  headers) has been
>>>         posted  to the list
>>>         recently, either by you or by someone  else. If you have
>>>         reason to resend this
>>>         message to the list (for instance because you have been
>>>         notified of a hardware
>>>         failure with loss of  data), please alter the text of the
>>>          message in some way
>>>         and resend it  to the list. Note  that altering the
>>>         "Subject:"  line or adding
>>>         blank lines at the top or bottom  of the message is not
>>>         sufficient; you should
>>>         instead add a sentence or two at  the top explaining why you
>>>         are resending the
>>>         message, so  that the other  subscribers understand  why
>>>         they are  getting two
>>>         copies of the same message.
>>>
>>>         *From: *"Stefan E. Funk" <[log in to unmask]
>>>         <mailto:[log in to unmask]>>
>>>         *Date: *6. April 2009 12:42:28 Uhr MESZ
>>>         *To: *[log in to unmask] <mailto:[log in to unmask]>
>>>         *Subject: **Re: [METS] mptr to higher-level object*
>>>         *Reply-To: *Metadata Encoding and Transmission Standard
>>>         <[log in to unmask] <mailto:[log in to unmask]>>
>>>
>>>
>>>         Dear METS-Community,
>>>
>>>         Fortunately the METS-Profile is available in English by now,
>>>         unfortunately only the PDF version:
>>>
>>>
>>>         http://dfg-viewer.de/en/profile-of-the-metadata/
>>>
>>>
>>>         Or use the direct link:
>>>
>>>
>>>         http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS_Application_Profile_2.0.pdf
>>>
>>>
>>>         The XML version will follow soon. As soon as it is
>>>         available, I will be glad to inform you immediately.
>>>
>>>         Happy Easter and best wishes from Göttingen.
>>>         *fu*
>>>
>>>
>>>         On 6. Apr 2009, at 12:05 Uhr, Enders, Markus wrote:
>>>
>>>>         Hi Jenn,
>>>>
>>>>         Probably you will not find a general solution for this
>>>>         problem at all. My experience is that the METS object may
>>>>         change over the life cycle of the resource. Depending on
>>>>         technical constraints and your purpose of the METS file you
>>>>         might need different solutions. With purpose I mean wether
>>>>         the METS describes a SIP, AIP or DIP.
>>>>
>>>>         At the British Library we are using the <mods:relatedItem>
>>>>         element for pointing up to the parent document if the METS
>>>>         file is describing a SIP. The volume / issue is only very
>>>>         loosley coupled with the parent object. As the SIPs are
>>>>         created somewhere (on some system) using a file system for
>>>>         storing their content files and METS descriptors, I don't
>>>>         regard a <mptr> as an appropriate method as those links
>>>>         could never be actionable (resolveable) in our current
>>>>         enviroment.
>>>>
>>>>         For the DIP the situation may be different. I would assume
>>>>         the DIP is disseminated from a repository. In this case a
>>>>         system will be available to resolve URIs. In this case I
>>>>         would regard the use of a <mptr> as a much better alternative.
>>>>         The METS profile of the DFG-Viewer
>>>>         (http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS_Anwendungsprofil_2.0.pdf)
>>>>         uses the <mptr> very similar to Jerry's suggestion:
>>>>
>>>>         <mets:structMap TYPE="LOGICAL">
>>>>          <mets:div LABEL="Zeitschrift" TYPE="Periodical">
>>>>
>>>>          <!-- Der METS-Pointer referenziert die METS-Datei der
>>>>         Zeitschrift / des Mehrbändigen Werkes -->
>>>>          <mets:mptr LOCTYPE="URL"
>>>>         xlink:href="http://link/to/mets/file/periodical" />
>>>>
>>>>             <!-- Hier beginnt die oben bereits besprochene
>>>>         Beschreibung des einzelnen Bandes -->
>>>>             <mets:div DMDID="DMD_00" ID="ex11__LOG_00"
>>>>         LABEL="Zeitschriftenband" TYPE="Volume">
>>>>
>>>>                <mets:div DMDID="DMD_01" ID="ex11__LOG_01"
>>>>         LABEL="Erstes Zeitschriftenheft" TYPE="Issue">
>>>>                   <mets:div ID="ex11__LOG_02" LABEL="Erster
>>>>         Artikel" TYPE="Article" />
>>>>                   <mets:div ID="ex11__LOG_03" LABEL="Zweiter
>>>>         Artikel" TYPE="Article" />
>>>>           </mets:div>
>>>>             </mets:div>
>>>>          </mets:div>
>>>>         </mets:structMap>
>>>>
>>>>         Unfortunately the profile is just available in German.
>>>>
>>>>
>>>>         Ciao
>>>>         Markus
>>
>>
>>         -- 
>>         Stefan E. Funk
>>         DP-D - Diensteportal Digitalisierung
>>         Goettingen State and University Library - The Historical
>>         Library Building
>>         Papendiek 14, 37073 Goettingen, Germany
>>         Phone: +49 551 39-7700 | 39-12170
>>         Mail: [log in to unmask]
>>         <mailto:[log in to unmask]>
>>
>>
>>
>>
>>
>
>     -- 
>     Rick Beaubien
>     Software Engineer, Research and Development
>     U.C. Berkeley Library
>
>     Contact information:
>     505-466-6630
>
>     88 Herrada Rd
>     Santa Fe, NM 87508
>