--simple boundary
Content-Type: text/plain; charset=US-ACSII
Content-Transfer-Encoding: 7bit
Message is undeliverable.
Reason: User "[log in to unmask]" is not found in the cc:Mail Directory.
Original text follows:
---------------------
--simple boundary
Content-Type: text/plain; charset=US-ACSII
Content-Transfer-Encoding: 7bit
Received: from rs8.loc.gov by library.sos.state.il.us (ccMail Link to SMTP R8.00.01)
; Fri, 17 Oct 97 15:16:47 -0600
Return-Path: <[log in to unmask]>
Received: from rs8 (rs8.loc.gov [140.147.248.8])
by rs8.loc.gov (8.8.4/8.8.4) with SMTP
id QAA85416; Fri, 17 Oct 1997 16:03:39 -0400
Received: from RS8.LOC.GOV by RS8.LOC.GOV (LISTSERV-TCP/IP release 1.8b) with
spool id 215507 for [log in to unmask]; Fri, 17 Oct 1997 16:03:37 -0400
Received: from sos.state.il.us (ftp.sos.state.il.us [199.15.1.2]) by
rs8.loc.gov (8.8.4/8.8.4) with SMTP id PAA74320 for <[log in to unmask]>;
Fri, 17 Oct 1997 15:53:36 -0400
Received: from library.sos.state.il.us (ccgate.sos.state.il.us [199.15.1.5]) by
sos.state.il.us (8.6.12/8.6.12) with SMTP id QAA06771 for
<[log in to unmask]>; Fri, 17 Oct 1997 16:07:10 -0500
Received: from ccMail by library.sos.state.il.us (ccMail Link to SMTP R8.00.01)
id AA877117637; Fri, 17 Oct 97 14:47:21 -0600
X-Mailer: ccMail Link to SMTP R8.00.01
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
Message-ID: <[log in to unmask]>
Date: Fri, 17 Oct 1997 14:47:17 -0600
Reply-To: Encoded Archival Description List <[log in to unmask]>
Sender: Encoded Archival Description List <[log in to unmask]>
From: [log in to unmask]
Subject: cc:Mail Link to SMTP Undeliverable Message
Comments: To: [log in to unmask]
To: Multiple recipients of list EAD <[log in to unmask]>
--simple boundary
Content-Type: text/plain; charset=US-ACSII
Content-Transfer-Encoding: 7bit
Message is undeliverable.
Reason: User "[log in to unmask]" is not found in the cc:Mail Directory.
Original text follows:
---------------------
--simple boundary
Content-Type: text/plain; charset=US-ACSII
Content-Transfer-Encoding: 7bit
Received: from rs8.loc.gov by library.sos.state.il.us (ccMail Link to SMTP R8.00.01)
; Fri, 17 Oct 97 14:47:13 -0600
Return-Path: <[log in to unmask]>
Received: from rs8 (rs8.loc.gov [140.147.248.8])
by rs8.loc.gov (8.8.4/8.8.4) with SMTP
id PAA113208; Fri, 17 Oct 1997 15:48:52 -0400
Received: from RS8.LOC.GOV by RS8.LOC.GOV (LISTSERV-TCP/IP release 1.8b) with
spool id 215458 for [log in to unmask]; Fri, 17 Oct 1997 15:48:50 -0400
Received: from enterprise.computing.csbsju.edu (enterprise.computing.csbsju.edu
[152.65.233.150]) by rs8.loc.gov (8.8.4/8.8.4) with ESMTP id
PAA110124 for <[log in to unmask]>; Fri, 17 Oct 1997 15:37:59 -0400
Received: by enterprise.computing.csbsju.edu with Internet Mail Service
(5.0.1458.49) id <4QCCG2Q9>; Fri, 17 Oct 1997 14:37:16 -0500
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <[log in to unmask]>
Date: Fri, 17 Oct 1997 14:37:14 -0500
Reply-To: Encoded Archival Description List <[log in to unmask]>
Sender: Encoded Archival Description List <[log in to unmask]>
From: "Berres, Peregrin" <[log in to unmask]>
Subject: Re: Query re: character normalization
To: Multiple recipients of list EAD <[log in to unmask]>
Timothy,
I am eagerly looking for UNICODE to solve similar problems in our =
CD-ROM
In Principio. The program works around lots of replacements for
Medieval Latin e.g. hymn* can find hymus, ymnus, hympnus, etc, but
M=DCNICH causes problems! =20
However, UNICODE will work on Windows NT and beyond. So... right back
at the starting blocks.
Peregrin Berres, OSB
Hill Monastic Manuscript Library
Collegeville, MN 56321
----------
From: Timothy Young[SMTP:[log in to unmask]]
Sent: Friday, October 17, 1997 1:31 PM
To: Multiple recipients of list EAD
Subject: Query re: character normalization
Now that we all seem to be moving in the direction of
understanding
and implementing SGML mark-up, I am going to open a can of worms
about a further step in making finding aids usable...namely:
Character Normalization
In the development of our Finding Aids site at Yale, we were
happy to realize that we could code non-Latin (extended)
characters=20
so they would appear properly, thanks to the Special Characters
Entity
component.
When our finding aids were online, we tested the search
interface and found
that, indeed, we could find extended characters by keying-in
ASCII
number sequences (e.g. Alt-130 =3D =E9). However, the wind left our
sails
when we realized that this was the ONLY way to search extended
characters.
Therefore, a researcher looking through our collection of Goethe
manuscripts
will
have to learn to type like a programmer to find all of the
relevant names she
desires.
Knowing that there are other problems that arise, such as an
inconsistency
in using extended characters, and local practice, I wonder if
anyone has
any advice/direction/comments on what can be done as far as what
I
refer to as "character normalization".
I envision a system that - on the search interface - is able to
map all
accented versions of Latin characters to their unaccented
equivalents.
(e.g. - =E9, =EB, etc. would map to e)
Is this the way to go? Is anybody aware of a system that can do
such
a normalization? Our default strategy is to do what we have done
with our in-house database - keep a "printable" version with
extended
characters - and create a database version with extended
characters stripped
out and replaced by Latin equivalents.
Any response would be welcome, even regarding correct
terminology for this
question.
Timothy Young
Archivist
Beinecke Rare Book and Manuscript Library
Yale University
New Haven, CT 06520
(203) 432-8131
--simple boundary--
--simple boundary--
|
