From MAILER-DAEMON Fri Feb 25 17:55:00 2000 Date: Fri, 25 Feb 2000 17:55:00 -0800 (PST) From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA X-IMAP: 0951530100 0000000000 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From howard@info.sims.berkeley.edu Thu Feb 10 07:55:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id HAA13232 for ; Thu, 10 Feb 2000 07:55:19 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id HAA56880; Thu, 10 Feb 2000 07:55:16 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 376784 for CDL-TAS@LISTSERV.UCOP.EDU; Thu, 10 Feb 2000 07:55:15 -0800 Received: from library.berkeley.edu (library.Berkeley.EDU [169.229.32.48]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id HAA40376 for ; Thu, 10 Feb 2000 07:55:08 -0800 Received: from b_hurley (doenx-245A-2.Lib.Berkeley.EDU [128.32.224.25]) by library.berkeley.edu (8.9.1a/8.9.1) with SMTP id HAA18766 for ; Thu, 10 Feb 2000 07:54:32 -0800 (PST) X-Sender: bernie@library.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Mime-Version: 1.0 Message-ID: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> Date: Thu, 10 Feb 2000 07:52:58 -0800 Reply-To: Bernie Hurley Sender: CDL Technical Architecture and Standards Workgroup List From: Bernie Hurley Subject: PID - What's the Problem and the Scope To: CDL-TAS@LISTSERV.UCOP.EDU Content-Type: text/enriched; charset="us-ascii" Content-Length: 3336 Hi.... Well, I've only heard from Regan on the discussion process, so I'm going to assume silence = agreement! Here's an introduction to the first discussion issue, just to kick us off. What's the problem? There is an ever increasing number of URL's in our library systems (Melvyl, A&I databases, CDL directory, OAC, local catalogs, etc.) that break every time files are moved from URL path to another. So, the solution would be to find a cost effective way to create "more persistent ID's" that can live in our systems? By "more persistent," I mean that we're not trying to solve the long term archival problem, but rather implement something that can migrate to that solution once the URN community comes to some agreement. I'm not sure what "cost effective" means, but this has to do with implementation issues and is already on the "discussion list." *** Add to discussion list -> How do we create a PID system that has the best chance of migrating forward to a URN solution? Scope As Regan pointed out in his last e-mail, we need to specify the time period as part of the "scope". He expects we will create t a solution similar to URL redirection for the coming year, with the opportunity to migrate to a true data handling system within 3 years. This sounds right to me. I think we agreed that in our first implementation, we would stick to library systems. We understand faculty needs for PIDs with regards to their publications and the greater needs within UC, as a whole. However, broadening the scope beyond libraries would take us into a new "political" arena and greatly complicate any discussion. Within the scope of library systems, we have two communities that have the power to "break" URLs. Us and them. "Us" is for the digital materials that we create and manage on UC storage. For example, the OAC images are still on the Sunsite at Berkeley. What's going to happen to all the URLs in our EADs, once we move these images to the CDL - their new home? The "Them" is for the URLs we load into our systems from vendors (publishers and aggregators). If a vendor changes the locations for their files (i.e., their URLs), would we best solve this problem by replacing them, in a batch run, within our systems? Or, would it be better handled within a mapping table? Someone pointed out that by using a mapping table, PIDs copied out of our systems into class instructional sites, would still work. Ken, does the CDL dynamically create any URL links for vendors, based on metadata in the record? I wouldn't think so, but..... ....B P.S. Here's the future discussion list, so far. *What Problem are we trying to solve and for what scope of materials? *What are the "implementation" issues for a PID solution in libraries? (Is the cure more painful than the diseases?) *What kind of name spaces do we need? *How do we create a PID system that has the best chance of migrating forward to a URN solution * LAST - Revisit the technical solution (URL redirection) to see if it still works, after these other discussions. Bernie Hurley Director for Library Technologies UC Berkeley Library Rm 245, Doe Library Berkeley, CA 94720 bernie@library.berkeley.edu (510)-642-3773 (510)-643-8179 (fax) From howard@info.sims.berkeley.edu Thu Feb 10 10:49:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id KAA21369 for ; Thu, 10 Feb 2000 10:49:48 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id KAA57598; Thu, 10 Feb 2000 10:49:45 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 377681 for CDL-TAS@LISTSERV.UCOP.EDU; Thu, 10 Feb 2000 10:49:42 -0800 Received: from [128.48.10.206] (bessy.ucop.edu [128.48.10.206]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id KAA23364; Thu, 10 Feb 2000 10:49:39 -0800 Mime-Version: 1.0 X-Sender: kweiss@popserv.ucop.edu References: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> Message-ID: Date: Thu, 10 Feb 2000 10:49:27 -0800 Reply-To: Ken Weiss Sender: CDL Technical Architecture and Standards Workgroup List From: Ken Weiss Subject: Re: PID - What's the Problem and the Scope Comments: cc: margery.tibbetts@ucop.edu To: CDL-TAS@LISTSERV.UCOP.EDU In-Reply-To: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Length: 5329 At 7:52 AM -0800 2/10/00, Bernie Hurley wrote: Well, I've only heard from Regan on the discussion process, so I'm going to assume silence = agreement! That's true for me. What's the problem? There is an ever increasing number of URL's in our library systems (Melvyl, A&I databases, CDL directory, OAC, local catalogs, etc.) that break every time files are moved from URL path to another. So, the solution would be to find a cost effective way to create "more persistent ID's" that can live in our systems? By "more persistent," I mean that we're not trying to solve the long term archival problem, but rather implement something that can migrate to that solution once the URN community comes to some agreement. I'm not sure what "cost effective" means, but this has to do with implementation issues and is already on the "discussion list." I would state the problem from a slightly different angle. Within our library systems we need to be able to refer to networked resources over which we have little or no direct control. A mechanism is required that separates the management of an object on a server from the reference used to retrieve that object. I look at it like this because it makes it a bit more explicit that we're really wrestling with a business process issue - one organization is maintaining a resource, and a different and wholly unrelated organization is referring to it. This view sharpens the key problem, which is assigning responsibility for the maintenance of the mapping from the reference to the object itself. *** Add to discussion list -> How do we create a PID system that has the best chance of migrating forward to a URN solution? I'm not sure we need this as a separate topic/criterion. I find it hard to imagine an interim system we might adopt that wouldn't be driven by some sort of database underneath the covers. If that's the case, future migration should be possible regardless of the URN solution. Scope As Regan pointed out in his last e-mail, we need to specify the time period as part of the "scope". He expects we will create t a solution similar to URL redirection for the coming year, with the opportunity to migrate to a true data handling system within 3 years. This sounds right to me. Agreed. I think we agreed that in our first implementation, we would stick to library systems. We understand faculty needs for PIDs with regards to their publications and the greater needs within UC, as a whole. However, broadening the scope beyond libraries would take us into a new "political" arena and greatly complicate any discussion. Agreed. Within the scope of library systems, we have two communities that have the power to "break" URLs. Us and them. "Us" is for the digital materials that we create and manage on UC storage. For example, the OAC images are still on the Sunsite at Berkeley. What's going to happen to all the URLs in our EADs, once we move these images to the CDL - their new home? The "Them" is for the URLs we load into our systems from vendors (publishers and aggregators). If a vendor changes the locations for their files (i.e., their URLs), would we best solve this problem by replacing them, in a batch run, within our systems? Or, would it be better handled within a mapping table? Someone pointed out that by using a mapping table, PIDs copied out of our systems into class instructional sites, would still work. Ken, does the CDL dynamically create any URL links for vendors, based on metadata in the record? I wouldn't think so, but..... See my earlier comment on the problem definition - this kind of 'us and them' analysis is exactly what I was talking about. The CDL is now generating URLs on the fly based on vendor-supplied metadata for about 2600 journal titles. For the Wiley materials we're using DOIs, resolving the current location of the object through a series of lookups against Wiley's database and the central DOI registry. So, that's a complication that we'll need to address early on. Margery Tibbetts (Margery.Tibbetts@ucop.edu) is the CDL guru on how linking works right now in Melvyl, and it might be useful for her to participate in some of these discussions. ....B P.S. Here's the future discussion list, so far. *What Problem are we trying to solve and for what scope of materials? *What are the "implementation" issues for a PID solution in libraries? (Is the cure more painful than the diseases?) *What kind of name spaces do we need? *How do we create a PID system that has the best chance of migrating forward to a URN solution * LAST - Revisit the technical solution (URL redirection) to see if it still works, after these other discussions. --Ken ------------------------------------------------------------------------- Ken Weiss ken.weiss@ucop.edu California Digital Library Technologies (510) 710-3356 (voice) UC Office of the President (510) 763-2471 (fax) 1111 Franklin Street #7313B ken.weiss.pager@ucop.edu (text page) Oakland, CA 94607-5200 http://dcas.ucdavis.edu/kenhome.html PGP public key stored at: ldap://certserver.pgp.com http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=ken+weiss From howard@info.sims.berkeley.edu Tue Feb 15 08:35:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id IAA06743 for ; Tue, 15 Feb 2000 08:35:34 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id IAA42998; Tue, 15 Feb 2000 08:35:29 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 371978 for CDL-TAS@LISTSERV.UCOP.EDU; Tue, 15 Feb 2000 08:35:28 -0800 Received: from library.berkeley.edu (library.Berkeley.EDU [169.229.32.48]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id IAA43314; Tue, 15 Feb 2000 08:35:27 -0800 Received: from b_hurley (doenx-245A-2.Lib.Berkeley.EDU [128.32.224.25]) by library.berkeley.edu (8.9.1a/8.9.1) with SMTP id IAA25974; Tue, 15 Feb 2000 08:34:49 -0800 (PST) X-Sender: bernie@library.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) References: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> Mime-Version: 1.0 Message-ID: <3.0.5.32.20000215083309.00b5b9a0@library.berkeley.edu> Date: Tue, 15 Feb 2000 08:33:09 -0800 Reply-To: Bernie Hurley Sender: CDL Technical Architecture and Standards Workgroup List From: Bernie Hurley Subject: Re: PID - What's the Problem and the Scope Comments: To: Ken Weiss To: CDL-TAS@LISTSERV.UCOP.EDU In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Length: 5394 Ken... I liked your redefinition of the problem! However, I don't think you went far enough to explain why this business process problem is a something that libraries should worry about. So, I tried to merge our text. I also tried to re-write the narrative so it could be better understood by people outside our group, as I assume we will have to write something, at some point. Howver, as you will see, I'm not at the level of trying to word-smith yet. All.... So, given silence = consent, please take a look at this and respond soon if you have any suggestions, or I'll move us to the next discussion issue. Thanks, B. ---------------------------------- What's the Problem? Within our library systems we need to be able to refer to networked resources over which we have little or no direct control. Currently, this reference is most often implemented as a URL. A mechanism is required that separates the management of an object on a server from the reference used to retrieve that object. This becomes a business process issue - one organization is maintaining a resource (e.g., a publisher, an aggregators, etc.) and a different and wholly unrelated organization is referring to it (e.g, the UC Libraries) This business process problem is important to libraries, as it manifests itself as "broken URLs." There is an ever increasing number of URL's in our library systems (Melvyl, A&I databases, CDL directory, OAC, local catalogs, etc.) that break every time files are moved from one URL path to another. So, the solution would be to find a cost-effective way for UC libraries to mange the references to the objects, even though another organization manages the objects on their remote servers. The Proposed Solution One way to manage the references would be to create a more Persistent ID (PID) that can live in our systems in place of URLs. When the PID is selected in a Web browser, it would be translated to the current URL through a mapping system. The current URL would then be called by issuing an HTTP redirect. In this solution, the references to objects are now managed by the UC libraries via the mapping system. By "more persistent," we mean that we're not trying to solve the long-term archival problem, but rather implement something that can migrate to that solution once the URN community comes to some agreement on a standard solution. We expect we will create a solution using URL redirection for the coming year, with the opportunity to migrate to a true data handling system within 3 years. By cost-effective we mean that the labor and technology cost of running the system is less than just fixing the URLs, as they break. [This is another whole topic of discussion] Scope In our first implementation, we would focus on fixing the problem in library systems. We understand other groups also need to address this problem (e.g., faculty needs for PIDs with regards to their publications and the greater needs within UC, as a whole). However, broadening the scope beyond libraries would take us into a new "political" arena and greatly complicate any discussion and implementation Within the scope of library systems, we have two communities that have the power to "break" URLs. Us and them. "Us" is for the digital materials that UC creates and manages on UC servers. For example, the OAC images are still on the Berkeley SUNsite. Therefore all the URLs in our EADs will break, once we move these images to the CDL - their new home. The "Them" is for the URLs we load into our systems from vendors (e.g., publishers and aggregators). If a vendor changes the locations for their files (i.e., their URLs), would we best solve this problem by replacing them, in a batch run, within our systems? Or, would it be better handled within a mapping table? Using a mapping table has the added advantage that PIDs copied out of our systems into class instructional sites would still work. FUTURE DISCUSSION *** Add to discussion list -> How do we handle dynamically created URLs? *** Add to discussion list -> How do we create a PID system that has the best chance of migrating forward to a URN solution? Then Bernie Responded -- Here I was referring to creating a URN like name for our persistent ID's that could migrate forward to a true URN - someday. Ken Responded -- I'm not sure we need this as a separate topic/criterion. I find it hard to imagine an interim system we might adopt that wouldn't be driven by some sort of database underneath the covers. If that's the case, future migration should be possible regardless of the URN solution. ....B P.S. Here's the future discussion list, so far. *What Problem are we trying to solve and for what scope of materials? *What are the "implementation" issues for a PID solution in libraries? (Is the cure more painful than the diseases?) *How do we handle dynamically created URLs? *What kind of name spaces do we need? *How do we create a PID naming system that has the best chance of migrating forward to a URN solution * LAST - Revisit the technical solution (URL redirection) to see if it still works, after these other discussions. Bernie Hurley Director for Library Technologies UC Berkeley Library Rm 245, Doe Library Berkeley, CA 94720 bernie@library.berkeley.edu (510)-642-3773 (510)-643-8179 (fax) From howard@info.sims.berkeley.edu Tue Feb 15 19:55:00 2000 -0800 Status: X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id TAA15936 for ; Tue, 15 Feb 2000 19:55:41 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA48282; Tue, 15 Feb 2000 19:55:39 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 376808 for CDL-TAS@LISTSERV.UCOP.EDU; Tue, 15 Feb 2000 19:55:38 -0800 Received: from billthecat.sdsc.edu (billthecat.sdsc.edu [132.249.20.60]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA36068 for ; Tue, 15 Feb 2000 19:55:37 -0800 Received: from [198.202.73.212] (d12.remote.sdsc.edu [198.202.73.212]) by billthecat.sdsc.edu (8.9.1/8.9.3/SDSCmx-6) with ESMTP id TAA06301 for ; Tue, 15 Feb 2000 19:55:34 -0800 (PST) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu (Unverified) References: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> Message-ID: Date: Tue, 15 Feb 2000 10:34:23 -0800 Reply-To: Reagan Moore Sender: CDL Technical Architecture and Standards Workgroup List From: Reagan Moore Subject: Re: PID - What's the Problem and the Scope To: CDL-TAS@LISTSERV.UCOP.EDU In-Reply-To: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Length: 1886 Bernie: I would like to comment on the first question: *What Problem are we trying to solve and for what scope of materials? In addition of persistent IDs for local data sets currently referenced by URLs, there is also the issue of persistent IDs for the archival copy of the data sets. I expect that CDL will have to specify disaster recovery requirements for all data sets advertised within the CDL referenced collections. Possible requirements are: - data sets must be replicated at an independent site (to avoid loss of data in fires, earthquakes, ...) - if the primary site is not available, the access system should automatically redirect to the backup site. Note that this type of redirection is not permanent, but changes dynamically based upon network outages. - the name of the data set should be the same at each site. This implies the data sets are true replicas. - each site is free to define their most cost effect storage mechanism for their data sets. This implies that multiple legacy systems will be used across the campuses, and the access system must work with any of the UC storage systems. - replication of data sets between the archive and the digital library disk cache will have to be supported. Note that archives do not handle high transaction rates, and require caching of highly referenced data on a data server. Thus the same named data set may be on the digital library disk as well as in the archive. We have been pursuing this type of support for both ADL and the UCB digital library by using the SRB to integrate the systems with HPSS storage at SDSC. Should the CDL aggressively pursue a solution that manages persistent IDs for local data sets as well as archival backup copies of data sets? Alternatively, a proposed solution should be able to evolve into a system that also handles persistent IDs for data stored in archives. Reagan From howard@info.sims.berkeley.edu Wed Feb 16 06:51:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id GAA02463 for ; Wed, 16 Feb 2000 06:51:02 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id GAA32432; Wed, 16 Feb 2000 06:51:00 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 380070 for CDL-TAS@LISTSERV.UCOP.EDU; Wed, 16 Feb 2000 06:50:59 -0800 Received: from westnet.com (westnet.com [206.24.6.2]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id GAA50436 for ; Wed, 16 Feb 2000 06:50:58 -0800 Received: from BISON (p4.pm3-5.westnet.com [206.28.203.96]) by westnet.com (8.9.1/8.9.3) with SMTP id JAA06422; Wed, 16 Feb 2000 09:50:44 -0500 (EST) X-Sender: jmcdonou@library.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 References: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> Mime-Version: 1.0 Message-ID: <200002161450.JAA06422@westnet.com> Date: Wed, 16 Feb 2000 09:28:00 -0500 Reply-To: Jerome McDonough Sender: CDL Technical Architecture and Standards Workgroup List From: Jerome McDonough Subject: Re: PID - What's the Problem and the Scope Comments: To: Reagan Moore To: CDL-TAS@LISTSERV.UCOP.EDU In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Length: 1493 At 10:34 AM 02/15/2000 -0800, Reagan Moore wrote: > >Should the CDL aggressively pursue a solution that manages persistent >IDs for local data sets as well as archival backup copies of data >sets? > >Alternatively, a proposed solution should be able to evolve into a >system that also handles persistent IDs for data stored in archives. > I'd like to add my voice to Reagan's on this issue. I know that we are not trying to solve the archiving problem writ large here, but archiving our material is going to require a persistent identifier solution, and we *really* need to start dealing with archiving digital material soon. By the end of this year, digitization projects at the Bancroft Library alone will have produced nearly 2 terabytes of material requiring long-term archiving and preservation. I'm assuming the other U.C. campuses face similar situations. I don't think the requirements for PIDs for archival use differ that significantly from what's already under discussion, but I suspect that we will need to start using any persistent ID solution adopted almost immediately for digital archiving. It's something to keep in mind in these discussions. Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......) Library Systems Office, 386 Doe, U.C. Berkeley | \ * * / Berkeley, CA 94720-6000 (510) 642-5168 | \ <> / "Well, it looks easy enough...." | \ -- / SGNORMPF!!! -- From the Famous Last Words file | |||| From howard@info.sims.berkeley.edu Wed Feb 16 08:37:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id IAA07268 for ; Wed, 16 Feb 2000 08:37:27 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id IAA16486; Wed, 16 Feb 2000 08:37:24 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 380741 for CDL-TAS@LISTSERV.UCOP.EDU; Wed, 16 Feb 2000 08:37:23 -0800 Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id IAA22798 for ; Wed, 16 Feb 2000 08:37:06 -0800 Received: from [192.168.0.16] ([207.212.67.31]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FQ1002EA78A1Q@mta1.snfc21.pbi.net> for CDL-TAS@LISTSERV.UCOP.EDU; Wed, 16 Feb 2000 08:31:23 -0800 (PST) X-Sender: kweiss@popserv.ucop.edu MIME-version: 1.0 References: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> <200002161450.JAA06422@westnet.com> Message-ID: Date: Wed, 16 Feb 2000 08:21:27 -0800 Reply-To: Ken Weiss Sender: CDL Technical Architecture and Standards Workgroup List From: Ken Weiss Subject: CDL-TAS: a new issue? Comments: To: Jerome McDonough To: CDL-TAS@LISTSERV.UCOP.EDU In-Reply-To: <200002161450.JAA06422@westnet.com> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Length: 1240 Reagan's recent discussion of the persistent identifier in the context of data management systems happened to coincide with another one of my projects to make me wonder if we've neglected a fairly major service/component in our overall architecture. Mirroring. We skirted around this in talking about the need for persistent IDs to be able to handle multiple locations for the same resource, but we never talked about the architectural pieces that need to be in place to facilitate the management of mirrors of networked services. Am I overstating this? Or is the question of mirroring on the same level as authentication and metadata standards? --Ken ------------------------------------------------------------------------- Ken Weiss ken.weiss@ucop.edu California Digital Library Technologies (510) 710-3356 (voice) UC Office of the President (510) 763-2471 (fax) 1111 Franklin Street #7313B ken.weiss.pager@ucop.edu (text page) Oakland, CA 94607-5200 http://dcas.ucdavis.edu/kenhome.html PGP public key stored at: ldap://certserver.pgp.com http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=ken+weiss From howard@info.sims.berkeley.edu Wed Feb 16 10:07:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id KAA11123 for ; Wed, 16 Feb 2000 10:07:02 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id KAA28834; Wed, 16 Feb 2000 10:06:59 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 381592 for CDL-TAS@LISTSERV.UCOP.EDU; Wed, 16 Feb 2000 10:06:56 -0800 Received: from billthecat.sdsc.edu (billthecat.sdsc.edu [132.249.20.60]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id KAA26354 for ; Wed, 16 Feb 2000 10:06:54 -0800 Received: from [198.202.73.213] (d10.remote.sdsc.edu [198.202.73.210]) by billthecat.sdsc.edu (8.9.1/8.9.3/SDSCmx-6) with ESMTP id KAA28504 for ; Wed, 16 Feb 2000 10:06:52 -0800 (PST) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu References: <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> <3.0.5.32.20000210075258.00b4b7c0@library.berkeley.edu> <200002161450.JAA06422@westnet.com> Message-ID: Date: Wed, 16 Feb 2000 10:03:22 -0800 Reply-To: Reagan Moore Sender: CDL Technical Architecture and Standards Workgroup List From: Reagan Moore Subject: Re: CDL-TAS: a new issue? To: CDL-TAS@LISTSERV.UCOP.EDU In-Reply-To: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Length: 2262 Ken: Support for mirroring is another example of a need for a data handling system. There are now four architecture requirements on the table that all need support for naming of remote data or movement of data between distributed collections: - persistent IDs - mirroring of data between sites and coordination of data set replicas - access to archival storage systems - support for persistent archives The coupling between these requirements is rather strong. The same persistent ID should be used for data on the local digital library disk, at mirror sites, and in the archives. Given that the SRB data handling system provides all of these capabilities, it may be easier to work directly with the SRB than build separate infrastructure solutions. Conversely, it may be beneficial to show how the SRB can meet each of these infrastructure requirements. The CDL needs data handling systems for data set management at the same level of urgency as databases for metadata management. Reagan >Reagan's recent discussion of the persistent identifier in the >context of data management systems happened to coincide with another >one of my projects to make me wonder if we've neglected a fairly >major service/component in our overall architecture. > >Mirroring. We skirted around this in talking about the need for >persistent IDs to be able to handle multiple locations for the same >resource, but we never talked about the architectural pieces that >need to be in place to facilitate the management of mirrors of >networked services. > >Am I overstating this? Or is the question of mirroring on the same >level as authentication and metadata standards? > >--Ken > >------------------------------------------------------------------------- >Ken Weiss ken.weiss@ucop.edu >California Digital Library Technologies (510) 710-3356 (voice) >UC Office of the President (510) 763-2471 (fax) >1111 Franklin Street #7313B ken.weiss.pager@ucop.edu (text page) >Oakland, CA 94607-5200 http://dcas.ucdavis.edu/kenhome.html > >PGP public key stored at: > ldap://certserver.pgp.com > http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=ken+weiss From howard@info.sims.berkeley.edu Sun Feb 20 14:38:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id OAA27178 for ; Sun, 20 Feb 2000 14:38:00 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA28550; Sun, 20 Feb 2000 14:37:57 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 359405 for CDL-TAS@LISTSERV.UCOP.EDU; Sun, 20 Feb 2000 14:37:56 -0800 Received: from sun1.lib.uci.edu (sun1.lib.uci.edu [128.200.103.2]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA22178 for ; Sun, 20 Feb 2000 14:37:55 -0800 Received: from sun2.lib.uci.edu (dbisom@sun2.lib.uci.edu [128.200.103.3]) by sun1.lib.uci.edu (8.9.3/) with ESMTP id OAA08408 for ; Sun, 20 Feb 2000 14:37:55 -0800 (PST) Received: from localhost (dbisom@localhost) by sun2.lib.uci.edu (8.9.3/) with ESMTP id OAA02493 for ; Sun, 20 Feb 2000 14:37:49 -0800 (PST) MIME-Version: 1.0 Message-ID: Date: Sun, 20 Feb 2000 14:37:49 -0800 Reply-To: Diane Bisom Sender: CDL Technical Architecture and Standards Workgroup List From: Diane Bisom Subject: LOCKSS Info To: CDL-TAS@LISTSERV.UCOP.EDU Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 779 Hello, I'm sure many of you are already aware of Stanford's LOCKSS (Lots of Copies Keeps Stuff Safe). More information is available at their website: http://lockss.stanford.edu/ We may want to include this project in our discussions about archiving at our next meeting. Diane ************************************************************************* Diane Bisom Head, Library Information Systems UCI Libraries Internet: DBISOM@UCI.EDU University of California, Irvine Voice: 949.824.8939 P.O. Box 19556 FAX: 949.824.3385 Irvine, CA 92623-9556 *Note: UCI's Area Code Has Changed To (949) ************************************************************************* From howard@info.sims.berkeley.edu Mon Feb 21 19:25:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id TAA18503 for ; Mon, 21 Feb 2000 19:25:11 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA22524; Mon, 21 Feb 2000 19:25:07 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 367609 for CDL-TAS@LISTSERV.UCOP.EDU; Mon, 21 Feb 2000 19:25:07 -0800 Received: from billthecat.sdsc.edu (billthecat.sdsc.edu [132.249.20.60]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA25994 for ; Mon, 21 Feb 2000 19:25:05 -0800 Received: from [132.249.200.198] (moore-pb.sdsc.edu [132.249.200.198]) by billthecat.sdsc.edu (8.9.1/8.9.3/SDSCmx-6) with ESMTP id TAA25013 for ; Mon, 21 Feb 2000 19:25:04 -0800 (PST) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu References: Message-ID: Date: Mon, 21 Feb 2000 19:27:54 -0800 Reply-To: Reagan Moore Sender: CDL Technical Architecture and Standards Workgroup List From: Reagan Moore Subject: Re: LOCKSS Info To: CDL-TAS@LISTSERV.UCOP.EDU In-Reply-To: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Length: 1640 Diane: - What happens when the Web cache fills up? Will you migrate data into an archive? - How do you provide persistent IDs? Since the data set is replicated across multiple sites, does each site have a different ID for the data set? - How do you manage access to data that is published in collections such as the Protein Data Bank, or the NASA DAACs, or the Human Brain project, or the AMICO art image library? - How do you manage proprietary data? An implication is that a user will need an account at each site where they might have proprietary data stored. - How do you index the collection to determine where to go to find a data set when your favorite web cache is down? One general question is how to integrate your Web cache with a data handling system, so that each of the above concerns can be addressed. Reagan Moore >Hello, > >I'm sure many of you are already aware of Stanford's LOCKSS (Lots of >Copies Keeps Stuff Safe). More information is available at their website: > > http://lockss.stanford.edu/ > >We may want to include this project in our discussions about archiving at >our next meeting. > >Diane > >************************************************************************* >Diane Bisom >Head, Library Information Systems > >UCI Libraries Internet: DBISOM@UCI.EDU >University of California, Irvine Voice: 949.824.8939 >P.O. Box 19556 FAX: 949.824.3385 >Irvine, CA 92623-9556 > > *Note: UCI's Area Code Has Changed To (949) >************************************************************************* From howard@info.sims.berkeley.edu Tue Feb 22 14:56:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id OAA01918 for ; Tue, 22 Feb 2000 14:56:50 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA40160; Tue, 22 Feb 2000 14:56:44 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 374743 for CDL-TAS@LISTSERV.UCOP.EDU; Tue, 22 Feb 2000 14:56:42 -0800 Received: from lhc.nlm.nih.gov (lhc.nlm.nih.gov [130.14.35.128]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA42642 for ; Tue, 22 Feb 2000 14:56:40 -0800 Received: (from jak@localhost) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) id RAA13535; Tue, 22 Feb 2000 17:56:39 -0500 (EST) Message-ID: <200002222256.RAA13535@lhc.nlm.nih.gov> Date: Tue, 22 Feb 2000 17:56:39 -0500 Reply-To: "John A. Kunze" Sender: CDL Technical Architecture and Standards Workgroup List From: "John A. Kunze" Subject: Re: LOCKSS Info Comments: To: dbisom@sun1.lib.uci.edu To: CDL-TAS@LISTSERV.UCOP.EDU Content-Type: text Content-Length: 6135 > From: Diane Bisom , 20 Feb 2000 14:37:49 > > I'm sure many of you are already aware of Stanford's LOCKSS (Lots of > Copies Keeps Stuff Safe). More information is available at their website: > > http://lockss.stanford.edu/ > > We may want to include this project in our discussions about archiving at > our next meeting. You all may be interested in some some less than sanguine comments (enclosed) that I expressed last week in an NLM discussion of LOCKSS. -John -------- From: John Kunze Fri Feb 18 14:51:25 2000 To: < ... various NLM staff ... > The Stanford LOCKSS "persistent access" project looks to me to have significant conceptual problems. It may be that their software could be used for an interesting experiment in distributed repository management, but it's far from clear to me that libraries could use it as part of a solution for archiving web journals. They make an interesting analogy between the hardcopy world where lots of libraries keep a copy of a thing (eg, a journal), and their vision of an online world where lots of libraries keep a copy of a thing. But while redundancy is probably critical for preserving the scholarly record (and some loose cooperation among digital libraries will make that happen for electronic information), there is no way that the LOCKSS software makes it any more likely. There are also many aspects of the problem that they (and I, here) don't address. The LOCKSS brief project description (which I will comment on further) says that publishers lease material to libraries; that libraries, who don't own the material, have "empty" collections. These libraries are not _allowed_ to keep a copy. This is the main problem with LOCKSS. It requires keeping lots of copies in an environment, as described by them, where one is not allowed to keep copies. Mysteriously, all the rights and encumbrances to keep lots of copies have been cleared. Moreover, they will have all been cleared in a uniform way; a LOCKSS software solution that works more or less untended would need a one-size-fits-all negotiated terms and conditions for all libraries (A, B, C, ...) to archive material from publishers (P, Q, R,...). It would be a great thing if all these rights had been cleared in a uniform way. There would be nothing to prevent digital libraries from proceeding with permanence planning in a manner that's a natural digital extension of hardcopy based permanence planning. Clearing rights is the main problem, and LOCKSS offers no help. Subsequent permanence planning would not need to involve any special technology unless the amount of material that each library is willing to safeguard was overwhelming. In fact a reason to avoid LOCKSS is that it manages your precious archives for you. Suppose for the moment that uniform terms and conditions had been negotiated for a 100 web journals. The LOCKSS software agents will go out and detect differences between your journals and others' journals. If it is to work untended (as claimed), it will deposit things in your archive automatically as it sees fit. The risks of software deciding what and when to write on your archives are huge. Because of the possibility for inconsistencies on other repositories to infect your repository, LOCKSS actually recreates some of the characteristics of single point failure that it claims to avoid. Without significant and detailed strategies for meeting security threats, LOCKS looks to me like a tempting and easy target for hackers. One of the only statements to this concern is made without support: "LOCKSS will not supply copies except to caches that have proved in the past that they had a copy". This raises many more questions. Certainly inconsistencies among repositories would be a useful thing to detect and report with the help of software, but few archivists would entrust that software with decisions to "adjust repositories" by writing on them without an archivist's carefully considering the nature and extent of the inconsistencies. It seems that LOCKSS has potential in the area of detecting and reporting. However, automatically repairing a collection is unlikely to be acceptable. I think this contradicts -- if I understand correctly -- what the LOCKSS project description says when it mentions "[t]his models library's individual collection development and circulation systems" and "[t]his models inter-library loan". A terminological problem for LOCKSS is that it establishes an unhelpful metaphor between an "archive" (a long-lived, stable, restricted access collection) and a "cache" (a highly dynamic, ephemeral collection of bits and pieces of digital objects from which old unused stuff is routinely purged). The reason for using the term "cache" for "archive" here derives mainly from the inter-cache protocol (from ICP and Squid). It's not easy for me to agree with the statement that "[t]he peer review process makes the material essentially immutable". Without going into the practical potential for changes, accidental or malicious, that are totally unaffected by peer review, I think that even in theory this statement is more true for some journals than for others. Increasingly we're finding that publishing is an ongoing process; that the online version is often (and not by exception) different from the hardcopy version; that almost always now the online version is considered "the master". I also don't understand the statement "LOCKSS deals with circulation, not with archiving". I would think the reverse is true. LOCKSS says nothing about how a user's web browser will retrieve information from your repository, at least not directly. It does directly, I think, say how the respository will be managed. This is confusing. In conclusion, I don't suspect that LOCKSS solves mainstream library problems. The inter-cache protocol may well have interesting application in assisting repository management of material that is either not high priority or is too voluminous to deal with accept with software (eg, keeping track of electronic discussion group archives). -John From howard@info.sims.berkeley.edu Mon Mar 6 13:34:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id NAA10244 for ; Mon, 6 Mar 2000 13:34:44 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id NAA27974; Mon, 6 Mar 2000 13:34:40 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 368727 for CDL-TAS@LISTSERV.UCOP.EDU; Mon, 6 Mar 2000 13:34:36 -0800 Received: from library.berkeley.edu (library.Berkeley.EDU [169.229.32.48]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id NAA25656 for ; Mon, 6 Mar 2000 13:34:33 -0800 Received: from b_hurley (doenx-245A-2.Lib.Berkeley.EDU [128.32.224.25]) by library.berkeley.edu (8.9.1a/8.9.1) with SMTP id NAA25412 for ; Mon, 6 Mar 2000 13:33:45 -0800 (PST) X-Sender: bernie@library.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Mime-Version: 1.0 Message-ID: <3.0.5.32.20000306133147.0093d820@library.berkeley.edu> Date: Mon, 6 Mar 2000 13:31:47 -0800 Reply-To: Bernie Hurley Sender: CDL Technical Architecture and Standards Workgroup List From: Bernie Hurley Subject: PID Discussion Paper To: CDL-TAS@LISTSERV.UCOP.EDU Content-Type: multipart/mixed; boundary="=====================_952407107==_" Content-Length: 57588 --=====================_952407107==_ Content-Type: text/plain; charset="us-ascii" Hi! I've written a short paper on most of the topics that were on our discussion list for PIDs (attached). I hope this may serve as a starting point for our next discussion. Jerry has already reviewed it and I thank him for his comments. Please note, I wrote the paper with a broader (i.e., not so technical) audience in mind. Thanks, B. ----- A text version for John---------- PERSISTENT IDENTIFIERS (PIDs) 3/6/00 What's the Problem? Within our library systems we need to be able to refer to networked resources over which we have little or no direct control. Currently, this reference is most often implemented as a URL. A mechanism is required that separates the management of an object on a server from the reference used to retrieve that object. This becomes a business process issue - where one organization is maintaining a resource (e.g., a publisher, an aggregator, etc.) and a different and wholly unrelated organization is referring to it (e.g, the UC Libraries) This business process problem is important to libraries, as it manifests itself as "broken URLs." There is an ever increasing number of URLs in our library systems (Melvyl, A&I databases, CDL directory, OAC, local catalogs, etc.) that break every time files are moved from one URL path to another. So, the solution would be to find a cost-effective way for UC libraries to manage the references to the objects, even though another organization manages the objects on their remote servers. It's worth mentioning that an optimal system would put managing the links in the hands of those who manage the resources. This solution, however, would require a global resolution system used by all publishers, aggregators, libraries, etc., which will not be a reality for some time to come. The Proposed Solution One way to manage the references would be to create a "more" Persistent ID (PID) that can be used in our systems in place of URLs. When the PID is selected in a Web browser, it would be translated to the current URL through a mapping system. The mapping system would translate the PID into the current URL, which would then be called by issuing an HTTP redirect . In this solution, the references to objects (i.e., the PIDs) are now managed by the UC libraries via the mapping system. By "more persistent," we mean that we're not trying to solve the long-term archival problem, but rather implement something that can migrate to that solution once the URN community comes to some agreement on a standard solution. We expect we will create a solution using URL redirection for the coming year, with the opportunity to migrate to a true data handling system within three years. By cost-effective we mean that the labor and technology cost of running the system is less than just fixing the URLs, as they break. See the section on Library Implementation Issues. Scope In our first implementation, we would focus on creating PIDs for our library systems. We understand other groups also need to address this problem (e.g., faculty needs for PIDs with regards to their publications and the greater needs within UC, as a whole). However, broadening the scope beyond libraries would take us into a new "political" arena and greatly complicate any discussion and implementation Within the scope of library systems, we have two communities that have the power to "break" URLs. Us and them. "Us" is for the digital materials that UC creates and manages on UC servers. For example, the OAC images are still on the Berkeley SUNsite. Therefore all the URLs in our EADs will break, once we move these images to the CDL - their new home. The "Them" is for the URLs we load into our systems from vendors (e.g., publishers and aggregators). If a vendor changes the locations for their files (i.e., their URLs), would we best solve this problem by replacing them, in a batch run, within our systems? Or, would it be better handled within a mapping table? Using a mapping table has the added advantage that PIDs copied out of our systems into class instructional sites would still work. Library Implementation Issues [Note: I discussed the following with our technical services and Bancroft technical service departments. Once we agree on this section, we should probably send it to HOTS to be vetted. - Bernie] Library technical services departments will need to request PIDs from the mapping system to be included in metadata they produce. For example, a cataloger will often need to add a PID to a MARC record they are creating in OCLC, or to add a PID to an EAD finding aid. In addition to requesting single PIDs, there will also be cases where we libraries will want to replace all URLs in existing metadata with PIDs. Replacing all the URLs with PIDs in existing EADs, or URLs with PIDs in our bibliographic catalogs are examples. The above scenarios argue for the mapping system to provide an administrative service in which a URL is presented to it and a PID is returned. There will need to be a web interface to this service, so a cataloger can present a single URL and have a PID returned. There also is the requirement that a computer program, executing remotely, be able to pass the mapping system a URL and receive a PID back. These programs will be developed to either integrate PID assignment within library catalog maintenance systems, or provide URL to PID to conversions in existing metadata (e.g., MARC records, EADs, etc., CDL standard objects. etc.). In addition to creating PID, UC libraries will be responsible for maintaining and deleting these from the mapping system. See the section, Administrative Service for a Mapping System for a further discussion of this topic. Name Spaces It is possible to consider running an object reference system that supported multiple name spaces. For example, an object reference systems could be set up to resolve identifiers in the ISBN, ISSN, SICI or LCCN name spaces. If a user sends an identifier within a particular name space (e.g., ISSN) to the mapping system's resolver, it would return the location of that object (e.g., a URL). Given the short-term nature of our solution, we have recommended only supporting the PID name space. That is, if we pass a PID to the resolver, we are returned the location of the object (i.e., the URL) that is then redirected by the browser to retrieve that resource. We do not have to directly support these other name spaces, as our catalogs already index these identifiers. Therefore, a user can search our catalog to find the bibliographic record for an existing identifier (e.g., ISSN) and then click on the PID, which is the supported name space. Naming Authorities It is technically possible to create a decentralized system for providing PIDs for resources. For example, each campus library could run their own mapping system and assign their own PIDs. It is our recommendation, however, that the CDL run a centralized mapping system for the UC library system under a naming authority called UCLibs. This approach would minimize the costs of implementation, by eliminating the duplication of effort. In addition, it would ensure that two different authorities did not assign the same PID. This would become a problem if we ever want to merge two or more naming authorities into one. Migrating PIDs to URNs The UC Libraries should pay careful attention to the ways in which PIDs are assigned to particular resources, and take steps to ensure that assigned PIDs may eventually be algorithmically transformed into URNs. Technically this is not a particularly difficult problem, but it does require that decisions be made in advance of assignment of any PIDs regarding the name spaces that will be employed in identifying resources managed by the University, and how authority to assign new PIDs will be delegated. In our case, the problem is somewhat simplified by the fact we are recommending one name space (PIDs) and one naming authority (UCLibs). However, we still need to consider the syntax of the PID. A URN takes the form of urn:: where is a name space identifier, and is a name space specific string (what we would think of as the actual identifier for a resource). So, for example, urn:isbn:039397281X is a urn where the namespace is the international standard book number, and the actual ISBN assigned to the work is 039397281X. Our PIDs, by contrast, would take the form http:/// where is the fully-qualified domain name for a UCLibs naming authority server, and constitutes an identifier for a resource registered at that server (e.g., the PID). Therefore, we would want to create PIDs such as: http://UCLibs.cdllib.org/pid/039397281X that can be transformed algorithmically into their URN formats: urn:pid:039397281X Administrative Service for a Mapping System The mapping system will require several features needed to ease its administration and use. The first of these is delegation of name creation and maintenance by those who administer the mapping system. Users at all of the campuses and at the CDL will need to be able to add, modify and delete information for particular PIDs as necessary. The mapping system will therefore require some means of allowing users authorized by UCLibs to make needed changes to information recorded in the system. It will also need to ensure that only authorized users can make changes, and that those users can only alter or delete information that is within their authority to modify (e.g., users at U.C. Berkeley should not be able to modify PID entries created by CDL users, and vice versa). The mapping system will therefore need to support some type of user authentication mechanism. Users will need a mechanism to add new entries into the mapping system matching PIDs with their respective URLs. They will also need some means to modify the URL associated with a PID when a resource is relocated, and a way to delete entries (or at least mark them as inactive) when resources become permanently unavailable. The system will also need to allow users some means to batch all of these interactions. Batch facilities might be needed, for example to simplify the job of modifying all of the URLs for a set of resources that are relocated from one HTTP server to another. The mapping system should include logging facilities, both to record transactions which modify the system's database, and to record activity by the resolver portion of the system in order to monitor its performance. Users may need to examine all of the PID/URL entries they have created, or some subset of them, to ensure their correctness or to prepare a batch job for submission to the system (as in the case of modifying all the URLs for resources moved from one server to another). The system will therefore need some form of reporting facility. Users should be able to prepare reports showing all PID/URL entries that they are authorized to modify, or only those which meet a user-selected set of criteria. Reporting facilities should also include reports on the system's performance based on its transaction logs. Finally, given the vital role played by the mapping system in provide services to the U.C. Libraries' users, facilities for backing up the information within the mapping system and ensuring its survival in the case of disaster is essential. While the technical means to accomplish this may not constitute part of the mapping system per se, this need is of sufficient importance to merit considering it as an essential component of the overall system. ------------------------------------------------- FUTURE DISCUSSION 1) How do we handle dynamically created URLs? 2) Revisit the technical solution (URL redirection) to see if it still works, after these other discussions. 3) Persistent IDs for the archival copy of the data sets. --=====================_952407107==_ Content-Type: application/msword; name="PID_V4.doc"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Disposition: attachment; filename="PID_V4.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPAAAAAAAAAAA EAAAPgAAAAEAAAD+////AAAAADsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWQAJBAAAABK/AAAAAAAAEAAAAAAABAAA1DIAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIUQAAJE9AQCRPQEASy0AAGwBAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAI4DAAAAAAAAjgMAAI4D AAAKAAAAmAMAAAwAAACkAwAAAAAAAKQDAAAAAAAApAMAABQAAAAAAAAAAAAAALgDAAAAAAAAuAMA AAAAAAC4AwAAAAAAALgDAAA4AAAA8AMAAAwAAAD8AwAAJAAAALgDAAAAAAAAmwoAABwBAABeBAAA AAAAAF4EAAAoAAAAhgQAAAAAAACGBAAAAAAAAIYEAAAAAAAAhgQAAAAAAACGBAAAAAAAAIYEAAAA AAAAYAoAAAIAAABiCgAAAAAAAGIKAAAAAAAAYgoAAAAAAABiCgAAAAAAAGIKAAAAAAAAYgoAACQA AAC3CwAA9AEAAKsNAACCAAAAhgoAABUAAAAAAAAAAAAAAAAAAAAAAAAApAMAAAAAAACGBAAAAAAA AAAAAAAAAAAAAAAAAAAAAACGBAAAAAAAAIYEAAAAAAAAhgQAAAAAAACGBAAAAAAAAIYKAAAAAAAA 7gQAAAAAAACkAwAAAAAAAKQDAAAAAAAAhgQAAAAAAAAAAAAAAAAAAIYEAAAAAAAALAQAADIAAADu BAAAAAAAAO4EAAAAAAAA7gQAAAAAAACGBAAAKAAAAKQDAAAAAAAAhgQAAAAAAACkAwAAAAAAAIYE AAAAAAAAYAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuAMAAAAAAAC4AwAAAAAAAKQDAAAAAAAApAMA AAAAAACkAwAAAAAAAKQDAAAAAAAAhgQAAAAAAABgCgAAAAAAAO4EAAB+BAAA7gQAAAAAAABsCQAA OgAAABYKAABAAAAApAMAAAAAAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAoAAAAAAACGBAAAAAAAACAEAAAMAAAAAMLStbKH vwG4AwAAAAAAALgDAAAAAAAArgQAAEAAAABWCgAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEVS U0lTVEVOVCBJREVOVElGSUVSUyAoUElEcykNMy82LzAwDQ1XaGF0J3MgdGhlIFByb2JsZW0/DVdp dGhpbiBvdXIgbGlicmFyeSBzeXN0ZW1zIHdlIG5lZWQgdG8gYmUgYWJsZSB0byByZWZlciB0byBu ZXR3b3JrZWQgcmVzb3VyY2VzIG92ZXIgd2hpY2ggd2UgaGF2ZSBsaXR0bGUgb3Igbm8gZGlyZWN0 IGNvbnRyb2wuIEN1cnJlbnRseSwgdGhpcyByZWZlcmVuY2UgaXMgbW9zdCBvZnRlbiBpbXBsZW1l bnRlZCBhcyBhIFVSTC4gIEEgbWVjaGFuaXNtIGlzIHJlcXVpcmVkIHRoYXQgc2VwYXJhdGVzIHRo ZSBtYW5hZ2VtZW50IG9mIGFuIG9iamVjdCBvbiBhIHNlcnZlciBmcm9tIHRoZSByZWZlcmVuY2Ug dXNlZCB0byByZXRyaWV2ZSB0aGF0IG9iamVjdC4gIFRoaXMgYmVjb21lcyBhIGJ1c2luZXNzIHBy b2Nlc3MgaXNzdWUgLSB3aGVyZSBvbmUgb3JnYW5pemF0aW9uIGlzIG1haW50YWluaW5nIGEgcmVz b3VyY2UgKGUuZy4sIGEgcHVibGlzaGVyLCBhbiBhZ2dyZWdhdG9yLCBldGMuKSBhbmQgYSBkaWZm ZXJlbnQgYW5kIHdob2xseSB1bnJlbGF0ZWQgb3JnYW5pemF0aW9uIGlzIHJlZmVycmluZyB0byBp dCAoZS5nLCB0aGUgVUMgTGlicmFyaWVzKQ0NVGhpcyBidXNpbmVzcyBwcm9jZXNzIHByb2JsZW0g aXMgaW1wb3J0YW50IHRvIGxpYnJhcmllcywgYXMgaXQgbWFuaWZlc3RzIGl0c2VsZiBhcyAiYnJv a2VuIFVSTHMuIiAgVGhlcmUgaXMgYW4gZXZlciBpbmNyZWFzaW5nIG51bWJlciBvZiBVUkxzIGlu IG91ciBsaWJyYXJ5IHN5c3RlbXMgKE1lbHZ5bCwgQSZJIGRhdGFiYXNlcywgQ0RMIGRpcmVjdG9y eSwgT0FDLCBsb2NhbCBjYXRhbG9ncywgZXRjLikgdGhhdCBicmVhayBldmVyeSB0aW1lIGZpbGVz IGFyZSBtb3ZlZCBmcm9tIG9uZSBVUkwgcGF0aCB0byBhbm90aGVyLiAgU28sIHRoZSBzb2x1dGlv biB3b3VsZCBiZSB0byBmaW5kIGEgY29zdC1lZmZlY3RpdmUgd2F5IGZvciBVQyBsaWJyYXJpZXMg dG8gbWFuYWdlIHRoZSByZWZlcmVuY2VzIHRvIHRoZSBvYmplY3RzLCBldmVuIHRob3VnaCBhbm90 aGVyIG9yZ2FuaXphdGlvbiBtYW5hZ2VzIHRoZSBvYmplY3RzIG9uIHRoZWlyIHJlbW90ZSBzZXJ2 ZXJzLiAgDQ1JdCdzIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBhbiBvcHRpbWFsIHN5c3RlbSB3b3Vs ZCBwdXQgbWFuYWdpbmcgdGhlIGxpbmtzIGluIHRoZSBoYW5kcyBvZiB0aG9zZSB3aG8gbWFuYWdl IHRoZSByZXNvdXJjZXMuICBUaGlzIHNvbHV0aW9uLCBob3dldmVyLCB3b3VsZCByZXF1aXJlIGEg Z2xvYmFsIHJlc29sdXRpb24gc3lzdGVtIHVzZWQgYnkgYWxsIHB1Ymxpc2hlcnMsIGFnZ3JlZ2F0 b3JzLCBsaWJyYXJpZXMsIGV0Yy4sIHdoaWNoIHdpbGwgbm90IGJlIGEgcmVhbGl0eSBmb3Igc29t ZSB0aW1lIHRvIGNvbWUuICANDVRoZSBQcm9wb3NlZCBTb2x1dGlvbg1PbmUgd2F5IHRvIG1hbmFn ZSB0aGUgcmVmZXJlbmNlcyB3b3VsZCBiZSB0byBjcmVhdGUgYSAibW9yZSIgUGVyc2lzdGVudCBJ RCAoUElEKSB0aGF0IGNhbiBiZSB1c2VkIGluIG91ciBzeXN0ZW1zIGluIHBsYWNlIG9mIFVSTHMu ICBXaGVuIHRoZSBQSUQgaXMgc2VsZWN0ZWQgaW4gYSBXZWIgYnJvd3NlciwgaXQgd291bGQgYmUg dHJhbnNsYXRlZCB0byB0aGUgY3VycmVudCBVUkwgdGhyb3VnaCBhIG1hcHBpbmcgc3lzdGVtLiAg VGhlIG1hcHBpbmcgc3lzdGVtIHdvdWxkIHRyYW5zbGF0ZSB0aGUgUElEIGludG8gdGhlIGN1cnJl bnQgVVJMLCB3aGljaCB3b3VsZCB0aGVuIGJlIGNhbGxlZCBieSBpc3N1aW5nIGFuIEhUVFAgcmVk aXJlY3QCLiAgSW4gdGhpcyBzb2x1dGlvbiwgdGhlIHJlZmVyZW5jZXMgdG8gb2JqZWN0cyAoaS5l LiwgdGhlIFBJRHMpIGFyZSBub3cgbWFuYWdlZCBieSB0aGUgVUMgbGlicmFyaWVzIHZpYSB0aGUg bWFwcGluZyBzeXN0ZW0uICANDUJ5ICJtb3JlIHBlcnNpc3RlbnQsIiB3ZSBtZWFuIHRoYXQgd2Un cmUgbm90IHRyeWluZyB0byBzb2x2ZSB0aGUgbG9uZy10ZXJtIGFyY2hpdmFsIHByb2JsZW0sIGJ1 dCByYXRoZXIgaW1wbGVtZW50IHNvbWV0aGluZyB0aGF0IGNhbiBtaWdyYXRlIHRvIHRoYXQgc29s dXRpb24gb25jZSB0aGUgVVJOIGNvbW11bml0eSBjb21lcyB0byBzb21lIGFncmVlbWVudCBvbiBh IHN0YW5kYXJkIHNvbHV0aW9uLiBXZSBleHBlY3Qgd2Ugd2lsbCBjcmVhdGUgYSBzb2x1dGlvbiB1 c2luZyBVUkwgcmVkaXJlY3Rpb24gZm9yIHRoZSBjb21pbmcgeWVhciwgd2l0aCB0aGUgb3Bwb3J0 dW5pdHkgdG8gbWlncmF0ZSB0byBhIHRydWUgZGF0YSBoYW5kbGluZyBzeXN0ZW0gd2l0aGluIHRo cmVlIHllYXJzLiAgDQ1CeSBjb3N0LWVmZmVjdGl2ZSB3ZSBtZWFuIHRoYXQgdGhlIGxhYm9yIGFu ZCB0ZWNobm9sb2d5IGNvc3Qgb2YgcnVubmluZyB0aGUgc3lzdGVtIGlzIGxlc3MgdGhhbiBqdXN0 IGZpeGluZyB0aGUgVVJMcywgYXMgdGhleSBicmVhay4gIFNlZSB0aGUgc2VjdGlvbiBvbiBMaWJy YXJ5IEltcGxlbWVudGF0aW9uIElzc3Vlcy4NDQ1TY29wZQ0gICAgICBJbiBvdXIgZmlyc3QgaW1w bGVtZW50YXRpb24sIHdlIHdvdWxkIGZvY3VzIG9uIGNyZWF0aW5nIFBJRHMgZm9yIG91ciBsaWJy YXJ5IHN5c3RlbXMuICBXZSB1bmRlcnN0YW5kIG90aGVyIGdyb3VwcyBhbHNvIG5lZWQgdG8gYWRk cmVzcyB0aGlzIHByb2JsZW0gKGUuZy4sIGZhY3VsdHkgbmVlZHMgZm9yIFBJRHMgd2l0aCByZWdh cmRzIHRvIHRoZWlyIHB1YmxpY2F0aW9ucyBhbmQgdGhlIGdyZWF0ZXIgbmVlZHMgd2l0aGluIFVD LCBhcyBhIHdob2xlKS4gIEhvd2V2ZXIsIGJyb2FkZW5pbmcgdGhlIHNjb3BlIGJleW9uZCBsaWJy YXJpZXMgd291bGQgdGFrZSB1cyBpbnRvIGEgbmV3ICJwb2xpdGljYWwiIGFyZW5hIGFuZCBncmVh dGx5IGNvbXBsaWNhdGUgYW55IGRpc2N1c3Npb24gYW5kIGltcGxlbWVudGF0aW9uDQ0gICAgICBX aXRoaW4gdGhlIHNjb3BlIG9mIGxpYnJhcnkgc3lzdGVtcywgd2UgaGF2ZSB0d28gY29tbXVuaXRp ZXMgdGhhdCBoYXZlIHRoZSBwb3dlciB0byAiYnJlYWsiIFVSTHMuICBVcyBhbmQgdGhlbS4gICJV cyIgaXMgZm9yIHRoZSBkaWdpdGFsIG1hdGVyaWFscyB0aGF0IFVDIGNyZWF0ZXMgYW5kIG1hbmFn ZXMgb24gVUMgc2VydmVycy4gRm9yIGV4YW1wbGUsIHRoZSBPQUMgaW1hZ2VzIGFyZSBzdGlsbCBv biB0aGUgQmVya2VsZXkgU1VOc2l0ZS4gIFRoZXJlZm9yZSBhbGwgdGhlIFVSTHMgaW4gb3VyIEVB RHMgd2lsbCBicmVhaywgb25jZSB3ZSBtb3ZlIHRoZXNlIGltYWdlcyB0byB0aGUgQ0RMIC0gdGhl aXIgbmV3IGhvbWUuDQ0gICAgICAgVGhlICJUaGVtIiBpcyBmb3IgdGhlIFVSTHMgd2UgbG9hZCBp bnRvIG91ciBzeXN0ZW1zIGZyb20gdmVuZG9ycyAoZS5nLiwgcHVibGlzaGVycyBhbmQgYWdncmVn YXRvcnMpLiAgSWYgYSB2ZW5kb3IgY2hhbmdlcyB0aGUgbG9jYXRpb25zIGZvciB0aGVpciBmaWxl cyAoaS5lLiwgdGhlaXIgVVJMcyksIHdvdWxkIHdlIGJlc3Qgc29sdmUgdGhpcyBwcm9ibGVtIGJ5 IHJlcGxhY2luZyB0aGVtLCBpbiBhIGJhdGNoIHJ1biwgd2l0aGluIG91ciBzeXN0ZW1zPyAgT3Is IHdvdWxkIGl0IGJlIGJldHRlciBoYW5kbGVkIHdpdGhpbiBhIG1hcHBpbmcgdGFibGU/ICBVc2lu ZyBhIG1hcHBpbmcgdGFibGUgaGFzIHRoZSBhZGRlZCBhZHZhbnRhZ2UgdGhhdCBQSURzIGNvcGll ZCBvdXQgb2Ygb3VyIHN5c3RlbXMgaW50byBjbGFzcyBpbnN0cnVjdGlvbmFsIHNpdGVzIHdvdWxk IHN0aWxsIHdvcmsuICANDUxpYnJhcnkgSW1wbGVtZW50YXRpb24gSXNzdWVzDQlbTm90ZTogSSBk aXNjdXNzZWQgdGhlIGZvbGxvd2luZyB3aXRoIG91ciB0ZWNobmljYWwgc2VydmljZXMgYW5kIEJh bmNyb2Z0IHRlY2huaWNhbCBzZXJ2aWNlIGRlcGFydG1lbnRzLiBPbmNlIHdlIGFncmVlIG9uIHRo aXMgc2VjdGlvbiwgd2Ugc2hvdWxkIHByb2JhYmx5IHNlbmQgaXQgdG8gSE9UUyB0byBiZSB2ZXR0 ZWQuIC0gQmVybmllXQ0NCUxpYnJhcnkgdGVjaG5pY2FsIHNlcnZpY2VzIGRlcGFydG1lbnRzIHdp bGwgbmVlZCB0byByZXF1ZXN0IFBJRHMgZnJvbSB0aGUgbWFwcGluZyBzeXN0ZW0gdG8gYmUgaW5j bHVkZWQgaW4gbWV0YWRhdGEgdGhleSBwcm9kdWNlLiAgRm9yIGV4YW1wbGUsIGEgY2F0YWxvZ2Vy IHdpbGwgb2Z0ZW4gbmVlZCB0byBhZGQgYSBQSUQgdG8gYSBNQVJDIHJlY29yZCB0aGV5IGFyZSBj cmVhdGluZyBpbiBPQ0xDLCBvciB0byBhZGQgYSBQSUQgdG8gYW4gRUFEIGZpbmRpbmcgYWlkLiAg SW4gYWRkaXRpb24gdG8gcmVxdWVzdGluZyBzaW5nbGUgUElEcywgdGhlcmUgd2lsbCBhbHNvIGJl IGNhc2VzIHdoZXJlIHdlIGxpYnJhcmllcyB3aWxsIHdhbnQgdG8gcmVwbGFjZSBhbGwgVVJMcyBp biBleGlzdGluZyBtZXRhZGF0YSB3aXRoIFBJRHMuICBSZXBsYWNpbmcgYWxsIHRoZSBVUkxzIHdp dGggUElEcyBpbiBleGlzdGluZyBFQURzLCBvciBVUkxzIHdpdGggUElEcyBpbiBvdXIgYmlibGlv Z3JhcGhpYyBjYXRhbG9ncyBhcmUgZXhhbXBsZXMuDQ0JVGhlIGFib3ZlIHNjZW5hcmlvcyBhcmd1 ZSBmb3IgdGhlIG1hcHBpbmcgc3lzdGVtIHRvIHByb3ZpZGUgYW4gYWRtaW5pc3RyYXRpdmUgc2Vy dmljZSBpbiB3aGljaCBhIFVSTCBpcyBwcmVzZW50ZWQgdG8gaXQgYW5kIGEgUElEIGlzIHJldHVy bmVkLiAgVGhlcmUgd2lsbCBuZWVkIHRvIGJlIGEgd2ViIGludGVyZmFjZSB0byB0aGlzIHNlcnZp Y2UsIHNvIGEgY2F0YWxvZ2VyIGNhbiBwcmVzZW50IGEgc2luZ2xlIFVSTCBhbmQgaGF2ZSBhIFBJ RCByZXR1cm5lZC4gIFRoZXJlIGFsc28gaXMgdGhlIHJlcXVpcmVtZW50IHRoYXQgYSBjb21wdXRl ciBwcm9ncmFtLCBleGVjdXRpbmcgcmVtb3RlbHksIGJlIGFibGUgdG8gcGFzcyB0aGUgbWFwcGlu ZyBzeXN0ZW0gYSBVUkwgYW5kIHJlY2VpdmUgYSBQSUQgYmFjay4gIFRoZXNlIHByb2dyYW1zIHdp bGwgYmUgZGV2ZWxvcGVkIHRvIGVpdGhlciBpbnRlZ3JhdGUgUElEIGFzc2lnbm1lbnQgd2l0aGlu IGxpYnJhcnkgY2F0YWxvZyBtYWludGVuYW5jZSBzeXN0ZW1zLCBvciBwcm92aWRlIFVSTCB0byBQ SUQgdG8gY29udmVyc2lvbnMgaW4gZXhpc3RpbmcgbWV0YWRhdGEgKGUuZy4sIE1BUkMgcmVjb3Jk cywgRUFEcywgZXRjLiwgQ0RMIHN0YW5kYXJkIG9iamVjdHMuIGV0Yy4pLg0NCUluIGFkZGl0aW9u IHRvIGNyZWF0aW5nIFBJRCwgVUMgbGlicmFyaWVzIHdpbGwgYmUgcmVzcG9uc2libGUgZm9yIG1h aW50YWluaW5nIGFuZCBkZWxldGluZyB0aGVzZSBmcm9tIHRoZSBtYXBwaW5nIHN5c3RlbS4gIFNl ZSB0aGUgc2VjdGlvbiwgQWRtaW5pc3RyYXRpdmUgU2VydmljZSBmb3IgYSBNYXBwaW5nIFN5c3Rl bSBmb3IgYSBmdXJ0aGVyIGRpc2N1c3Npb24gb2YgdGhpcyB0b3BpYy4NDU5hbWUgU3BhY2VzDQlJ dCBpcyBwb3NzaWJsZSB0byBjb25zaWRlciBydW5uaW5nIGFuIG9iamVjdCByZWZlcmVuY2Ugc3lz dGVtIHRoYXQgc3VwcG9ydGVkIG11bHRpcGxlIG5hbWUgc3BhY2VzLiAgRm9yIGV4YW1wbGUsIGFu IG9iamVjdCByZWZlcmVuY2Ugc3lzdGVtcyBjb3VsZCBiZSBzZXQgdXAgdG8gcmVzb2x2ZSBpZGVu dGlmaWVycyBpbiB0aGUgSVNCTiwgSVNTTiwgU0lDSSBvciBMQ0NOIG5hbWUgc3BhY2VzLiAgSWYg YSB1c2VyIHNlbmRzIGFuIGlkZW50aWZpZXIgd2l0aGluIGEgcGFydGljdWxhciBuYW1lIHNwYWNl IChlLmcuLCBJU1NOKSB0byB0aGUgbWFwcGluZyBzeXN0ZW0ncyByZXNvbHZlciwgaXQgd291bGQg cmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGF0IG9iamVjdCAoZS5nLiwgYSBVUkwpLiAgR2l2ZW4g dGhlIHNob3J0LXRlcm0gbmF0dXJlIG9mIG91ciBzb2x1dGlvbiwgd2UgaGF2ZSByZWNvbW1lbmRl ZCBvbmx5IHN1cHBvcnRpbmcgdGhlIFBJRCBuYW1lIHNwYWNlLiAgVGhhdCBpcywgaWYgd2UgcGFz cyBhIFBJRCB0byB0aGUgcmVzb2x2ZXIsIHdlIGFyZSByZXR1cm5lZCB0aGUgbG9jYXRpb24gb2Yg dGhlIG9iamVjdCAoaS5lLiwgdGhlIFVSTCkgdGhhdCBpcyB0aGVuIHJlZGlyZWN0ZWQgYnkgdGhl IGJyb3dzZXIgdG8gcmV0cmlldmUgdGhhdCByZXNvdXJjZS4NDVdlIGRvIG5vdCBoYXZlIHRvIGRp cmVjdGx5IHN1cHBvcnQgdGhlc2Ugb3RoZXIgbmFtZSBzcGFjZXMsIGFzIG91ciBjYXRhbG9ncyBh bHJlYWR5IGluZGV4IHRoZXNlIGlkZW50aWZpZXJzLiAgVGhlcmVmb3JlLCBhIHVzZXIgY2FuIHNl YXJjaCBvdXIgY2F0YWxvZyB0byBmaW5kIHRoZSBiaWJsaW9ncmFwaGljIHJlY29yZCBmb3IgYW4g ZXhpc3RpbmcgaWRlbnRpZmllciAoZS5nLiwgSVNTTikgYW5kIHRoZW4gY2xpY2sgb24gdGhlIFBJ RCwgd2hpY2ggaXMgdGhlIHN1cHBvcnRlZCBuYW1lIHNwYWNlLiAgICAgIA0NTmFtaW5nIEF1dGhv cml0aWVzDQlJdCBpcyB0ZWNobmljYWxseSBwb3NzaWJsZSB0byBjcmVhdGUgYSBkZWNlbnRyYWxp emVkIHN5c3RlbSBmb3IgcHJvdmlkaW5nIFBJRHMgZm9yIHJlc291cmNlcy4gRm9yIGV4YW1wbGUs IGVhY2ggY2FtcHVzIGxpYnJhcnkgY291bGQgcnVuIHRoZWlyIG93biBtYXBwaW5nIHN5c3RlbSBh bmQgYXNzaWduIHRoZWlyIG93biBQSURzLiAgSXQgaXMgb3VyIHJlY29tbWVuZGF0aW9uLCBob3dl dmVyLCB0aGF0IHRoZSBDREwgcnVuIGEgY2VudHJhbGl6ZWQgbWFwcGluZyBzeXN0ZW0gZm9yIHRo ZSBVQyBsaWJyYXJ5IHN5c3RlbSB1bmRlciBhIG5hbWluZyBhdXRob3JpdHkgY2FsbGVkIFVDTGli cy4gIFRoaXMgYXBwcm9hY2ggd291bGQgbWluaW1pemUgdGhlIGNvc3RzIG9mIGltcGxlbWVudGF0 aW9uLCBieSBlbGltaW5hdGluZyB0aGUgZHVwbGljYXRpb24gb2YgZWZmb3J0LiAgSW4gYWRkaXRp b24sIGl0IHdvdWxkIGVuc3VyZSB0aGF0IHR3byBkaWZmZXJlbnQgYXV0aG9yaXRpZXMgZGlkIG5v dCBhc3NpZ24gdGhlIHNhbWUgUElELiAgVGhpcyB3b3VsZCBiZWNvbWUgYSBwcm9ibGVtIGlmIHdl IGV2ZXIgd2FudCB0byBtZXJnZSB0d28gb3IgbW9yZSBuYW1pbmcgYXV0aG9yaXRpZXMgaW50byBv bmUuDQ1NaWdyYXRpbmcgUElEcyB0byBVUk5zIA0JDVRoZSBVQyBMaWJyYXJpZXMgc2hvdWxkIHBh eSBjYXJlZnVsIGF0dGVudGlvbiB0byB0aGUgd2F5cyBpbiB3aGljaCBQSURzIGFyZSBhc3NpZ25l ZCB0byBwYXJ0aWN1bGFyIHJlc291cmNlcywgYW5kIHRha2Ugc3RlcHMgdG8gZW5zdXJlIHRoYXQg YXNzaWduZWQgUElEcyBtYXkgZXZlbnR1YWxseSBiZSBhbGdvcml0aG1pY2FsbHkgdHJhbnNmb3Jt ZWQgaW50byBVUk5zLiAgVGVjaG5pY2FsbHkgdGhpcyBpcyBub3QgYSBwYXJ0aWN1bGFybHkgZGlm ZmljdWx0IHByb2JsZW0sIGJ1dCBpdCBkb2VzIHJlcXVpcmUgdGhhdCBkZWNpc2lvbnMgYmUgbWFk ZSBpbiBhZHZhbmNlIG9mIGFzc2lnbm1lbnQgb2YgYW55IFBJRHMgcmVnYXJkaW5nIHRoZSBuYW1l IHNwYWNlcyB0aGF0IHdpbGwgYmUgZW1wbG95ZWQgaW4gaWRlbnRpZnlpbmcgcmVzb3VyY2VzIG1h bmFnZWQgYnkgdGhlIFVuaXZlcnNpdHksIGFuZCBob3cgYXV0aG9yaXR5IHRvIGFzc2lnbiBuZXcg UElEcyB3aWxsIGJlIGRlbGVnYXRlZC4gIEluIG91ciBjYXNlLCB0aGUgcHJvYmxlbSBpcyBzb21l d2hhdCBzaW1wbGlmaWVkIGJ5IHRoZSBmYWN0IHdlIGFyZSByZWNvbW1lbmRpbmcgb25lIG5hbWUg c3BhY2UgKFBJRHMpIGFuZCBvbmUgbmFtaW5nIGF1dGhvcml0eSAoVUNMaWJzKS4gIEhvd2V2ZXIs IHdlIHN0aWxsIG5lZWQgdG8gY29uc2lkZXIgdGhlIHN5bnRheCBvZiB0aGUgUElELg0NQSBVUk4g dGFrZXMgdGhlIGZvcm0gb2YgdXJuOjxuaWQ+Ojxuc3M+IHdoZXJlIDxuaWQ+IGlzIGEgbmFtZSBz cGFjZSBpZGVudGlmaWVyLCBhbmQgPG5zcz4gaXMgYSBuYW1lIHNwYWNlIHNwZWNpZmljIHN0cmlu ZyAod2hhdCB3ZSB3b3VsZCB0aGluayBvZiBhcyB0aGUgYWN0dWFsIGlkZW50aWZpZXIgZm9yIGEg cmVzb3VyY2UpLiAgU28sIGZvciBleGFtcGxlLCB1cm46aXNibjowMzkzOTcyODFYIGlzIGEgdXJu IHdoZXJlIHRoZSBuYW1lc3BhY2UgaXMgdGhlIGludGVybmF0aW9uYWwgc3RhbmRhcmQgYm9vayBu dW1iZXIsIGFuZCB0aGUgYWN0dWFsIElTQk4gYXNzaWduZWQgdG8gdGhlIHdvcmsgaXMgMDM5Mzk3 MjgxWC4gIA0NT3VyIFBJRHMsIGJ5IGNvbnRyYXN0LCB3b3VsZCB0YWtlIHRoZSBmb3JtIGh0dHA6 Ly88bWFwcGluZ19zeXN0ZW1fc2VydmVyPi88cmVzb3VyY2VfcGF0aD4gd2hlcmUgPG1hcHBpbmdf c3lzdGVtX3NlcnZlciA+IGlzIHRoZSBmdWxseS1xdWFsaWZpZWQgZG9tYWluIG5hbWUgZm9yIGEg VUNMaWJzIG5hbWluZyBhdXRob3JpdHkgc2VydmVyLCBhbmQgPHJlc291cmNlX3BhdGg+IGNvbnN0 aXR1dGVzIGFuIGlkZW50aWZpZXIgZm9yIGEgcmVzb3VyY2UgcmVnaXN0ZXJlZCBhdCB0aGF0IHNl cnZlciAoZS5nLiwgdGhlIFBJRCkuICBUaGVyZWZvcmUsIHdlIHdvdWxkIHdhbnQgdG8gY3JlYXRl IFBJRHMgc3VjaCBhczoNDQlodHRwOi8vVUNMaWJzLmNkbGxpYi5vcmcvcGlkLzAzOTM5NzI4MVgN DSB0aGF0IGNhbiBiZSB0cmFuc2Zvcm1lZCBhbGdvcml0aG1pY2FsbHkgaW50byB0aGVpciBVUk4g Zm9ybWF0czoNDQl1cm46cGlkOjAzOTM5NzI4MVgNDUFkbWluaXN0cmF0aXZlIFNlcnZpY2UgZm9y IGEgTWFwcGluZyBTeXN0ZW0NVGhlIG1hcHBpbmcgc3lzdGVtIHdpbGwgcmVxdWlyZSBzZXZlcmFs IGZlYXR1cmVzIG5lZWRlZCB0byBlYXNlIGl0cyBhZG1pbmlzdHJhdGlvbiBhbmQgdXNlLiAgVGhl IGZpcnN0IG9mIHRoZXNlIGlzIGRlbGVnYXRpb24gb2YgbmFtZSBjcmVhdGlvbiBhbmQgbWFpbnRl bmFuY2UgYnkgdGhvc2Ugd2hvIGFkbWluaXN0ZXIgdGhlIG1hcHBpbmcgc3lzdGVtLiAgVXNlcnMg YXQgYWxsIG9mIHRoZSBjYW1wdXNlcyBhbmQgYXQgdGhlIENETCB3aWxsIG5lZWQgdG8gYmUgYWJs ZSB0byBhZGQsIG1vZGlmeSBhbmQgZGVsZXRlIGluZm9ybWF0aW9uIGZvciBwYXJ0aWN1bGFyIFBJ RHMgYXMgbmVjZXNzYXJ5LiAgVGhlIG1hcHBpbmcgc3lzdGVtIHdpbGwgdGhlcmVmb3JlIHJlcXVp cmUgc29tZSBtZWFucyBvZiBhbGxvd2luZyB1c2VycyBhdXRob3JpemVkIGJ5IFVDTGlicyB0byBt YWtlIG5lZWRlZCBjaGFuZ2VzIHRvIGluZm9ybWF0aW9uIHJlY29yZGVkIGluIHRoZSBzeXN0ZW0u ICAgSXQgd2lsbCBhbHNvIG5lZWQgdG8gZW5zdXJlIHRoYXQgb25seSBhdXRob3JpemVkIHVzZXJz IGNhbiBtYWtlIGNoYW5nZXMsIGFuZCB0aGF0IHRob3NlIHVzZXJzIGNhbiBvbmx5IGFsdGVyIG9y IGRlbGV0ZSBpbmZvcm1hdGlvbiB0aGF0IGlzIHdpdGhpbiB0aGVpciBhdXRob3JpdHkgdG8gbW9k aWZ5IChlLmcuLCB1c2VycyBhdCBVLkMuIEJlcmtlbGV5IHNob3VsZCBub3QgYmUgYWJsZSB0byBt b2RpZnkgUElEIGVudHJpZXMgY3JlYXRlZCBieSBDREwgdXNlcnMsIGFuZCB2aWNlIHZlcnNhKS4g IFRoZSBtYXBwaW5nIHN5c3RlbSB3aWxsIHRoZXJlZm9yZSBuZWVkIHRvIHN1cHBvcnQgc29tZSB0 eXBlIG9mIHVzZXIgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLg0NVXNlcnMgd2lsbCBuZWVkIGEg bWVjaGFuaXNtIHRvIGFkZCBuZXcgZW50cmllcyBpbnRvIHRoZSBtYXBwaW5nIHN5c3RlbSBtYXRj aGluZyBQSURzIHdpdGggdGhlaXIgcmVzcGVjdGl2ZSBVUkxzLiAgIFRoZXkgd2lsbCBhbHNvIG5l ZWQgc29tZSBtZWFucyB0byBtb2RpZnkgdGhlIFVSTCBhc3NvY2lhdGVkIHdpdGggYSBQSUQgd2hl biBhIHJlc291cmNlIGlzIHJlbG9jYXRlZCwgYW5kIGEgd2F5IHRvIGRlbGV0ZSBlbnRyaWVzIChv ciBhdCBsZWFzdCBtYXJrIHRoZW0gYXMgaW5hY3RpdmUpIHdoZW4gcmVzb3VyY2VzIGJlY29tZSBw ZXJtYW5lbnRseSB1bmF2YWlsYWJsZS4gIFRoZSBzeXN0ZW0gd2lsbCBhbHNvIG5lZWQgdG8gYWxs b3cgdXNlcnMgc29tZSBtZWFucyB0byBiYXRjaCBhbGwgb2YgdGhlc2UgaW50ZXJhY3Rpb25zLiAg QmF0Y2ggZmFjaWxpdGllcyBtaWdodCBiZSBuZWVkZWQsIGZvciBleGFtcGxlIHRvIHNpbXBsaWZ5 IHRoZSBqb2Igb2YgbW9kaWZ5aW5nIGFsbCBvZiB0aGUgVVJMcyBmb3IgYSBzZXQgb2YgcmVzb3Vy Y2VzIHRoYXQgYXJlIHJlbG9jYXRlZCBmcm9tIG9uZSBIVFRQIHNlcnZlciB0byBhbm90aGVyLg0N VGhlIG1hcHBpbmcgc3lzdGVtIHNob3VsZCBpbmNsdWRlIGxvZ2dpbmcgZmFjaWxpdGllcywgYm90 aCB0byByZWNvcmQgdHJhbnNhY3Rpb25zIHdoaWNoIG1vZGlmeSB0aGUgc3lzdGVtknMgZGF0YWJh c2UsIGFuZCB0byByZWNvcmQgYWN0aXZpdHkgYnkgdGhlIHJlc29sdmVyIHBvcnRpb24gb2YgdGhl IHN5c3RlbSBpbiBvcmRlciB0byBtb25pdG9yIGl0cyBwZXJmb3JtYW5jZS4NDVVzZXJzIG1heSBu ZWVkIHRvIGV4YW1pbmUgYWxsIG9mIHRoZSBQSUQvVVJMIGVudHJpZXMgdGhleSBoYXZlIGNyZWF0 ZWQsIG9yIHNvbWUgc3Vic2V0IG9mIHRoZW0sIHRvIGVuc3VyZSB0aGVpciBjb3JyZWN0bmVzcyBv ciB0byBwcmVwYXJlIGEgYmF0Y2ggam9iIGZvciBzdWJtaXNzaW9uIHRvIHRoZSBzeXN0ZW0gKGFz IGluIHRoZSBjYXNlIG9mIG1vZGlmeWluZyBhbGwgdGhlIFVSTHMgZm9yIHJlc291cmNlcyBtb3Zl ZCBmcm9tIG9uZSBzZXJ2ZXIgdG8gYW5vdGhlcikuICBUaGUgc3lzdGVtIHdpbGwgdGhlcmVmb3Jl IG5lZWQgc29tZSBmb3JtIG9mIHJlcG9ydGluZyBmYWNpbGl0eS4gIFVzZXJzIHNob3VsZCBiZSBh YmxlIHRvIHByZXBhcmUgcmVwb3J0cyBzaG93aW5nIGFsbCBQSUQvVVJMIGVudHJpZXMgdGhhdCB0 aGV5IGFyZSBhdXRob3JpemVkIHRvIG1vZGlmeSwgb3Igb25seSB0aG9zZSB3aGljaCBtZWV0IGEg dXNlci1zZWxlY3RlZCBzZXQgb2YgY3JpdGVyaWEuICBSZXBvcnRpbmcgZmFjaWxpdGllcyBzaG91 bGQgYWxzbyBpbmNsdWRlIHJlcG9ydHMgb24gdGhlIHN5c3RlbZJzIHBlcmZvcm1hbmNlIGJhc2Vk IG9uIGl0cyB0cmFuc2FjdGlvbiBsb2dzLg0NRmluYWxseSwgZ2l2ZW4gdGhlIHZpdGFsIHJvbGUg cGxheWVkIGJ5IHRoZSBtYXBwaW5nIHN5c3RlbSBpbiBwcm92aWRlIHNlcnZpY2VzIHRvIHRoZSBV LkMuIExpYnJhcmllc5IgdXNlcnMsIGZhY2lsaXRpZXMgZm9yIGJhY2tpbmcgdXAgdGhlIGluZm9y bWF0aW9uIHdpdGhpbiB0aGUgbWFwcGluZyBzeXN0ZW0gYW5kIGVuc3VyaW5nIGl0cyBzdXJ2aXZh bCBpbiB0aGUgY2FzZSBvZiBkaXNhc3RlciBpcyBlc3NlbnRpYWwuICBXaGlsZSB0aGUgdGVjaG5p Y2FsIG1lYW5zIHRvIGFjY29tcGxpc2ggdGhpcyBtYXkgbm90IGNvbnN0aXR1dGUgcGFydCBvZiB0 aGUgbWFwcGluZyBzeXN0ZW0gcGVyIHNlLCB0aGlzIG5lZWQgaXMgb2Ygc3VmZmljaWVudCBpbXBv cnRhbmNlIHRvIG1lcml0IGNvbnNpZGVyaW5nIGl0IGFzIGFuIGVzc2VudGlhbCBjb21wb25lbnQg b2YgdGhlIG92ZXJhbGwgc3lzdGVtLg0NLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ1GVVRVUkUgRElTQ1VTU0lPTg0NMSkgSG93IGRvIHdlIGhhbmRsZSBk eW5hbWljYWxseSBjcmVhdGVkIFVSTHM/DTIpIFJldmlzaXQgdGhlIHRlY2huaWNhbCBzb2x1dGlv biAoVVJMIHJlZGlyZWN0aW9uKSB0byBzZWUgaWYgaXQgc3RpbGwgd29ya3MsIGFmdGVyIHRoZXNl IG90aGVyIGRpc2N1c3Npb25zLg0zKSBQZXJzaXN0ZW50IElEcyBmb3IgdGhlIGFyY2hpdmFsIGNv cHkgb2YgdGhlIGRhdGEgc2V0cy4NAiBBbiBIVFRQIHJlZGlyZWN0IGlzIGEgd2ViIGJyb3dzZXIg c3VwcG9ydGVkIGZ1bmN0aW9uLiAgV2hlbiBvbmUgY2xpY2tzIG9uIGFuIEhUTUwgbGluayAoVVJM KSwgdGhlIGJyb3dzZXIgc2VuZHMgYSBtZXNzYWdlIHRvIHRoZSB3ZWIgc2VydmVyIGlkZW50aWZp ZWQgaW4gdGhhdCBVUkwuICBVc3VhbGx5LCB0aGUgc2VydmVyIHdvdWxkIHJldHVybiBhbiBIVE1M IHBhZ2UgdG8gZGlzcGxheS4gIEhvd2V2ZXIsIHRoZSBzZXJ2ZXIgY2FuIHJldHVybiBhbiBIVFRQ IHJlZGlyZWN0IHdpdGggYSBuZXcgVVJMLCBhbmQgdGhlIGJyb3dzZXIgd2lsbCB0aGVuIHNlbmQg dGhhdCBVUkwgdG8gdGhlIG5ldyBzZXJ2ZXIgaXQgaWRlbnRpZmllcy4NDRNQQUdFICAUMRUNDQ0T UEFHRSAgFDUVDQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAeBAAAJQQAADoEAAAiBQAALQUAAE8FAABY BQAA2gcAAOQHAABuCQAAhAkAAGcKAAB1CgAA7woAAPAKAAAJCwAAEwsAAJINAACxDQAAsw0AALkN AACMEgAAqhIAAI4YAAC6GAAA4RgAAOMYAADwGAAArhwAAMEcAAAyHwAASh8AAEsfAABPJQAAeyUA AEsxAABMMQAAtzIAALgyAAC+MgAAvzIAAMAyAADBMgAAwjIAAMQyAADFMgAAyzIAAMwyAADNMgAA zjIAANAyAADUMgAA/QD9APkA+QD5AP0A9wDwAPkA9wD9AP0A6uUA/QD9AP0A5d8A8ADY1djQ2NUA 2NXY0NjVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACDBKEQBtSAAEAAQw ShEAAA0DagAAAAAwShEAVQgBCzUIgU9KAwBRSgMACE9KAwBRSgMAAAs2CIFPSgMAUUoDAA0DagAA AAAwShgAVQgBAzYIgQY1CIE2CIEAAzUIgQA0AAQAAB4EAAAlBAAAJgQAADoEAABXBgAAWAYAAEUI AABGCAAAbQkAAG4JAACECQAAbgsAAG8LAAD4DAAA+QwAALENAACyDQAAsw0AALkNAABWDwAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARgAAEYRoAUMkAUXGgAAA AQBPMkMmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAMAABGEaAEAAQAAABQABAAAHgQAACUEAAAmBAAAOgQAAFcGAABYBgAARQgA AEYIAABtCQAAbgkAAIQJAABuCwAAbwsAAPgMAAD5DAAAsQ0AALINAACzDQAAuQ0AAFYPAABXDwAA wRAAAMIQAACLEgAAjBIAAKoSAABuEwAAbxMAAIAVAACBFQAAABgAAAEYAADiGAAA4xgAAO8YAACI GwAAiRsAAK0cAACuHAAAwRwAADEfAAAyHwAASh8AAEwfAAALIgAADCIAAHAjAABxIwAAzSQAAM4k AAD3JAAA+CQAADklAAA6JQAATiUAAE8lAAB7JQAA5igAAOcoAAAyKwAAMysAAAssAAAMLAAAay4A AGwuAAAwMAAAMTAAAGMwAAB1MAAAdjAAAKQwAAARMQAASzEAALYyAAC3MgAAvzIAAMAyAADEMgAA zzIAANAyAADRMgAA0jIAANMyAADUMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD+/v7+/v7+/v7+/v7+AAAAAAAAAAAAAAAAAAAAAPz8/Pz8+fn59/wAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAINAQAFAhAADQECAQEAAgcMVFYPAABXDwAAwRAAAMIQAACLEgAAjBIAAKoSAABuEwAA bxMAAIAVAACBFQAAABgAAAEYAADiGAAA4xgAAO8YAACIGwAAiRsAAK0cAACuHAAAwRwAADEfAAAy HwAASh8AAEwfAAALIgAADCIAAHAjAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAAAAAAAAAAcAAAomDAtGAAARhGgBBQAACiYM C0YAAAcAAAomDAtGAAARhNACAAEAAAAbcCMAAHEjAADNJAAAziQAAPckAAD4JAAAOSUAADolAABO JQAATyUAAHslAADmKAAA5ygAADIrAAAzKwAACywAAAwsAABrLgAAbC4AADAwAAD4AAAAAAAAAAAA AAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAA AAAAAAAA7wAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAA AKgAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAACoAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAABEAABDJAFFxoAAAAEATDJDJgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAARhGgBBQAA CiYMC0YAAAcAAAomDAtGAAARhGgBABMwMAAAMTAAAGMwAAB1MAAAdjAAAKQwAAARMQAASzEAALYy AAC3MgAAwjIAAMMyAADEMgAAzzIAANAyAADRMgAA0jIAANMyAADUMgAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAA AO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADuAAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoQABsmYA6EaAEjJAIYhPj/GYQBAAADEAAOhGgBAAgQABsm YCMkAhiE+P8ZhAEAAAEXAAABAAAAEh8ACjABH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAZAAoAAQBbAA8AAgAAAAAAAAAoAABA8f8CACgAAAAGAE4A bwByAG0AYQBsAAAAAgAAAAgAQ0oYAG1ICQRCAAEAIQEiAEIAAAAJAEgAZQBhAGQAaQBuAGcAIAAx AAAAEAABAAYkAROk8AAUpDwAQCYADgA1CIE7CIFDShgAS0gcAEYAAgABAAIARgAAAAkASABlAGEA ZABpAG4AZwAgADIAAAAQAAIABiQBE6TwABSkPABAJgESADUIgTYIgUNKGABPSgIAUUoCAEAAAwAB AAIAQAAAAAkASABlAGEAZABpAG4AZwAgADMAAAAQAAMABiQBE6TwABSkPABAJgIMAENKGABPSgIA UUoCAEIABAAxAAIAQgAAAAkASABlAGEAZABpAG4AZwAgADQAAAANAAQAD4Q4BBSkAABAJgMADwA2 CIFLSBwAT0oAAFFKAAAANAAFAFEBAgA0AAAACQBIAGUAYQBkAGkAbgBnACAANQAAAAwABQAKJgAL RgAAQCYEBABDShgAAAAAAAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBh AGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAALAAfAAEA8gAsAAAABgBIAGUAYQBkAGUA cgAAAA0ADwANxggAAuAQwCEBAgAAACwAIEABAAIBLAAAAAYARgBvAG8AdABlAHIAAAANABAADcYI AALgEMAhAQIAAAAmAClAogARASYAAAALAFAAYQBnAGUAIABOAHUAbQBiAGUAcgAAAAAAJAAvAAEA IgEkAAAABABMAGkAcwB0AAAACgASAA+EaAERhJj+AAAkAP4PAQAyASQAAAAEAFAAYQByADMAAAAG ABMAEYQ4BAQAQ0oYACAA/g8xAUIBIAAAAAQAUABhAHIANAAAAAYAFAARhKAFAAAyADAAAQBSATIA AQALAEwAaQBzAHQAIABCAHUAbABsAGUAdAAAAAkAFQAKJgALRgIAAAAAJAD+DwEAYgEkAAAABABQ AGEAcgAyAAAABgAWABGE0AIEAENKGAAyAB1AAQByATIAAAANAEYAbwBvAHQAbgBvAHQAZQAgAFQA ZQB4AHQAAAACABcABABDShQAOAAmQKIAgQE4AAAAEgBGAG8AbwB0AG4AbwB0AGUAIABSAGUAZgBl AHIAZQBuAGMAZQAAAAMASCoBAO8GAADULgAAAQAAAAAAawEAAG4BAAAAAAAA1C4AAA8AAEQAAAwA /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAbAAAAGwAAABsAAAAe AAAAAAQAANQyAAAcAAAAAAQAAFYPAABwIwAAMDAAANQyAAAdAAAAHwAAACAAAAAhAAAAAAQAANQy AAAeAAAA//8CAAAABwBVAG4AawBuAG8AdwBuAA0AQgBlAHIAbgBpAGUAIABIAHUAcgBsAGUAeQAA AAAABwAAAAkAAAANAAAAFAAAABYAAAAeAAAAEyE0/5WAEyF0/5WAAAAAACYjAAAsIwAASy0AALcu AADSLgAA1S4AAAcAHAAHAAcABwACAAAAAABhFQAAfBUAAN0eAADtHgAADCgAABkpAABLLQAAty4A ANIuAADVLgAABwAaAAcAGgAHABoABwAHAAcAAgD//xQAAAANAEIAZQByAG4AaQBlACAASAB1AHIA bABlAHkAKABDADoAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBl ACAAbwBmACAAUABJAEQAXwBWADMALgByAGUAdgAxAA0AQgBlAHIAbgBpAGUAIABIAHUAcgBsAGUA eQAoAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABv AGYAIABQAEkARABfAFYAMwAuAHIAZQB2ADEADQBCAGUAcgBuAGkAZQAgAEgAdQByAGwAZQB5ACgA QwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAg AFAASQBEAF8AVgAzAC4AcgBlAHYAMQANAEIAZQByAG4AaQBlACAASAB1AHIAbABlAHkAKABDADoA XABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAUABJ AEQAXwBWADMALgByAGUAdgAxAA0AQgBlAHIAbgBpAGUAIABIAHUAcgBsAGUAeQAoAEMAOgBcAFQA RQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABQAEkARABf AFYAMwAuAHIAZQB2ADEADQBCAGUAcgBuAGkAZQAgAEgAdQByAGwAZQB5ACgAQwA6AFwAVABFAE0A UABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFAASQBEAF8AVgAz AC4AcgBlAHYAMQANAEIAZQByAG4AaQBlACAASAB1AHIAbABlAHkANABcAFwAYgB1AHMAaQBvAGYA ZgBcAEIAZQByAG4AaQBlACcAcwAgAFcAUABXAEkATgBcAEMARABMAFwAUwB0ACAAJgAgAEEAcgBj AGgAIABXAEcAXABQAEkARABfAFYANAAuAGQAbwBjAA0AQgBlAHIAbgBpAGUAIABIAHUAcgBsAGUA eQAnAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABv AGYAIABQAEkARABfAFYANAAuAGEAcwBkAA0AQgBlAHIAbgBpAGUAIABIAHUAcgBsAGUAeQAnAEMA OgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABQ AEkARABfAFYANAAuAGEAcwBkAA0AQgBlAHIAbgBpAGUAIABIAHUAcgBsAGUAeQA0AFwAXABiAHUA cwBpAG8AZgBmAFwAQgBlAHIAbgBpAGUAJwBzACAAVwBQAFcASQBOAFwAQwBEAEwAXABTAHQAIAAm ACAAQQByAGMAaAAgAFcARwBcAFAASQBEAF8AVgA0AC4AZABvAGMAAgCJ////TIX62BUA/w//D/8P /w//D/8P/w//DwEA+2i8B/66ZiT/D/8P/w//D/8P/w//D/8P/w8BAAEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAMAAQAAAAAAAAAA AAAAAAAAAAAAAxAAAA+E0AIRhJj+FcYFAAHQAgZvKAACAAAALgADAAAAif///wAAAAAAAAAAAAAA AIn///8AAAAAAAAAAAAAAAD7aLwHAAAAAAAAAAAAAAAA//////////////////8CAAAAAAAAAP9A A4ABAEotAABKLQAA7DnaAQEAAQBKLQAAAAAAAEotAAAAAAAAAhAAAAAAAAAA1C4AAPAAAAgAQAAA BAAAAEcWkAEAAAICBgMFBAUCAwSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABUAGkAbQBlAHMAIABO AGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAA AABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABB AHIAaQBhAGwAAABlFpABAA8CAgYCBgUGAgQDhwAAAAAAAAAAAAAAAAAAABsAAAAAAAAARQBsAGUA ZwBhAEcAYQByAG0AbgBkACAAQgBUAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAAi AAQAcQiIGAAAaAEAAGgBAAAAAGYyQyZbM0Mm6RlDpgMAEAAAAI0GAABYJQAAAQATAAAABAADEE8A AAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAJAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA pQbAB7QAtACAADIwAAAQABkAZAAAABkAAADcLQAAAAAAAAAAAABpfDQ+AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA3SAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAASAFcA aABhAHQAJwBzACAAdABoAGUAIABQAHIAbwBiAGwAZQBtAAAAAAAAAA0AQgBlAHIAbgBpAGUAIABI AHUAcgBsAGUAeQANAEIAZQByAG4AaQBlACAASAB1AHIAbABlAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAAIgBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAAC0AAAABAAAAMAAAAAFAAAA2AAAAAcAAADk AAAACAAAAPgAAAAJAAAAEAEAABIAAAAcAQAACgAAADgBAAALAAAARAEAAAwAAABQAQAADQAAAFwB AAAOAAAAaAEAAA8AAABwAQAAEAAAAHgBAAATAAAAgAEAAAIAAADkBAAAHgAAABMAAABXaGF0J3Mg dGhlIFByb2JsZW0AAB4AAAABAAAAAGhhdB4AAAAOAAAAQmVybmllIEh1cmxleQBibB4AAAABAAAA AGVybh4AAAALAAAATm9ybWFsLmRvdABlHgAAAA4AAABCZXJuaWUgSHVybGV5AGJsHgAAAAIAAAAz AHJuHgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAAAEAAAAAAYDQ8AgAAAEAAAAAADtLfJoW/AUAA AAAATE63koe/AUAAAAAA6vu0soe/AQMAAAABAAAAAwAAAI0GAAADAAAAWCUAAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3V nC4bEJOXCAArLPmuQAEAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAAB8AAAABgAAAIQAAAAR AAAAjAAAABcAAACUAAAACwAAAJwAAAAQAAAApAAAABMAAACsAAAAFgAAALQAAAANAAAAvAAAAAwA AADbAAAAAgAAAOQEAAAeAAAABAAAAFVDQgADAAAATwAAAAMAAAATAAAAAwAAANwtAAADAAAAahAI AAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAATAAAAV2hhdCdzIHRoZSBQ cm9ibGVtAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAJgAAAADAAAAAAAAACAAAAAB AAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADQA OABCAEYARgA3ADkARQAtAEUAMwBCADkALQAxADEARAAzAC0AQQA0ADEARgAtADAAMAAxADAANABC ADcANQA5ADkANQBEAH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAAP7///8kAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA/v///ywA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAD+////NAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAA AP7////9////PQAAAP7////+/////v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////9SAG8A bwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAQl1iHJSHvwEgAv+1soe/AT8A AACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIwAAAAAQAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIUQAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBu AGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsAAAAAEAAAAAAAAAUARABv AGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAYABgAGAA MAA4AAIB////////////////cABwAHAAcABwAHAAoABwAGAAYABgAGAAQABAAEAAQACAAHAAMwAA AAAQAACAAIAAAQBDAG8AbQBwAE8AYgBqAAAAYABgAGAAYABgAKAAUABgAGAAYABgACAAIAAgACAA YABgAGAAYABgAGAAYACAABIAAgEBAAAABgAAAP////8mAJsAAAAAAOgBFADoARQAUK8WAAAAAAAA AAAAAAAAAAAAAAAAAAAAagAAAKLYCABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAR7gAAAAcA pQAAAQkAFAAfAOBP0CDqOmkQotgIACswMJ0ZACNEFgABAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAIAL/tbKHvwEgAv+1soe/ARkAI0U6XAAAAAAAAAAAAAAAAAAAAAAACfAAAAAHALMA AAEJABQAHwDgT9Ag6jppEKLYCAArMDCdGQAlRjpcAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////FAAfAOBP0CDqOmkQotgIACswMJ0ZACpHOlwAAAAAAAAAAAAAAAAAAAAAAKGoAAAAAQAAAP7/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////8BAP7/AwoA AP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dv cmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --=====================_952407107==_ Content-Type: text/plain; charset="us-ascii" Bernie Hurley Director for Library Technologies UC Berkeley Library Rm 245, Doe Library Berkeley, CA 94720 bernie@library.berkeley.edu (510)-642-3773 (510)-643-8179 (fax) --=====================_952407107==_-- From howard@info.sims.berkeley.edu Mon Mar 6 15:30:00 2000 -0800 Status: R X-Status: X-Keywords: Received: from dosuno.ucop.edu (dosuno.ucop.edu [128.48.116.201]) by malaprop.sims.berkeley.edu (8.9.3/8.9.3) with ESMTP id PAA16932 for ; Mon, 6 Mar 2000 15:30:33 -0800 (PST) Received: from listserv (dosuno.ucop.edu [128.48.116.201]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA31612; Mon, 6 Mar 2000 15:30:31 -0800 Received: from LISTSERV.UCOP.EDU by LISTSERV.UCOP.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 370386 for CDL-TAS@LISTSERV.UCOP.EDU; Mon, 6 Mar 2000 15:30:30 -0800 Received: from dw-s-computer (ucop010066.ucop.edu [128.48.10.66]) by dosuno.ucop.edu (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA21082; Mon, 6 Mar 2000 15:30:26 -0800 X-Sender: dwalker@popserv.ucop.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Mime-Version: 1.0 Message-ID: <4.2.0.58.20000306145236.00947460@popserv.ucop.edu> Date: Mon, 6 Mar 2000 15:24:38 -0800 Reply-To: David Walker Sender: CDL Technical Architecture and Standards Workgroup List From: David Walker Subject: Re: PID Discussion Paper Comments: To: Bernie Hurley Comments: cc: Margery Tibbetts To: CDL-TAS@LISTSERV.UCOP.EDU In-Reply-To: <3.0.5.32.20000306133147.0093d820@library.berkeley.edu> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 13689 Bernie, Good paper. I've forwarded it to Margery Tibbetts, as she will be joining us on Friday to talk about this. Your issue of batch updating to allow a server change raised a question in my mind that also occurred to me at the last meeting: From the administrative point of view, do we want to map only entire URLs, or do we want to allow the specification of prefixes that are redirected, leaving the tail alone. This would allow for mapping entire subtrees with only one mapping entry, as long as the internal structure of the subtree did not change. When the internal structure of collections is expected to be stable, this would really save catalogers' time. For example, the PID mapping for the AMICO art collection might be: http://UCLibs.cdlib.org/AMICO/* => http://amico.ucop.edu/* causing "http://UCLibs.cdlib.org/AMICO/" would be redirected to "http://amico.ucop.edu/". By the way, Beverlee French is really anxious to see some result of this discussion, as SOPAG is pressuring her for it. I told her I would bring that up at our next meeting. I guess I already have. David At 01:31 PM 3/6/00 -0800, Bernie Hurley wrote: >Hi! > >I've written a short paper on most of the topics that were on our >discussion list for PIDs (attached). I hope this may serve as a starting >point for our next discussion. Jerry has already reviewed it and I thank >him for his comments. > >Please note, I wrote the paper with a broader (i.e., not so technical) >audience in mind. > >Thanks, B. > > >----- A text version for John---------- > >PERSISTENT IDENTIFIERS (PIDs) >3/6/00 > >What's the Problem? >Within our library systems we need to be able to refer to networked >resources over which we have little or no direct control. Currently, this >reference is most often implemented as a URL. A mechanism is required that >separates the management of an object on a server from the reference used >to retrieve that object. This becomes a business process issue - where one >organization is maintaining a resource (e.g., a publisher, an aggregator, >etc.) and a different and wholly unrelated organization is referring to it >(e.g, the UC Libraries) > >This business process problem is important to libraries, as it manifests >itself as "broken URLs." There is an ever increasing number of URLs in our >library systems (Melvyl, A&I databases, CDL directory, OAC, local catalogs, >etc.) that break every time files are moved from one URL path to another. >So, the solution would be to find a cost-effective way for UC libraries to >manage the references to the objects, even though another organization >manages the objects on their remote servers. > >It's worth mentioning that an optimal system would put managing the links >in the hands of those who manage the resources. This solution, however, >would require a global resolution system used by all publishers, >aggregators, libraries, etc., which will not be a reality for some time to >come. > >The Proposed Solution >One way to manage the references would be to create a "more" Persistent ID >(PID) that can be used in our systems in place of URLs. When the PID is >selected in a Web browser, it would be translated to the current URL >through a mapping system. The mapping system would translate the PID into >the current URL, which would then be called by issuing an HTTP redirect . >In this solution, the references to objects (i.e., the PIDs) are now >managed by the UC libraries via the mapping system. > >By "more persistent," we mean that we're not trying to solve the long-term >archival problem, but rather implement something that can migrate to that >solution once the URN community comes to some agreement on a standard >solution. We expect we will create a solution using URL redirection for the >coming year, with the opportunity to migrate to a true data handling system >within three years. > >By cost-effective we mean that the labor and technology cost of running the >system is less than just fixing the URLs, as they break. See the section >on Library Implementation Issues. > > >Scope > In our first implementation, we would focus on creating PIDs for our >library systems. We understand other groups also need to address this >problem (e.g., faculty needs for PIDs with regards to their publications >and the greater needs within UC, as a whole). However, broadening the >scope beyond libraries would take us into a new "political" arena and >greatly complicate any discussion and implementation > > Within the scope of library systems, we have two communities that >have the power to "break" URLs. Us and them. "Us" is for the digital >materials that UC creates and manages on UC servers. For example, the OAC >images are still on the Berkeley SUNsite. Therefore all the URLs in our >EADs will break, once we move these images to the CDL - their new home. > > The "Them" is for the URLs we load into our systems from vendors >(e.g., publishers and aggregators). If a vendor changes the locations for >their files (i.e., their URLs), would we best solve this problem by >replacing them, in a batch run, within our systems? Or, would it be better >handled within a mapping table? Using a mapping table has the added >advantage that PIDs copied out of our systems into class instructional >sites would still work. > >Library Implementation Issues > [Note: I discussed the following with our technical services and > Bancroft >technical service departments. Once we agree on this section, we should >probably send it to HOTS to be vetted. - Bernie] > > Library technical services departments will need to request PIDs > from the >mapping system to be included in metadata they produce. For example, a >cataloger will often need to add a PID to a MARC record they are creating >in OCLC, or to add a PID to an EAD finding aid. In addition to requesting >single PIDs, there will also be cases where we libraries will want to >replace all URLs in existing metadata with PIDs. Replacing all the URLs >with PIDs in existing EADs, or URLs with PIDs in our bibliographic catalogs >are examples. > > The above scenarios argue for the mapping system to provide an >administrative service in which a URL is presented to it and a PID is >returned. There will need to be a web interface to this service, so a >cataloger can present a single URL and have a PID returned. There also is >the requirement that a computer program, executing remotely, be able to >pass the mapping system a URL and receive a PID back. These programs will >be developed to either integrate PID assignment within library catalog >maintenance systems, or provide URL to PID to conversions in existing >metadata (e.g., MARC records, EADs, etc., CDL standard objects. etc.). > > In addition to creating PID, UC libraries will be responsible for >maintaining and deleting these from the mapping system. See the section, >Administrative Service for a Mapping System for a further discussion of >this topic. > >Name Spaces > It is possible to consider running an object reference system that >supported multiple name spaces. For example, an object reference systems >could be set up to resolve identifiers in the ISBN, ISSN, SICI or LCCN name >spaces. If a user sends an identifier within a particular name space >(e.g., ISSN) to the mapping system's resolver, it would return the location >of that object (e.g., a URL). Given the short-term nature of our solution, >we have recommended only supporting the PID name space. That is, if we >pass a PID to the resolver, we are returned the location of the object >(i.e., the URL) that is then redirected by the browser to retrieve that >resource. > >We do not have to directly support these other name spaces, as our catalogs >already index these identifiers. Therefore, a user can search our catalog >to find the bibliographic record for an existing identifier (e.g., ISSN) >and then click on the PID, which is the supported name space. > >Naming Authorities > It is technically possible to create a decentralized system for > providing >PIDs for resources. For example, each campus library could run their own >mapping system and assign their own PIDs. It is our recommendation, >however, that the CDL run a centralized mapping system for the UC library >system under a naming authority called UCLibs. This approach would >minimize the costs of implementation, by eliminating the duplication of >effort. In addition, it would ensure that two different authorities did >not assign the same PID. This would become a problem if we ever want to >merge two or more naming authorities into one. > >Migrating PIDs to URNs > > The UC Libraries should pay careful attention to the ways in which PIDs >are assigned to particular resources, and take steps to ensure that >assigned PIDs may eventually be algorithmically transformed into URNs. >Technically this is not a particularly difficult problem, but it does >require that decisions be made in advance of assignment of any PIDs >regarding the name spaces that will be employed in identifying resources >managed by the University, and how authority to assign new PIDs will be >delegated. In our case, the problem is somewhat simplified by the fact we >are recommending one name space (PIDs) and one naming authority (UCLibs). >However, we still need to consider the syntax of the PID. > > A URN takes the form of urn:: where is a name space >identifier, and is a name space specific string (what we would think >of as the actual identifier for a resource). So, for example, >urn:isbn:039397281X is a urn where the namespace is the international >standard book number, and the actual ISBN assigned to the work is >039397281X. > > Our PIDs, by contrast, would take the form >http:/// where > is the fully-qualified domain name for a UCLibs naming authority server, >and constitutes an identifier for a resource registered at >that server (e.g., the PID). Therefore, we would want to create PIDs such as: > > http://UCLibs.cdllib.org/pid/039397281X > > that can be transformed algorithmically into their URN formats: > > urn:pid:039397281X > > Administrative Service for a Mapping System >The mapping system will require several features needed to ease its >administration and use. The first of these is delegation of name creation >and maintenance by those who administer the mapping system. Users at all >of the campuses and at the CDL will need to be able to add, modify and >delete information for particular PIDs as necessary. The mapping system >will therefore require some means of allowing users authorized by UCLibs to >make needed changes to information recorded in the system. It will also >need to ensure that only authorized users can make changes, and that those >users can only alter or delete information that is within their authority >to modify (e.g., users at U.C. Berkeley should not be able to modify PID >entries created by CDL users, and vice versa). The mapping system will >therefore need to support some type of user authentication mechanism. > >Users will need a mechanism to add new entries into the mapping system >matching PIDs with their respective URLs. They will also need some means >to modify the URL associated with a PID when a resource is relocated, and a >way to delete entries (or at least mark them as inactive) when resources >become permanently unavailable. The system will also need to allow users >some means to batch all of these interactions. Batch facilities might be >needed, for example to simplify the job of modifying all of the URLs for a >set of resources that are relocated from one HTTP server to another. > >The mapping system should include logging facilities, both to record >transactions which modify the system's database, and to record activity by >the resolver portion of the system in order to monitor its performance. > >Users may need to examine all of the PID/URL entries they have created, or >some subset of them, to ensure their correctness or to prepare a batch job >for submission to the system (as in the case of modifying all the URLs for >resources moved from one server to another). The system will therefore >need some form of reporting facility. Users should be able to prepare >reports showing all PID/URL entries that they are authorized to modify, or >only those which meet a user-selected set of criteria. Reporting >facilities should also include reports on the system's performance based on >its transaction logs. > >Finally, given the vital role played by the mapping system in provide >services to the U.C. Libraries' users, facilities for backing up the >information within the mapping system and ensuring its survival in the case >of disaster is essential. While the technical means to accomplish this may >not constitute part of the mapping system per se, this need is of >sufficient importance to merit considering it as an essential component of >the overall system. > >------------------------------------------------- >FUTURE DISCUSSION > >1) How do we handle dynamically created URLs? >2) Revisit the technical solution (URL redirection) to see if it still >works, after these other discussions. >3) Persistent IDs for the archival copy of the data sets. > > > >Bernie Hurley >Director for Library Technologies >UC Berkeley Library >Rm 245, Doe Library >Berkeley, CA 94720 > >bernie@library.berkeley.edu >(510)-642-3773 >(510)-643-8179 (fax)