--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) ; Sat, 18 Oct 97 17:53:48 -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 SAA148242; Sat, 18 Oct 1997 18:42:46 -0400 Received: from RS8.LOC.GOV by RS8.LOC.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 216090 for [log in to unmask]; Sat, 18 Oct 1997 18:42:44 -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 SAA72168 for <[log in to unmask]>; Sat, 18 Oct 1997 18:32:43 -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 SAA09479 for <[log in to unmask]>; Sat, 18 Oct 1997 18:46:57 -0500 Received: from ccMail by library.sos.state.il.us (ccMail Link to SMTP R8.00.01) id AA877214469; Sat, 18 Oct 97 17:41:11 -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: Sat, 18 Oct 1997 17:41:09 -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) ; Sat, 18 Oct 97 17:41:07 -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 SAA82510; Sat, 18 Oct 1997 18:29:41 -0400 Received: from RS8.LOC.GOV by RS8.LOC.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 216071 for [log in to unmask]; Sat, 18 Oct 1997 18:29:39 -0400 Received: from sos.state.il.us (sos.state.il.us [199.15.1.2]) by rs8.loc.gov (8.8.4/8.8.4) with SMTP id SAA133626 for <[log in to unmask]>; Sat, 18 Oct 1997 18:19:37 -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 SAA09463 for <[log in to unmask]>; Sat, 18 Oct 1997 18:33:47 -0500 Received: from ccMail by library.sos.state.il.us (ccMail Link to SMTP R8.00.01) id AA877213678; Sat, 18 Oct 97 17:28:05 -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: Sat, 18 Oct 1997 17:27:58 -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) ; Sat, 18 Oct 97 17:27:54 -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 QAA88578; Sat, 18 Oct 1997 16:42:43 -0400 Received: from RS8.LOC.GOV by RS8.LOC.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 215644 for [log in to unmask]; Sat, 18 Oct 1997 16:42:41 -0400 Received: (from rbar@localhost) by rs8.loc.gov (8.8.4/8.8.4) id RAA48546 for [log in to unmask]; Fri, 17 Oct 1997 17:03:13 -0400 Message-ID: <[log in to unmask]> Date: Fri, 17 Oct 1997 17:03:13 -0400 Reply-To: Encoded Archival Description List <[log in to unmask]> Sender: Encoded Archival Description List <[log in to unmask]> From: Randall Barry <[log in to unmask]> Subject: Character normalization Comments: To: [log in to unmask] To: Multiple recipients of list EAD <[log in to unmask]> Timothy Young at Yale posed an interesting question about the indexing and retrieval for special characters. To his dismay, he realized that if special characters are encoded in EAD finding aids, those same characters must be used in searching unless some special accommodation is made somewhere. This problem confronted early library systems too. Having the special marks associated with "ordinary" alphabetic characters was one way to get around the problem. That's one of the reasons the USMARC character sets treat modifying marks (accents, etc.) as separate characters. It makes it much easier for indexing and retrieval systems to ignore the specialness of special characters. This solution won't work for special characters that are more than just an ordinary letter with a special mark (for example, the "thorn" used in Icelandic). In many system, nonspecialized characters are associated with special characters for indexing and retrieval (for example, thorn can be indexed and retrieved as an ordinary "d"). I'm not suggesting that the bibliographic (i.e., MARC) solution is the best for archival finding aids, but it is one solution. Regardless of the solution, it will require special provisions, rules, programming, and training of users to search when special characters are involved. There is not an easy solution. Developers of ISO 10646, the Universal Coded Character Set, and implementations of it like Unicode(tm), are concerned with issues such as indexing, retrieval, sorting, etc. As more characters come to be available to us, using them in search and retrieval will become a challenge. Perhaps we should look at authority files or thesauri as a possible solution. When people search for matches to text strings, they should be given help if variations are possible. If searching Muller is intended to also bring back M"uller and Mueller, authority and thesauri systems can help guide the users. I don't think the solution need necessarily burden the EAD group. It's a general problem with data nowadays that involves rich character data. Applications that can handle special characters for printing, display, and retrieval need to provide the solution. I rather us not try to fix it withing the scope of the EAD DTD. --Randy Barry ***************************************************************** * Randall Keigan Barry LL * * Senior MARC Standards Specialist LLL * * U.S. Library of Congress LLL * * Network Development and MARC Standards Office LLL CCCCC * * 101 Independence Avenue, S.E. LLL CCC CCC * * Washington, DC 20540-4102 U.S.A. LLL CCC * * TEL: +1-202-707-5118 LLLLLLLLLL * * FAX: +1-202-707-0115 CCC CCC * * NET: [log in to unmask] CCCCC * ***************************************************************** * NOTE: The ideas and opinions expressed in this communication * * are personal and do not necessarily reflect the position of * * the Library of Congress or any other U.S. government agency. * ***************************************************************** --simple boundary-- --simple boundary-- --simple boundary--